Hello Ralph,

Issue #1)  There is no way to tell the difference between a transit entry and an “AS0” entry.

There is no difference between a transit entry and an AS0 entry. The transit keyword is just a syntactic shortcut for provider 0.

The treatment of AS0 providers is mentioned in section 5 of draft-ietf-sidrops-aspa-verification-19.  It is a mechanism for people to announce that “no one should announce this AS”.  I’ve attached a snapshot of the global ASPA table as “bird-aspa-v2.16.conf”.  There is one AS0 announcement as of today.

No, it isn’t. It’s a mechanism to say “I have no providers”, as written in section 5 of the draft:

Registering as AS0 ASPA is a statement by the registering AS that it has no transit providers (…)

This effectively means that in a valid AS Path, there may be:

• no AS with AS0 ASPA
• a single AS with AS0 ASPA
• two adjacent AS’s with AS0 ASPA

I fell probably exactly into the same trap when reading the drafts first time, and the draft authors had to explain the principles to me several times in person for me to get it right. I tried to fix that by suggesting a different wording, please check this (long) message in sidrops:

https://mailarchive.ietf.org/arch/msg/sidrops/LE_nPFL6XFnIKE-25O9WIfZ-YFI/

Issue #2)  Changes in static ASPA tables are not reflected until entries are removed and re-added.

Thanks, fixed: https://gitlab.nic.cz/labs/bird/-/commit/1e685bbc2a7411c09b6c80404c49a410d6c47a2a

This problem does not occur when the ASPA elements are customer-provider pairs.  I believe this is an overall design issue, not a simple bug.  I will be bringing this issue up with ietf-sidrops.

There were massive data consistency problems in BIRD 3 when the ASPA elements were customer-provider pairs, and we won’t go back there.

Also, both the configuration and the in-table storage is more memory-greedy with the pairs storage.

Have a nice end-of-the-year! Maria

–
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.