Hi,
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.
A better example would be rather welcome, though, I think I have it correct now
with details from the list.
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.
But, I do think there might be a bug (though I might just understand the whole
thing wrong).
If we simply define:
```
aspa table aspas;
```
and then call a `aspa_check(aspas, ...., ...)` then I sometimes receive a
ASPA_VALID back, especially for paths with only 1 ASN.
This, while that table is really empty.
Checking the code:
https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-table.c#L356
There is a !found for the upstream edition, but in the end, the logic does not
account for a empty ASPA table, which could simply be because one lost the
connection to the RTR that supplies is (or stayrtr not providing currently any
entries...)
Which might cause an ASPA_VALID to come out, even though not a single ASPA
entry has been defined and as there are no entries the path cannot be 'surely
valid'... should that situation not be ASPA_UNKNOWN?
Maybe a meree check if 'tab' is empty at the top would be sufficient to
determine that it will always be unknown as we have no positive or negative
entries?
net_roa_check has a 'anything' variable to cover that situation it seems, which
causes ROA_INVALID : ROA_UNKNOWN which is the correct way IMHO. (correct and
nice use of inline macros there btw :) )
Greets,
Jeroen
