added secion on merging updates

-17 published

draft-ietf-sidrops-8210bis.xml

@@ -8,7 +8,7 @@
 <?rfc compact="yes"?>
 <?rfc subcompact="no"?>
 
-<rfc category="std" docName="draft-ietf-sidrops-8210bis-17"
+<rfc category="std" docName="draft-ietf-sidrops-8210bis-18"
      submissionType="IETF" ipr="trust200902" version="2" consensus="yes">
 
   <front>
@@ -728,14 +728,6 @@
           The lowest-order bit of the Flags field is 1 for an
           announcement and 0 for a withdrawal.
         </t>
-	<!--
-        <t>
-          In the RPKI, nothing prevents a signing authority from issuing
-          multiple ROAs with semantically identical payloads.  In this
-          case, there would be no semantic difference between the
-          objects, merely a process redundancy.
-        </t>
-	-->
         <t>
           In the RPKI, there is an actual need for what might appear to
           a router as identical IPvX PDUs.  This can occur when an
@@ -748,12 +740,17 @@
         </t>
         <t>
           The cache server MUST ensure that it has told the router
-          client to have one and only one IPvX PDU for a unique {Prefix,
+          client to have one and only one IPvX VRP for a unique {Prefix,
           Len, Max-Len, AS} at any one point in time.  Should the
-          router client receive an IPvX PDU with a {Prefix, Len,
+          router client receive an IPvX VRP with a {Prefix, Len,
           Max-Len, AS} identical to one it already has active, it
           SHOULD raise a Duplicate Announcement Received error.
         </t>
+	<t>
+	  The cache MUST merge announce/withdraw ROAs for the same
+	  {Prefix, Len, Max-Len, AS} into the minimal (or no) VRP to
+	  update the router to to the desired state.
+	</t>
         </section>
 
       <section anchor="ipv6" title="IPv6 Prefix">
@@ -1471,7 +1468,8 @@ Cache                         Router
 	(e.g. the peer advertised a TCP RCV.WND <xref target="RFC793"/>
 	<xref target="RFC9293"/> of zero) for longer than three times
 	the Retry Interval (a la BGP's hold timer being three times the
-	keepalive interval), the transport session should be terminated.
+	keepalive interval), an Error PDU 10, Transport Failure, should
+	be sent and the transport session should be terminated.
       </t>
       <t>
 	A cache SHOULD NOT use a separate TCP segment for each PDU, but
@@ -1753,14 +1751,15 @@ Cache                         Router
       <list style="hanging">
 	<t hangText="Break Before Make:">
 	  For some prefix P, an operator may create two or more ROAs
-	  with different ASes because they are in the process of changing
-	  what provider AS may announce P.  This is a case of "make
-	  before break."  If a cache is feeding a router and sends the
-	  one not yet in service a significant time before sending the
-	  one currently in service, then BGP data could be marked
+	  with different ASes because they are in the process of
+	  changing what provider AS may announce P.  This is a case of
+	  "make before break."  If a cache is feeding a router and sends
+	  the one not yet in service a significant time before sending
+	  the one currently in service, then BGP data could be marked
 	  invalid during the interval.  To minimize that interval, the
-	  cache SHOULD announce all ROAs for the same prefix as close to
-	  sequentially as possible.
+	  cache SHOULD announce all VRPs for the same prefix as close to
+	  sequentially as possible, and announce new VRPs for a prefix
+	  before any withdraws,
 	</t>
 	<t hangText="Shorter Prefix First:">
 	  If an operator has created a ROA for P0, and another operator
@@ -1772,6 +1771,11 @@ Cache                         Router
 	  the case of withdrawals, the cache SHOULD withdraw covering
 	  prefixes before their sub-prefixes.
 	</t>
+	<t hangText="AS 0 Last:">
+	  To minimize risk of inadvertent marking of BGP data as
+	  invalid, a prefix PDU for prefix P which has an AS of 0,
+	  SHOULD be sent after all other prefix PDUs for prefix P.
+	</t>
       </list>
       <t>
 	In order to further mitigate such race conditions, a router MAY
@@ -1786,7 +1790,36 @@ Cache                         Router
     
     </section>
 	  
-<!---
+  <section anchor="ordering" title="PDU Ordering">
+    <t>
+      A Version 2 Cache SHOULD order payload PDUs it sends to routers.
+      Ascending order is considered somewhat more efficient as routers
+      are likely building trees.  With the exceptions in <xref
+      target="races"/> above, ordering SHOULD be, as follows:
+    </t>
+    <list style="symbols">
+      <t>
+	PDU Type,
+      </t>
+      <t>
+	Within prefix PDUs for the same prefix by Max Length and then
+	AS,
+      </t>
+      <t>
+	Router Keys ordered by AS Number and then Subject Public Key
+	Info, and
+      </t>
+      <t>
+	ASPA PDUs ordered by Customer AS.
+      </t>
+    </list>
+    <t>
+      Routers MUST NOT depend on payload PDU ordering.
+    </t>
+      
+    </section>
+	  
+ <!---
     <section anchor="Scenarios" title="Deployment Scenarios">
       <t>
         For illustration, we present three likely deployment
@@ -1891,6 +1924,10 @@ Cache                         Router
             The received ASPA PDU has an incorrect list of Provider
 	    Autonomous System Numbers.
           </t>
+          <t hangText="10: Transport Error (fatal):">
+	    An error such as a stall (see <xref target="Transport"/>) or
+	    tother transport layer failure occurred.
+          </t>
         </list>
       </t>
 
@@ -2005,7 +2042,8 @@ Cache                         Router
 	      7   Duplicate Announcement Received
 	      8   Unexpected Protocol Version
 	      9   ASPA Provider List Error
-	 10-254   Unassigned
+	     10   Transport Failure
+	 11-254   Unassigned
 	    255   Reserved
         </artwork>
       </figure>