Summary

  • In his 26 October RIPE 93 ASPA tutorial, RIPE NCC's Ondřej Caletka showed a BIRD filter that prepends the local ASN for a fuller path check.
  • His next slide gives the trap: on a lateral peer session, that extra ASN breaks upstream verification instead of revealing an omitted provider.

The extra ASN is a useful witness until it is invited to the wrong interview. In a customer session, adding the local network to the path being tested can reveal that the customer forgot to name it as a provider. In a transit session, it can expose the local network's own forgotten provider. Give the same treatment to a peer, and the check starts asking a sideways neighbour to behave like an upstream.

Ondřej Caletka's RIPE 93 tutorial on 26 October made that distinction concrete. His original slides date BIRD ASPA support to April 2026 releases 3.2.1, 3.1.6, 2.18.1 and 2.17.4. The transit example calls aspa_check(aspas, bgp_path.prepend(2121), false). The false selects downstream verification. The example rejects an invalid result, with a comment showing how an operator could print it during observation instead.

Why add ASN 2121? A received AS path normally stops at the BGP neighbour. The local AS will be added when a route is exported, yet the import-side ASPA calculation has not seen that local hop. Caletka's slide 57 lists two gaps this can leave: a customer has omitted you from its provider list, or you have omitted your transit provider from yours. Temporarily appending the local hop to the path being checked brings that edge into view. It is a validation input, not a claim that the incoming update already carried your ASN.

Slide 57 also carries the warning a copy-pasted filter will miss. A lateral peer is a peer, not your provider. In that session, prepending your ASN manufactures a hop that upstream verification cannot treat as a provider step. The BIRD team's own explainer spells out the practice: prepend for customer and provider checks; leave the peer's received path alone. It also says the IETF ASPA verification draft does not require this BIRD technique, relying on a separate check of the local relationship.

This is a route-policy ownership problem dressed as a one-line syntax change. The RIPE NCC guide requires accurate provider declarations and distinguishes providers from ordinary peers. A filter library needs the same distinction. If the neighbour-role inventory is wrong, a beautifully consistent template will consistently ask the wrong question. That is not the sort of consistency an operations team wants framed.

Original sources