Hi Ondrej, On Fri, 13 Jun 2025 at 16:12, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Jun 13, 2025 at 12:31:09PM +0200, André Grüneberg wrote:
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).
Oops, it seems like I opened a can of worms. Looking at RFC4271 section 3.2 b), any route in Loc-RIB must have a resolvable next hop.
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.
IMO Loc-RIB is not only the best path, but accepted routes = those that passed the import filters. And RFC4271 does not mandate you to have a strict distinction between these tables, but uses those for explaining the logic.
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.
Thinking about all this, I can imagine an (internal) attribute that identifies ineligible (but otherwise valid) routes. Maybe values being a bit set for various reasons? 0x1 = next_hop unresolvable 0x2 = OTC route leak 0x4 = route damped ... As long as the attribute is non-zero, the route is not going anywhere (accept means reject). Of course, those of us feeling lucky could modify the value of the attribute in a filter. Would that be a major undertaking? We would not need the configuration parameters suggested by Maria (as non-Bird-developer :). The effects should be the same, unless someone programming filters (!= operator as per RFC9234) has any insane ideas. Have a pleasant weekend, André -- André Grüneberg, Managing Director andre.grueneberg@bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B