From 888b96c0b249e844efe1ba1ae6d5e2663260e20a Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 23 Aug 2022 08:54:14 -0700 Subject: [PATCH] response to alvaro's discuss --- draft-ietf-sidrops-rov-no-rr.xml | 89 ++++++++++++++++++-------------- 1 file changed, 50 insertions(+), 39 deletions(-) diff --git a/draft-ietf-sidrops-rov-no-rr.xml b/draft-ietf-sidrops-rov-no-rr.xml index 7cfa231..b8dbc73 100644 --- a/draft-ietf-sidrops-rov-no-rr.xml +++ b/draft-ietf-sidrops-rov-no-rr.xml @@ -10,8 +10,8 @@ + docName="draft-ietf-sidrops-rov-no-rr-04" + ipr="trust200902" updates="8481"> @@ -80,10 +80,11 @@ A BGP Speaker performing RPKI-based policy should not issue Route - Refresh to its neighbors when receiving new RPKI data. This - document describes avoiding doing so by either keeping a full - Adj-RIB-In or saving paths dropped due to ROV 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 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. @@ -111,16 +112,17 @@ Memory constraints in early BGP speakers caused classic BGP implementations to not keep a full Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin - Validation ( and and ), and similar RPKI-based policy, if such a BGP speaker receives new RPKI data, it might not have kept paths previously marked as Invalid etc. Such an implementation must - then request a Route Refresh from its - neighbors to recover the paths which might be covered by these new - RPKI data. This will be perceived as rude by those neighbors as - it passes a serious resource burden on to them. This document - recommends implementations keep and mark paths affected by - RPKI-based policy so Route Refresh is no longer needed. + then request a Route Refresh, and , from its neighbors to recover the paths which + might be covered by these new RPKI data. This will be perceived + as rude by those neighbors as it passes a serious resource burden + on to them. This document recommends implementations keep and + mark paths affected by RPKI-based policy so Route Refresh is no + longer needed. @@ -166,48 +168,54 @@ used, the problem will increase. + + Other mechanisms, such as automented policy provisioning, which + have flux rates similar to ROV (i.e. on the order of minutes), + could very well cause similar problems. + +
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. + problem for resource constrained BGP speakers. In reality, only + some data need be retained. - When RPKI data cause one or more paths to be dropped due to ROV, - those paths MUST NOT be evaluated for best path, but MUST be saved - (either separately or marked) so they may be reevaluated with - respect to new RPKI data. + When RPKI data cause one or more paths to be dropped by operator + policy due to ROV, those paths MUST NOT be evaluated for best + route, but MUST be saved (either separately or marked) so they may + be reevaluated with respect to new RPKI data. - If new RPKI data arrive which invalidate the best path, and the + 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 - path. + route. - Policy which may drop paths due to RPKI-based checks such as ROV, + Policy which may drop routes due to RPKI-based checks such as ROV, ASPA, BGPsec , etc. MUST be run, and the - dropped paths saved per the above paragraph, before non-RPKI + dropped routes saved per the above paragraph, before non-RPKI policies are run, as the latter may change path attributes. - 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. + 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. 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 - path selection and in outbound signaling. + route selection and in outbound signaling.
@@ -215,7 +223,7 @@
- Operators deploying ROV and/or other RPKI based policies SHOULD + 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. @@ -227,7 +235,7 @@ If the BGP speaker does not implement these recommendations, the - operator SHOULD enable the vendor's knob to keep the full + 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. @@ -236,21 +244,23 @@ If the BGP speaker has insufficient resources to support either of the two proposed options, it MUST NOT be used for Route Origin - Validation. I.e. the knob in should only be - used in very well known and controlled circumstances. + Validation. The equiptment should either be replaced with capable + equipement or ROV not used. I.e. the knob in + should only be used in very well known and controlled + circumstances. Operators using the specification in should be aware that a misconfigured neighbor might erroneously send a - massive number of paths, thus consuming a lot of memory. - Pre-policy filtering such as described in SHOULD be used to reduce + massive number of paths, thus consuming a lot of memory. Hence + pre-policy filtering such as described in could be used to reduce this exposure. - Internet Exchange Points (IXPs)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. @@ -299,21 +309,22 @@ + + - + - - +