Hello Maria!
Thank you for taking the time to read my email.
Yes, "I have no providers" is a much more accurate description of AS 0.
It can be used by tier 1 networks as well as people trying to depreciate
their old ASN. It looks like the source of my confusion was that I was
under the assumption that the transit ASPA entries could be used to
auto-detect upstream vs downstream as opposed to doing the check in the
filter script. Sorry about that!
Thank you for fixing the problem with the static ASPA changes!!
I noticed in aspa_check() you check for confeds but AS_PATH_SET is never
checked for.
The specs say they should return ASPA_INVALID however I noticed when I
did that I lost about 64 routes which caused some customer complaints.
I had to end up slightly changing the code to return ASPA_INVALID if
upstream and ASPA_UNKNOWN if downstream.
Thank you!
Ralph
On 12/26/2024 6:04 AM, Maria Matejka via Bird-users wrote:
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.
