a lot of new text to respond to hilliard and maddison

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

@@ -10,7 +10,9 @@
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 
-<rfc category="info" docName="draft-ymbk-sidrops-rov-no-rr-01" ipr="trust200902">
+<rfc category="std" consensus="true"
+     docName="draft-ymbk-sidrops-rov-no-rr-02"
+     ipr="trust200902" updates="8481">
 
 <front>
 
@@ -136,30 +138,89 @@
 
    </section>
 
+  <section anchor="experience" title="ROV Experience">
+
+    <t>
+      As Route Origin Validation dropping Invalids has depoyed, some
+      router implementations have been found which, when receiving new
+      RPKI data (VRPs, see <xref target="I-D.ietf-sidrops-8210bis"/>)
+      issue a BGP Route Refresh <xref target="RFC7313"/> to all sending
+      BGP peers so that it can reevaluate the received paths aginst the
+      new data.
+    </t>
+
+    <t>
+      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.
+    </t>
+
+    <t>
+      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.
+    </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 routers.  In reality, only some
+      data need be retained.
+    </t>
+
+    <t>
+      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.
+    </t>
+
+    <t>
+      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.
+    </t>
+
+   </section>
+
   <section anchor="ops" title="Operational Recommendations">
 
     <t>
-      Routers MUST either keep the full Adj-RIB-In or implement this
+      Routers MUST either keep the full Adj-RIB-In or implement the
-      specification.
+      specification in <xref target="rib"/>.
     </t>
 
     <t>
-      Operators deploying ROV SHOULD ensure that the router
+      Operators deploying ROV and/or other RPKI based policies SHOULD
-      implementation is not causing unnecessary Route Refresh requests
+      ensure that the router implementation is not causing unnecessary
-      to neighbors.
+      Route Refresh requests to neighbors.
     </t>
 
     <t>
-      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
+      inbound".  The operator should then measure to ensure that there
-      unnecessary Route Refresh requests to neighbors.
+      are no unnecessary Route Refresh requests sent to neighbors.
     </t>
 
     <t>
       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
+      <xref target="rib"/> should only be used in very well known and
+      controlled circumstances.
+    </t>
+
+    <t>
+      Internet Exchange Points which provide <xref target="RFC7947"/>
+      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.
     </t>
 
   </section>
@@ -167,9 +228,9 @@
   <section anchor="Security" title="Security Considerations">
 
     <t>
-      This document describes a denial of service Route Origin
+      This document describes a denial of service which Route Origin
-      Validation may place on a BGP neighbor, and describes how it may
+      Validation or other RPKI policy may place on a BGP neighbor, and
-      be ameliorated.
+      describes how it may be ameliorated.
     </t>
     
     <t>
@@ -194,27 +255,26 @@
   <references title="Normative References">
     <?rfc include="reference.RFC.2119.xml"?>
     <?rfc include="reference.RFC.4271.xml"?>
-    <?rfc include="reference.RFC.6482.xml"?>
-    <?rfc include="reference.RFC.6811.xml"?>
     <?rfc include="reference.RFC.7313.xml"?>
     <?rfc include="reference.RFC.8174.xml"?>
-    <?rfc include="reference.RFC.8481.xml"?>
-    <?rfc include="reference.I-D.ietf-sidrops-8210bis.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.8481.xml"?>
+    <?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
     </references>
 
-<!--
   <section anchor="Acknowledgements" title="Acknowledgements">
       
     <t>
-      The authors wish to thank Philip Smith and Mark Tinka.
+      The authors wish to thank Ben Maddison and Nick Hilliard.
     </t>
     
   </section>
--->
 
 </back>