On Fri, Jun 13, 2025 at 12:31:09PM +0200, André Grüneberg wrote: > For a lot of errors in UPDATE messages, it's perfectly fine to treat those > as an error and do Treat-as-withdraw (as described in RFC7606). This > includes checking the length of the OTC attribute. > I am not asking to see routes with protocol errors in the routing table. > > As far as I can see RFC9234 does not mandate handling a route leak with > Treat-as-widthdraw. It just refers to leaking routes to be ineligible (for > further use). > My understanding: a leaked route should be present in Adj-RIB-In, but not > into Loc-RIB.
You are right, we do not have clear concept of 'route is ineligible' and in most cases (like OTC mismatch or AS path loop) we do treat-as-withdraw. One exception is unresolvable next hop, which can be transient and therefore such route cannot be removed. This is handled by just setting it as unreachable and de-preferencing it in best path selection (but it would still be selected and announced if no other route is available). > I do understand that Bird does not follow the traditional path of other BGP > speakers and has no Adj-RIB-In/Out. That is true that we do not have Adj-RIB-In by default, but note that routes kept by BIRD in regular tables are not just Loc-RIB (as that would be just the selected best routes), but any routes that passed import filters. In that case changing the behavior to have explicit 'route is ineligible' and importing such routes (but not selecting or exporting them to other protocols) would make sense. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) "To err is human -- to blame it on a computer is even more so."
