-19 pushed with jgs comments and small clean-ups

This commit is contained in:
Randy Bush 2025-04-10 13:24:20 -07:00
parent 092c4bcbec
commit 6213ecaaf5

View file

@ -8,7 +8,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-8210bis-18"
<rfc category="std" docName="draft-ietf-sidrops-8210bis-19"
submissionType="IETF" ipr="trust200902" version="2" consensus="yes">
<front>
@ -19,7 +19,7 @@
</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>IIJ Research, Arrcus, &amp; DRL</organization>
<organization>Arrcus, DRL, &amp; IIJ Research</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
@ -133,6 +133,9 @@
race conditions, Make Before Break and Shorter Prefix
First.
</t>
<t>
Optional ordering of payload PDUs has been added.
</t>
<t>
Language was clarified when multiple caches are
configured, and an interesting affect is noted.
@ -206,9 +209,9 @@
</t>
<t hangText="Payload PDU:">
A payload PDU is a protocol message which contains data for
use by the router, as opposed to a PDU which conveys the control
mechanisms of this protocol. Prefixes and Router Keys are
examples of payload PDUs.
use by the router, as opposed to a PDU which conveys the
control mechanisms of this protocol. IPvX Prefixes, Router
Keys, ASPA are examples of payload PDUs.
</t>
</list>
</t>
@ -1749,7 +1752,7 @@ Cache Router
especially an initial full load in response to a Reset Query PDU,
undesirable race conditions are possible:
<list style="hanging">
<t hangText="Break Before Make:">
<t hangText="Make Before Break:">
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
@ -1767,7 +1770,7 @@ Cache Router
sub-prefix of P0, a router which receives the ROA for P0
before that for P1 is likely to mark a BGP announcement of
prefix P1 invalid. Therefore, the cache SHOULD announce the
sub-prefix P1 before the covering prefix P0. Similarly, in
sub-prefix P1 before the covering prefix P0. Conversely, in
the case of withdrawals, the cache SHOULD withdraw covering
prefixes before their sub-prefixes.
</t>
@ -1783,8 +1786,8 @@ Cache Router
request until the relevant End of Data PDU is received.
</t>
<t>
However, a router MAY choose to apply a time limit for how long
it is willing to wait for the End of Data PDU.
However, a router MAY apply a time limit for how long it is
willing to wait for the End of Data PDU.
</t>
</t>
@ -1792,25 +1795,29 @@ Cache Router
<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:
A Version 2 Cache SHOULD, unless it requires major revision of
existing code, order payload PDUs (IPvX, Router Key, ASPA) it
sends to routers. Ascending order is considered somewhat more
efficient as routers are likely building trees. Iff ordering,
with the exceptions in <xref target="races"/> above, ordering MUST
be, as follows:
</t>
<list style="symbols">
<t>
PDU Type,
PDUs are first ordered by PDU Type,
</t>
<t>
Within prefix PDUs for the same prefix by Max Length and then
AS,
IPv4 and IPv6 Prefix PDUs are ordered by: first IPvX Prefix,
second Prefix Length, third Max Length, and fourth Autonomous
System Number. Treating AS 0 as sorting last fulfills the "AS 0
Last" requirement of <xref target="races"/>,
</t>
<t>
Router Keys ordered by AS Number and then Subject Public Key
Info, and
Router Keys are ordered by AS Number and then Subject Public Key
Info,
</t>
<t>
ASPA PDUs ordered by Customer AS.
And ASPA PDUs ordered by Customer AS.
</t>
</list>
<t>