randy/draft-8210bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

-05 published, revives Flags.[ann|del]

Browse source
This commit is contained in:
Randy Bush 2021-12-22 17:34:51 -08:00
parent f5502b5b62
commit 37817df455
1 changed files with 26 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

46
draft-ietf-sidrops-8210bis.xml
View file

@ -10,7 +10,7 @@
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-8210bis-04" updates="8210" ipr="trust200902" consensus="yes">
<rfc category="std" docName="draft-ietf-sidrops-8210bis-05" obsoletes="8210" ipr="trust200902" consensus="yes">
<front>
@ -973,13 +973,13 @@
target="I-D.ietf-sidrops-aspa-profile"/>. An ASPA PDU
represents one single customer AS and its provider ASs for a
particular Address Family. Receipt of an ASPA PDU
announcement when the router already has an ASPA PDU with the
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. Therefore,
the cache MUST deliver entire data of an ASPA record in a
single ASPA PDU.
announcement (Flag.Announce == 1) when the router already has
an ASPA PDU with the 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. Therefore, the cache MUST deliver the complete
data of an ASPA record in a single ASPA PDU.
</t>
<t>
@ -987,9 +987,9 @@
particular Customer Autonomous System Number active at any
time. As a number of conditions in the global RPKI may
present multiple valid ASPA objects for a single customer to a
particular RP cache, this places a burden on the cache to
merge multiple ASPA records it has received from the global
RPKI into one ASPA PDU.
particular RP cache, this places a burden on the cache to form
the union of multiple ASPA records it has received from the
global RPKI into one ASPA PDU.
</t>
<t>
@ -999,7 +999,8 @@
Bit Bit Name
---- -------------------
0 AFI (IPv4 == 0, IPv6 == 1)
1-7 Reserved, must be zero
1 Announce == 1, Delete == 0
2-7 Reserved, must be zero
</artwork>
</figure>
@ -1010,20 +1011,25 @@
<t>
The Customer Autonomous System Number is the 32-bit Autonomous
System Number of the customer which signed the PDU. There
MUST be one and only one ASPA for a Customer Autonomous System
Number active in the router at any time.
System Number of the customer which authenticated the PDU.
There MUST be one and only one ASPA for a Customer Autonomous
System Number active in the router at any time.
</t>
<t>
There are one or more 32-bit Provider Autonomous System Number
fields; see <xref target="I-D.ietf-sidrops-aspa-profile"/>.
There are zero or more 32-bit Provider Autonomous System
Number fields as indicated in the Provider AS Count; see <xref
target="I-D.ietf-sidrops-aspa-profile"/>.
</t>
<t>
Receipt of an ASPA PDU with zero providers is an implicit
withdraw of the entire ASPA data for that customer AS from
that cache.
Receipt of an ASPA PDU with the Flags field indicating Delete
is an explicit withdraw from the router of the entire ASPA
data for that customer AS. While the Provider AS Count and
the Provider AS Numbers MUST BE ignored by the router when the
Flags field indicates a Delete, the cache SHOULD set the
Provider AS Count to zero, and have a null Provider AS Numbers
list.
</t>
</section>