Hi Ondrej, On Fri, 13 Jun 2025 at 16:12, Ondrej Zajicek <santi...@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.grueneb...@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
