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

["Borchert, Oliver (Fed)" <[e-mail]>]

On 6/8/23, 6:09 AM, "Sidrops" <[e-mail]> wrote:

>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?

The replacing action was introduced with the ASPA PDU. Up until then
the add and withdrawal was used and still is for all PDU’s other than ASPA.

>
>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.

Randy and I had some long discussion about that back in Nov. 2011.
https://mailarchive.ietf.org/arch/browse/sidrops/?q=2021-11

look for “[Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021”

>
>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

Not for ASPA PDU but it is still an error for 5.6, 5.7, and 5.10

>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

Oliver