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

-04 published with brutal withdraw and no Add/With Flag

Browse source
This commit is contained in:
Randy Bush 2021-12-06 18:27:57 -08:00
parent d668de82a0
commit f5502b5b62
1 changed files with 41 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

61
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-03" updates="8210" ipr="trust200902" consensus="yes">
<rfc category="std" docName="draft-ietf-sidrops-8210bis-04" updates="8210" ipr="trust200902" consensus="yes">
<front>
@ -65,7 +65,7 @@
<section anchor="Intro" title="Introduction">
<t>
In order to verifiably validate the origin Autonomous Systems
(ASes) and AS paths of BGP announcements, routers need a
(ASs) and AS paths of BGP announcements, routers need a
simple but reliable mechanism to receive cryptographically
validated Resource Public Key Infrastructure (RPKI)
<xref target="RFC6480"/> prefix origin data and router keys
@ -967,54 +967,65 @@
~-------------------------------------------~
</artwork>
</figure>
<t>The ASPA PDU is to support <xref
<t>
The ASPA PDU is to support <xref
target="I-D.ietf-sidrops-aspa-profile"/>. An ASPA PDU
represents one single customer AS and one or more provider ASs
for a particular Address Family. Receipt of 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.
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.
</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>
The router should see at most one ASPA from a cache for a
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.
</t>
<t>
The Flags field is defined as follows:</t>
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 Announce/Withdraw (ann == 1, with == 0)
1 AFI (IPv4 == 0, IPv6 == 1)
2-7 Reserved, must be zero
0 AFI (IPv4 == 0, IPv6 == 1)
1-7 Reserved, must be zero
</artwork>
</figure>
<t>
The Provider AS Count is the number of Provider Autonomous
System Number(s) at the end of the PDU, and MUST be one or
more.
The Provider AS Count is the number of 32-bit Provider
Autonomous System Numbers in the PDU.
</t>
<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.
</t>
<t>
The Provider AS Count is the number of 32-bit Provider
Autonomous System Numbers in the PDU. It MUST be one or
greater.
</t>
<t>
There are one or more 32-bit Provider Autonomous System Number
fields; 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.
</t>
</section>
</section>