alexander review

This commit is contained in:
Randy Bush 2021-02-06 16:26:24 -08:00
parent 5b0cc37ca5
commit b733b2334c

View file

@ -10,7 +10,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-8210bis-01" updates="8210" ipr="trust200902">
<rfc category="std" docName="draft-ietf-sidrops-8210bis-02" updates="8210" ipr="trust200902">
<front>
@ -75,7 +75,7 @@
platforms.
</t>
<t>This document updates <xref target="RFC6810"/>.</t>
<t>This document updates <xref target="RFC8210"/>.</t>
<t>
<xref target="Struct"/> describes the deployment structure, and
@ -110,14 +110,14 @@
<section title="Changes from RFC 8210">
<t>
This section summarizes the significant changes between
<xref target="RFC6810"/> and the protocol described in this
<xref target="RFC8210"/> and the protocol described in this
document.
</t>
<t>
<list style="symbols">
<t>
New ASPA PDU type (<xref target="aspa"/>) added to support
<xref target="I-D.ietf-sidrops-aspa-profile"/>.
A new ASPA PDU type (<xref target="aspa"/>) has added to
support <xref target="I-D.ietf-sidrops-aspa-profile"/>.
</t>
<t>
A small section, <xref target="races"/>, has been added to
@ -125,8 +125,9 @@
Shorter Prefix First.
</t>
<t>
Protocol version number incremented from 1 (one) to 2
(two).
The protocol version number incremented from 1 (one) to 2
(two) and the <xref target="version"/> section has been
updated accordingly.
</t>
</list>
</t>
@ -526,7 +527,7 @@
<t>
The rationale for this approach is that the entire purpose of
the RPKI&nbhy;Router protocol is to offload work from the router
to the cache, and it should therefore be the cache's job to
to the cache, and it should therefor be the cache's job to
simplify the change set, thus reducing work for the router.
</t>
<t>
@ -974,10 +975,15 @@
same Customer Autonomous System Number and the same Address
Family (see Flags field), replaces the previous one. This is to
avoid a race condition when a BGP announcement is received
between an withdrawn PDU and a new announced PDU. Therfore, the
cache SHOULD deliver entire data of an ASPA record in a single
between an withdrawn PDU and a new announced PDU. Therefor, the
cache MUST deliver entire data of an ASPA record in a single
ASPA PDU.
</t>
<t>The router should only see one ASPA for a particular Customer
Autonomous System Number active at any time. This may place a
burden on the cache to merge multiple ASPA records it has
received from the global RPKI into one ASPA PDU.
</t>
<t>
The Flags field is defined as follows:</t>
<figure>
@ -1090,39 +1096,41 @@
which version of this protocol the router implements.
</t>
<t>
If a cache which supports version 1 receives a query from a
router which specifies version 0, the cache MUST downgrade to
protocol version 0 <xref target="RFC6810"/> or send a version
1 Error Report PDU with Error Code 4 ("Unsupported Protocol
Version") and terminate the connection.
If a cache which supports version N receives a query from a
router which specifies version Q &lt; N, the cache MUST downgrade
to protocol version Q <xref target="RFC6810"/> or <xref
target="RFC8210"/> or send a version 1 Error Report PDU with
Error Code 4 ("Unsupported Protocol Version") and terminate the
connection.
</t>
<t>
If a router which supports version 1 sends a query to a cache
which only supports version 0, one of two things will happen:
If a router which supports version N sends a query to a cache
which only supports version C &lt; N, one of two things will
happen:
<list style="numbers">
<t>
The cache may terminate the connection, perhaps with a
version 0 Error Report PDU. In this case, the router MAY
retry the connection using protocol version 0.
retry the connection using protocol version C.
</t>
<t>
The cache may reply with a version 0 response. In this
case, the router MUST either downgrade to version 0 or
The cache may reply with a version C response. In this
case, the router MUST either downgrade to version C or
terminate the connection.
</t>
</list>
</t>
<t>
In any of the downgraded combinations above, the new features
of version 1 will not be available, and all PDUs will have 0
in their version fields.
In any of the downgraded combinations above, the new features of
the hogher version will not be available, and all PDUs will have
the negotiated lower version number in their version fields.
</t>
<t>
If either party receives a PDU containing an unrecognized
Protocol Version (neither 0 nor 1) during this negotiation, it
MUST either downgrade to a known version or terminate the
connection, with an Error Report PDU unless the received PDU
is itself an Error Report PDU.
Protocol Version (neither 0, 1, nor 2) during this negotiation,
it MUST either downgrade to a known version or terminate the
connection, with an Error Report PDU unless the received PDU is
itself an Error Report PDU.
</t>
<t>
The router MUST ignore any Serial Notify PDUs it might receive
@ -1140,9 +1148,9 @@
</t>
<t>
Caches SHOULD NOT send Serial Notify PDUs before version
negotiation completes. Routers, however, MUST handle
such notifications (by ignoring them) for backwards
compatibility with caches serving protocol version 0.
negotiation completes. Routers, however, MUST handle such
notifications (by ignoring them) for backwards compatibility
with caches serving protocol version 0.
</t>
<t>
Once the cache and router have agreed upon a Protocol Version
@ -1829,7 +1837,7 @@ Cache Router
<t>
This section only discusses updates required in the existing
IANA protocol registries to accommodate version 1 of this
protocol. See <xref target="RFC6810"/> for IANA considerations
protocol. See <xref target="RFC8210"/> for IANA considerations
from the original (version 0) protocol.
</t>
<t>
@ -1907,6 +1915,7 @@ Cache Router
<?rfc include="reference.RFC.8126"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8208"?>
<?rfc include="reference.RFC.8210"?>
<?rfc include="reference.I-D.ietf-sidrops-aspa-profile"?>
</references>