diff --git a/draft-ymbk-sidrops-rov-no-rr.xml b/draft-ymbk-sidrops-rov-no-rr.xml index 2ec445e..de632d2 100644 --- a/draft-ymbk-sidrops-rov-no-rr.xml +++ b/draft-ymbk-sidrops-rov-no-rr.xml @@ -10,7 +10,9 @@ - + @@ -119,47 +121,106 @@ Invalidated paths so the Route Refresh is no longer needed. + + +
+ + + It is assumed that the reader understands BGP, and Route Refresh , the + RPKI , Route Origin Authorizations (ROAs), + , The Resource Public Key Infrastructure + (RPKI) to Router Protocol , RPKI-based Prefix Validation, + , and Origin Validation Clarifications, + . + +
-
+
- - It is assumed that the reader understands BGP, and Route Refresh , the - RPKI , Route Origin Authorizations (ROAs), - , The Resource Public Key Infrastructure - (RPKI) to Router Protocol , RPKI-based Prefix Validation, - , and Origin Validation Clarifications, - . - + + As Route Origin Validation dropping Invalids has depoyed, some + router implementations have been found which, when receiving new + RPKI data (VRPs, see ) + issue a BGP Route Refresh to all sending + BGP peers so that it can reevaluate the received paths aginst the + new data. + -
+ + In actual deployment this has been found to be very destructive, + transferring a serious resource burden to the unsuspecting peers. + In reaction, RPKI based Route Origin Validation (ROV) has been + turned off; and there have been actual de-peerings. + + + + As RPKI registration and ROA creation have steadily increased, + this problem has increased, not just proportionally, but on the + order of the in-degree of ROV implementing routers. + + +
+ +
+ + + Ameliorating this problem by keeping a full Adj-RIB-In can be a + problem for resource constrained routers. In reality, only some + data need be retained. + + + + When RPKI data cause one or more paths to be dropped, withdrawn, + or merely not chosn as best path due to RPKI-based policy (ROV, + ASPA, etc.), those paths MUST be saved and marked so that later + VRPs can reevaluate them against then current policy. + + + + As storing these paths could cause problems in resource + constrained devices, there MUST be a knob allowing operator + control of this feature. Such a knob MUST NOT be per peer, as + this could cause inconsistent behavior. + + +
- Routers MUST either keep the full Adj-RIB-In or implement this - specification. + Routers MUST either keep the full Adj-RIB-In or implement the + specification in . - Operators deploying ROV SHOULD ensure that the router - implementation is not causing unnecessary Route Refresh requests - to neighbors. + Operators deploying ROV and/or other RPKI based policies SHOULD + ensure that the router implementation is not causing unnecessary + Route Refresh requests to neighbors. - If the router does not implement the recommendations here, the + If the router does not implement these recommendations, the operator SHOULD enable the vendor's knob to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration - inbound". The operator should then ensure that this stops - unnecessary Route Refresh requests to neighbors. + inbound". The operator should then measure to ensure that there + are no unnecessary Route Refresh requests sent to neighbors. If the router has insufficient resources to support this, it - MUST not be used for Route Origin Validation. + MUST not be used for Route Origin Validation. I.e. the knob in + should only be used in very well known and + controlled circumstances. + + + + Internet Exchange Points which provide + Route Servers 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.
@@ -167,9 +228,9 @@
- This document describes a denial of service Route Origin - Validation may place on a BGP neighbor, and describes how it may - be ameliorated. + This document describes a denial of service which Route Origin + Validation or other RPKI policy may place on a BGP neighbor, and + describes how it may be ameliorated. @@ -194,27 +255,26 @@ - - - - + + + + + -