Hello, Earlier this week, while building a BGP lab I've discovered a weird behavior with aspa_check() that was rejecting routes that should be correct. It seems to be the same bug as https://trubka.network.cz/pipermail/bird-users/2026-February/018611.html. I discover that the previous implementation of the verification algorithm was not fully compliant with the current internet draft (draft-ietf-sidrops-aspa-verification-24) and could incorrectly filter routes when the up-ramp and down-ramp apex were apart by exactly one hop. In practice, this caused legitimate routes to be dropped, such as routes involving Tier-1 peering while having an AS0 ASPA record. One of my test sample was the following AS_PATH: 10846, 7018, 174, 29075, 208627 with the following ASPA records: - AS208627 => AS29075 - AS174 => 0 - AS7018 => 0 - AS10846 => 7018 If you manually compute the upstream and downstream bounds, you get - max_down = 5 - 3 + 1 = 3 - min_down = 5 - 4 + 1 = 2 - max_up = 2 - min_up = 2 Using the downstream algorithm: - max_up + max_down = 5 >= N, so the route is not invalid and we continue - min_up + min_down = 4 < N, so the route is unknown If you draw this on paper, it makes sense. However, BIRD reports this route as invalid, which is unexpected. Given this issue, I tried to implement a patch. With a bit of help of Alarig, I managed to get a working version that still passes the existing unit tests (except one) as well as our corner case. While I tried to understand the initial logic, it was quite hard to follow. Therefore, I tried, as much as possible, to follow the algorithm from the I.D. Something not trivial since the AS_PATH is reversed compared to the draft. This patch also contains few documentation comments. While I am not usually a big fan of comments, I think these are needed to highlight the differences between our implementation and the algorithm specified in the Internet-Draft. To improve unit test coverage, I have added the missing test cases from the official list (https://raw.githubusercontent.com/ksriram25/IETF/main/ASPA_path_verification...). They all passed successfully. However, one of the existing custom unit tests did not pass. In this test, the path consists of two ASes: 65544, 65541. AS65544 declare an AS0 ASPA and AS65541 declare AS65545 as a provider. The test expects the route to be invalid. However, I believe this expectation is incorrect. Manual computation gives: - min_up = 1 - max_up = 1 - max_down = 2 - 2 + 1 = 1 - min_down = 2 - 2 + 1 = 1 Using the downstream algorithm: - max_up + max_down = 2 >= N, so the route is not invalid and we continue - min_up + min_down = 2 >= N, so the route is not unknown, and therefore the route is valid. This actually makes sense: although there is no explicit valid ASPA, from a downstream perspective, this can be interpreted as a peering relationship between AS65544 and AS65541 (with the up-ramp and down-ramp apexes separated by exactly one hop), and the route should therefore be considered valid (see: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-2...). Don't hesitate to discuss the patch if needed, -- Evann