Hello Jeroen,
I was checking the ASPA possibilities, and the is_upstream option of aspa_check definitely is confusing. The downstream/upstream variant also, as the logic seems reverse to what one would expect.
The draft defines downstream / upstream that way, so sorry for that confusion, I would also kinda prefer wording like "received from transit, only for my customers" and "just some parts of the internet behind this peer". Maybe we should add this as an alias to "downstream". Any preference for exact wording? Also, in BIRD 3 it is later going to be possible to infer this information from the BGP OTC setting. We don't have the right data structure for that yet tho.
A better example would be rather welcome, though, I think I have it correct now with details from the list.
It's quite a complicated matter. There are some better examples in <https://datatracker.ietf.org/meeting/122/materials/slides-122-sidrops-aspa-based-as-path-verification-examples-and-unit-tests-00>, and we are expecting to use and merge these with our documentation. (Contributions of this kind welcome, until somebody fixes this internally.) Would you appreciate even more than that example set?
It would also be useful if we could do something like we can do for RPKI:
print roa_check(rpki4, 84.205.83.0/24, 12654) = ROA_UNKNOWN; print roa_check(rpki4, 93.175.146.0/24, 12654) = ROA_VALID; print roa_check(rpki4, 93.175.147.0/24, 12654) = ROA_INVALID;
and that we could run a similar: print aspa_check(aspas, "54874 970", false) = ASPA_INVALID;
Currently though there is no datatype that would allow one to provide the BGP path thus that test would not be possible.
There is one, actually, but you have to build the BGP path like this: +empty+.prepend(970).prepend(54874) It's quite hard to make our filter syntax accept BGP path literals or constructors, but… now I'm thinking of something which might work, tho. (Internal note for the team: issue #209.) Have a nice day! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.