Operators deploying ROV and/or other RPKI-based policies should ensure that the BGP speaker implementation is not causing route refresh requests to neighbors.
BGP speakers MUST
either keep the full Adj-RIB-In or implement the specification in Section 4
. Conformance to this behavior is an additional, mandatory capability for BGP speakers performing ROV.
If the BGP speaker does not implement these recommendations, the operator should enable the vendor's control to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration inbound". The operator should then measure to ensure that there are no unnecessary route refresh requests sent to neighbors.
If the BGP speaker's equipment has insufficient resources to support either of the two proposed options (keeping a full AdjRibIn or at least the dropped routes), the equipment SHOULD
either be replaced with capable equipment or SHOULD NOT
be used for ROV.
The configuration setting in Section 4
should only be used in very well-known and controlled circumstances where the scaling issues are well understood and anticipated.
Operators using the specification in Section 4
should be aware that a misconfigured neighbor might erroneously send a massive number of paths, thus consuming a lot of memory. Hence, pre-policy filtering such as described in [MAXPREFIX-INBOUND
] could be used to reduce this exposure.
If route refresh has been issued toward more than one peer, the order of receipt of the refresh data can cause churn in both best route selection and outbound signaling.
Internet Exchange Points (IXPs) that provide route servers [RFC 7947
] should be aware that some members could be causing an undue route refresh load on the route servers and take appropriate administrative and/or technical measures. IXPs using BGP speakers as route servers should ensure that they are not generating excessive route refresh requests.