Concerning the structure of ASPA tables and AS0

[Ralph Covelli]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20241226/4e21b1bc/attachment.htm>