response to alvaro's discuss

draft-ietf-sidrops-rov-no-rr.xml

@@ -10,8 +10,8 @@
 
 <rfc category="std" consensus="true"
      submissionType="IETF" 
-     docName="draft-ietf-sidrops-rov-no-rr-02"
+     docName="draft-ietf-sidrops-rov-no-rr-04"
-     ipr="trust200902">
+     ipr="trust200902" updates="8481">
 
 <front>
 
@@ -80,10 +80,11 @@
     
     <t>
       A BGP Speaker performing RPKI-based policy should not issue Route
-      Refresh to its neighbors when receiving new RPKI data.  This
+      Refresh to its neighbors because it has received new RPKI data.
-      document describes avoiding doing so by either keeping a full
+      This document updates RFC8481 by describing how to avoid doing so
-      Adj-RIB-In or saving paths dropped due to ROV so they may be
+      by either keeping a full Adj-RIB-In or saving paths dropped due to
-      reevaluated with respect to new RPKI data.
+      ROV (Route Origin Validation) so they may be reevaluated with
+      respect to new RPKI data.
     </t>
     
   </abstract>
@@ -111,16 +112,17 @@
       Memory constraints in early BGP speakers caused classic <xref
       target="RFC4271"/> BGP implementations to not keep a full
       Adj-RIB-In (Sec. 1.1).  When doing RPKI-based Route Origin
-      Validation (<xref target="RFC6811"/> and <xref
+      Validation (ROV) (<xref target="RFC6811"/> and <xref
       target="RFC8481"/>), 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 <xref target="RFC7313"/> from its
+      then request a Route Refresh, <xref target="RFC2918"/> and <xref
-      neighbors to recover the paths which might be covered by these new
+      target="RFC7313"/>, from its neighbors to recover the paths which
-      RPKI data.  This will be perceived as rude by those neighbors as
+      might be covered by these new RPKI data.  This will be perceived
-      it passes a serious resource burden on to them.  This document
+      as rude by those neighbors as it passes a serious resource burden
-      recommends implementations keep and mark paths affected by
+      on to them.  This document recommends implementations keep and
-      RPKI-based policy so Route Refresh is no longer needed.
+      mark paths affected by RPKI-based policy so Route Refresh is no
+      longer needed.
     </t>
 
   </section>
@@ -166,48 +168,54 @@
       used, the problem will increase.
     </t>
 
+    <t>
+      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.
+    </t>
+
   </section>
   
   <section anchor="rib" title="Keeping Partial Adj-RIB-In Data">
 
     <t>
       Ameliorating this problem by keeping a full Adj-RIB-In can be a
-      problem for resource constrained BGP speakers.  In reality, only some
+      problem for resource constrained BGP speakers.  In reality, only
-      data need be retained.
+      some data need be retained.
     </t>
 
     <t>
-      When RPKI data cause one or more paths to be dropped due to ROV,
+      When RPKI data cause one or more paths to be dropped by operator
-      those paths MUST NOT be evaluated for best path, but MUST be saved
+      policy due to ROV, those paths MUST NOT be evaluated for best
-      (either separately or marked) so they may be reevaluated with
+      route, but MUST be saved (either separately or marked) so they may
-      respect to new RPKI data.
+      be reevaluated with respect to new RPKI data.
     </t>
 
     <t>
-      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.
     </t>
 
     <t>
-      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 <xref target="RFC8205"/>, 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.
     </t>
 
     <t>
-      As storing these paths could cause problems in resource
+      As storing these routes could cause problems in resource
-      constrained devices, there MUST be a knob allowing operator
+      constrained devices, there MUST be a global operation, CLI, YANG,
-      control of this feature.  Such a knob MUST NOT be per peer, as
+      ... allowing operator control of this feature.  Such a control
-      this could cause inconsistent behavior.
+      MUST NOT be per peer, as this could cause inconsistent behavior.
     </t>
 
     <t>
       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.
     </t>
 
    </section>
@@ -215,7 +223,7 @@
   <section anchor="ops" title="Operational Recommendations">
 
     <t>
-      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.
     </t>
@@ -227,7 +235,7 @@
 
     <t>
       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,16 +244,18 @@
     <t>
       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 <xref target="rib"/> should only be
+      Validation.  The equiptment should either be replaced with capable
-      used in very well known and controlled circumstances.
+      equipement or ROV not used.  I.e. the knob in <xref target="rib"/>
+      should only be used in very well known and controlled
+      circumstances.
     </t>
 
     <t>
       Operators using the specification in <xref target="rib"/> should
       be aware that a misconfigured neighbor might erroneously send a
-      massive number of paths, thus consuming a lot of memory.
+      massive number of paths, thus consuming a lot of memory.  Hence
-      Pre-policy filtering such as described in <xref
+      pre-policy filtering such as described in <xref
-      target="I-D.sas-idr-maxprefix-inbound"/> SHOULD be used to reduce
+      target="I-D.sas-idr-maxprefix-inbound"/> could be used to reduce
       this exposure.
     </t>
 
@@ -299,21 +309,22 @@
     
   <references title="Normative References">
     <?rfc include="reference.RFC.2119.xml"?>
+    <?rfc include="reference.RFC.2918.xml"?>
     <?rfc include="reference.RFC.4271.xml"?>
+    <?rfc include="reference.RFC.6811.xml"?>
     <?rfc include="reference.RFC.7313.xml"?>
     <?rfc include="reference.RFC.8174.xml"?>
-    <?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
+    <?rfc include="reference.RFC.8481.xml"?>
     </references>
 
   <references title="Informative References">
     <?rfc include="reference.RFC.6480.xml"?>
     <?rfc include="reference.RFC.6482.xml"?>
-    <?rfc include="reference.RFC.6811.xml"?>
     <?rfc include="reference.RFC.7947.xml"?>
     <?rfc include="reference.RFC.8205.xml"?>
-    <?rfc include="reference.RFC.8481.xml"?>
     <?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
     <?rfc include="reference.I-D.ietf-sidrops-aspa-verification.xml"?>
+    <?rfc include="reference.I-D.sas-idr-maxprefix-inbound.xml"?>
     </references>
 
 </back>