alexander review
This commit is contained in:
parent
5b0cc37ca5
commit
b733b2334c
1 changed files with 40 additions and 31 deletions
|
|
@ -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 < 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 < 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>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue