Re: [Sidrops] Format of ASPA RTR PDU

[Claudio Jeker <[e-mail]>]

On Tue, Nov 07, 2023 at 04:00:49PM +0100, Maria Matejka wrote:
> Hello!
> 
> While trying to implement ASPA in RTR, we got confused by § 5.12, ASPA PDU,
> as of draft-ietf-sidrops-8210bis-11. Bytes 2 and 3 are set to zero and bytes
> 10 and 11 are encoding Provider AS Count which can be inferred from the
> overall PDU length easily. Is there any good reason to have this redundant
> information inside the PDU? We are suggesting to move the Flags and AFI
> Flags to bytes 2 and 3 and to drop Provider AS Count completely. The
> Customer ASN would then start at byte 8 and Provider ASNs would start at
> byte 12.

To be honest, the RTR bits are nowhere close to be ready. Especially these
questions have been raised numerous times by various developers
implementing this draft but the authors seem to not listen.
Right now draft-ietf-sidrops-8210bis is holding up all of ASPA.
 
> Also, while writing this, there arose another question. Is there any
> significant difference between ASPA with only Provider AS Zero and ASPA with
> no Provider AS at all?

While theoretically true draft-ietf-sidrops-aspa-profile-16 states
in section 3:
    ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF ASID

So there must be at least one ASID in the ProviderASSet to be a valid ASPA
profile. Because of this I would not depend on a ASPA record with empty
ProviderASSet.

In OpenBGPD the parser of static ASPA tables does not allow empty
ProviderASSet but in the RTR code it currently does not treat an empty AS
count as an error. Now I would prefer if draft-ietf-sidrops-8210bis
properly states that there MUST be at least one Provider ASNs in the
payload. Since then there is no confusion possible.

-- 
:wq Claudio