Re: [Sidrops] Which 8210-bis error code should be used?

[Claudio Jeker <[e-mail]>]

On Thu, Jun 08, 2023 at 06:53:41AM +0000, gengnan wrote:
> Hi,
> 
> (Want to confirm another 8210bis error code usage in this thread..)
> 
> The two descriptions in the 8210bis draft below look like inconsistent.
> (Through reading the codes) Openbgpd seems to follow the first
> description, i.e., "replacing". 
> If "replacing" is the correct understanding, why not IPvX PDU and Router
> Key PDU take the "replacing" action?  

I followed 5.12 that is very clear that an announce will replace the ASPA
record. The section is also emphasing that the ASPA PDU lookup is not
using the Provider Autonomous System Numbers or Provider AS Count as
information to lookup the record:
    The router MUST see at most one ASPA for a given AFI from a cache for a
    particular Customer Autonomous System Number active at any time.

So there is a difference in behaviour here regarding the other PDUs.
For IPvX PDU and Router Key PDU track one element and the full element is
used as key in the lookup (there is no extra data).

The ASPA PDU did not do that. It aggreagtes all the Provider Autonomous
System Numbers into a single object (extra data). To simplify update
operation the replace method was added. The alternative would be to update
an ASPA record by issuing a withdraw of the old record and announce of the
new record. This can result in Break Before Make issues.

For IPvX PDUs this problem is delegated to the RTR cache to order the
updates properly. For Router Key there is nothing in place right now
mainly because there is no experience with it. My assumption is that
Section 11 will need to be extended for Router Key consideration at some
point. In the case for Router Keys this may be delegated all the way up to
the CA to perform proper key roll over procedures (so it may not be needed
inside RTR itself).

RTR is lacking all the transactional awareness that databases normally
need to be ACID compliant. This lack of basic isolation is a big problem
of RTR and the reason for special workarounds (Section 11).

In OpenBGPD we try to make all Payload PDU updates between Cache Response
and End of Data PDU to appear atomic but if the End of Data PDU is not
received in reasonable time (60 sec) this atomicity is not guaranteed.
This works as long as the RTR cache is not spreading connected PDUs
over multiple incremental updates.
 
> Description 1: 
> "
> Receipt of an ASPA PDU announcement (announce/withdraw flag == 1) when the router already has an ASPA PDU with the same Customer Autonomous System Number and the same Address Family (see AFI Flags field), replaces the previous one.
> "
> Description 2: 
> "
> Duplicate Announcement Received (fatal):
> The received PDU has Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a Router Key PDU), or Customer Autonomous System for an ASPA PDU is already active in the router.
> "

The additon of ASPA PDU text in Description 2 (Section 13. Error Codes)
needs to be removed since there is no way to have a duplicate announcement
based on the text in Section 5.12
Now one could argue that sending an ASPA PDU to replace the current PDU
that is exactly the same should trigger this error but what do we gain
from that?

-- 
:wq Claudio