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