first pass at dutch request changes
This commit is contained in:
parent
1a2da429b3
commit
9df447ea92
1 changed files with 39 additions and 47 deletions
|
|
@ -8,7 +8,7 @@
|
|||
<?rfc compact="yes"?>
|
||||
<?rfc subcompact="no"?>
|
||||
|
||||
<rfc category="std" docName="draft-ietf-sidrops-8210bis-13"
|
||||
<rfc category="std" docName="draft-ietf-sidrops-8210bis-14"
|
||||
submissionType="IETF" ipr="trust200902" version="2" consensus="yes">
|
||||
|
||||
<front>
|
||||
|
|
@ -92,8 +92,7 @@
|
|||
The transport protocol options are described in
|
||||
<xref target="Transport"/>. <xref target="Setup"/> details
|
||||
how routers and caches are configured to connect and authenticate.
|
||||
<xref target="Scenarios"/> describes likely deployment
|
||||
scenarios. The traditional security and IANA considerations end
|
||||
The traditional security and IANA considerations end
|
||||
the document.
|
||||
</t>
|
||||
<t>
|
||||
|
|
@ -481,10 +480,6 @@
|
|||
from a cache remains valid in the absence of a successful
|
||||
subsequent cache poll. See <xref target="timing"/>.
|
||||
</t>
|
||||
<t hangText="Provider AS Count:">
|
||||
A 16-bit count of Provider Autonomous System Numbers in
|
||||
the PDU.
|
||||
</t>
|
||||
<t hangText="Customer Autonomous System Number:">
|
||||
The 32-bit AS number of the Autonomous System that
|
||||
authorizes the upstream providers listed in the Provider
|
||||
|
|
@ -565,16 +560,22 @@
|
|||
<t>
|
||||
When replying to a Serial Query, the cache MUST return the
|
||||
minimum set of changes needed to bring the router into sync
|
||||
with the cache. That is, if a particular prefix or router
|
||||
key underwent multiple changes between the Serial Number
|
||||
specified by the router and the cache's current Serial
|
||||
Number, the cache MUST merge those changes to present the
|
||||
simplest possible view of those changes to the router. In
|
||||
general, this means that, for any particular prefix or
|
||||
router key, the data stream will include at most one
|
||||
withdrawal followed by at most one announcement, and if all
|
||||
of the changes cancel out, the data stream will not mention
|
||||
the prefix or router key at all.
|
||||
with the cache. That is, if a particular prefix, router key,
|
||||
or ASPA underwent multiple changes between the Serial Number
|
||||
specified by the router and the cache's current Serial Number,
|
||||
the cache MUST merge those changes to present the simplest
|
||||
possible view of those changes to the router. In general,
|
||||
this means that, for any particular prefix/AS, Router Key. or
|
||||
ASPA/Customer, the data stream will include at most one
|
||||
withdrawal followed by at most one announcement, and if all of
|
||||
the changes cancel out, the data stream will not mention the
|
||||
prefix/AS, Router Key, or ASPA/Customer at all.
|
||||
</t>
|
||||
<t>
|
||||
In the data responding to a Serial Query, should the router
|
||||
receive duplicate announcements or withdrawals, the router
|
||||
should raise an Error with Error Code 7, Duplicate
|
||||
Announcement Received.
|
||||
</t>
|
||||
<t>
|
||||
The rationale for this approach is that the entire purpose of
|
||||
|
|
@ -999,23 +1000,19 @@
|
|||
</section>
|
||||
|
||||
<section anchor="aspa" title="ASPA PDU">
|
||||
<!-- protocol "Protocol Version 2:8,PDU Type 11:8,zero:16,Length:32,Flags:8,Zero:8,Provider AS Count:16,Customer Autonomous System Number:32,Provider Autonomous System Numbers:32" -->
|
||||
<!-- protocol "Protocol Version 2:8,PDU Type 11:8,Flags:8,zero:8,Length:32,Customer Autonomous System Number:32,Provider Autonomous System Numbers:32" -->
|
||||
<figure>
|
||||
<artwork>
|
||||
0 8 16 24 31
|
||||
.-------------------------------------------.
|
||||
| Protocol | PDU | |
|
||||
| Version | Type | zero |
|
||||
| 2 | 11 | |
|
||||
| Protocol | PDU | | |
|
||||
| Version | Type | Flags | zero |
|
||||
| 2 | 11 | | |
|
||||
+-------------------------------------------+
|
||||
| |
|
||||
| Length |
|
||||
| |
|
||||
+-------------------------------------------+
|
||||
| | | |
|
||||
| Flags | zero | Provider AS Count |
|
||||
| | | |
|
||||
+-------------------------------------------+
|
||||
| |
|
||||
| Customer Autonomous System Number |
|
||||
| |
|
||||
|
|
@ -1062,14 +1059,7 @@
|
|||
If the announce/withdraw flag is set to 0, it indicates
|
||||
removal of the entire ASPA record for that Customer AS. Here,
|
||||
the customer AS of the ASPA record MUST be provided, the
|
||||
Provider AS Count must be zero, the Provider AS Numbers list
|
||||
MUST be null, and these last two fields MUST be ignored by the
|
||||
router.
|
||||
</t>
|
||||
|
||||
<t>
|
||||
The Provider AS Count is the number of 32-bit Provider
|
||||
Autonomous System Numbers in the PDU.
|
||||
Provider list MUST be null, and the PDU Length MUST be 12.
|
||||
</t>
|
||||
|
||||
<t>
|
||||
|
|
@ -1081,7 +1071,7 @@
|
|||
|
||||
<t>
|
||||
There are zero or more 32-bit Provider Autonomous System
|
||||
Number fields as indicated in the Provider AS Count; see <xref
|
||||
Number fields in increasing numeric order. See <xref
|
||||
target="I-D.ietf-sidrops-aspa-profile"/>.
|
||||
</t>
|
||||
|
||||
|
|
@ -1715,6 +1705,13 @@ Cache Router
|
|||
true at the point of connection loss if the client has
|
||||
connections to more than one cache.
|
||||
</t>
|
||||
<t>
|
||||
To keep load on Global RPKI services from unnecessary peaks, it
|
||||
is recommended that caches which fetch from the Global RPKI not
|
||||
do so all at the same times, e.g., on the hour. Choose a random
|
||||
time, perhaps the ISP's AS number modulo 60, and jitter the
|
||||
inter-fetch timing.
|
||||
</t>
|
||||
</section>
|
||||
|
||||
<section anchor="races" title="ROA PDU Race Minimization">
|
||||
|
|
@ -1746,6 +1743,7 @@ Cache Router
|
|||
</t>
|
||||
</section>
|
||||
|
||||
<!---
|
||||
<section anchor="Scenarios" title="Deployment Scenarios">
|
||||
<t>
|
||||
For illustration, we present three likely deployment
|
||||
|
|
@ -1785,14 +1783,8 @@ Cache Router
|
|||
deployment strategies. It is expected that minimizing load on
|
||||
the Global RPKI servers will be a major consideration.
|
||||
</t>
|
||||
<t>
|
||||
To keep load on Global RPKI services from unnecessary peaks, it
|
||||
is recommended that caches which fetch from the Global RPKI not
|
||||
do so all at the same times, e.g., on the hour. Choose a random
|
||||
time, perhaps the ISP's AS number modulo 60, and jitter the
|
||||
inter-fetch timing.
|
||||
</t>
|
||||
</section>
|
||||
-->
|
||||
|
||||
<section anchor="errorcodes" title="Error Codes">
|
||||
<t>
|
||||
|
|
@ -1865,12 +1857,12 @@ Cache Router
|
|||
sections.
|
||||
<list style="hanging">
|
||||
<t hangText="Cache Validation:">
|
||||
In order for a collection of caches as described in <xref
|
||||
target="Scenarios"/> to provide a consistent view, they need
|
||||
to be given consistent trust anchors of the Certification
|
||||
Authorities to use in their internal validation process.
|
||||
Distribution of a consistent trust anchor set to validating
|
||||
caches is assumed to be out of band.
|
||||
In order for a collection of caches to provide a consistent
|
||||
view, they need to be given consistent trust anchors of the
|
||||
Certification Authorities to use in their internal
|
||||
validation process. Distribution of a consistent trust
|
||||
anchor set to validating caches is assumed to be out of
|
||||
band.
|
||||
</t>
|
||||
<t hangText="Cache Peer Identification:">
|
||||
The router initiates a transport connection to a cache, which it
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue