diff --git a/draft-ietf-sidrops-rov-no-rr.xml b/draft-ietf-sidrops-rov-no-rr.xml index 0a7bb31..2661a6e 100644 --- a/draft-ietf-sidrops-rov-no-rr.xml +++ b/draft-ietf-sidrops-rov-no-rr.xml @@ -10,7 +10,7 @@ @@ -80,11 +80,11 @@ A BGP Speaker performing RPKI-based policy should not issue Route -q Refresh to its neighbors because it has received new RPKI data. - This document updates RFC8481 by describing how to avoid doing so - by either keeping a full Adj-RIB-In or saving paths dropped due to - ROV (Route Origin Validation) so they may be reevaluated with - respect to new RPKI data. + Refresh to its neighbors because it has received new RPKI data. + This document updates by describing how + to avoid doing so by either keeping a full Adj-RIB-In or saving + paths dropped due to ROV (Route Origin Validation) so they may be + reevaluated with respect to new RPKI data. @@ -169,52 +169,55 @@ q Refresh to its neighbors because it has received new RPKI data. - Other mechanisms, such as automented policy provisioning, which + Other mechanisms, such as automated policy provisioning, which have flux rates similar to ROV (i.e. on the order of minutes), could very well cause similar problems. + + Therefore this document updates by + describing how to avoid this problem. + +
- Ameliorating this problem by keeping a full Adj-RIB-In can be a - problem for resource constrained BGP speakers. In reality, only - some data need be retained. + If new RPKI data arrive which cause operator policy to invalidate + the best route, and the BGP speaker did not keep the dropped + routes, then it would issue a route refresh, which this feature + aims to prevent. - A route that is dropped by operator policy due to ROV MUST be - considered ineligible and MUST be kept in the Adj-RIB-In for - potential future evaluation. + A route that is dropped by operator policy due to ROV is, by + nature, considered ineligible to compete for best route, and MUST + be kept in the Adj-RIB-In for potential future evaluation. - If new RPKI data arrive which invalidate the best route, and the - BGP speaker did not keep all alternatives, then it MUST issue a - route refresh, so those alternatives may be evaluated for best - route. - - - - Policy which may drop routes due to RPKI-based checks such as ROV, - ASPA, BGPsec , etc. MUST be run, and the - dropped routes saved per the above paragraph, before non-RPKI - policies are run, as the latter may change path attributes. + Ameliorating the Route Refresh problem by keeping a full + Adj-RIB-In can be a problem for resource constrained BGP speakers. + In reality, only some data need be retained. If an implementation + chooses not to retain the full Adj-RIB-In, it MUST retain at least + routes dropped due to ROV, for potential future evaluation. As storing these routes could cause problems in resource constrained devices, there MUST be a global operation, CLI, YANG, - ... allowing operator control of this feature. Such a control - MUST NOT be per peer, as this could cause inconsistent behavior. + etc. allowing the operator to enable this feature, storing the + dropped routes. Such a control MUST NOT be per peer, as this + could cause inconsistent behavior. - 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 in outbound signaling. + As a side note: policy which may drop routes due to RPKI-based + checks such as ROV (and ASPA, BGPsec , + etc. in the future) MUST be run, and the dropped routes saved per + this section, before non-RPKI policies are run, as the latter may + change path attributes.
@@ -224,12 +227,14 @@ q Refresh to its neighbors because it has received new RPKI data. Operators deploying ROV and/or other RPKI based policies should ensure that the BGP speaker implementation is not causing - unnecessary Route Refresh requests to neighbors. + Route Refresh requests to neighbors. BGP Speakers MUST either keep the full Adj-RIB-In or implement the - specification in . + specification in . Conformance to this + behavior is a additional, mandatory capability for BGP speakers + performing ROV. @@ -244,7 +249,7 @@ q Refresh to its neighbors because it has received new RPKI data. If the BGP speaker's equipment has insufficient resources to support either of the two proposed options, it MUST NOT be used for Route Origin Validation. The equipment should either be - replaced with capable equipement or ROV not used. I.e. the knob + replaced with capable equipment or ROV not used. I.e. the knob in should only be used in very well known and controlled circumstances. @@ -258,6 +263,12 @@ q Refresh to its neighbors because it has received new RPKI data. 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 in outbound signaling. + + Internet Exchange Points (IXPs) which provide Route Servers should be aware that some members