<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Ondrej,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Jun 2025 at 16:12, Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 13, 2025 at 12:31:09PM +0200, André Grüneberg wrote:<br>> As far as I can see RFC9234 does not mandate handling a route leak with<br>
> Treat-as-widthdraw. It just refers to leaking routes to be ineligible (for<br>
> further use).<br>
> My understanding: a leaked route should be present in Adj-RIB-In, but not<br>
> into Loc-RIB.<br>
You are right, we do not have clear concept of 'route is ineligible' and in<br>
most cases (like OTC mismatch or AS path loop) we do treat-as-withdraw. One<br>
exception is unresolvable next hop, which can be transient and therefore such<br>
route cannot be removed. This is handled by just setting it as unreachable<br>
and de-preferencing it in best path selection (but it would still be selected<br>
and announced if no other route is available).<br></blockquote><div><br></div><div>Oops, it seems like I opened a can of worms.</div><div>Looking at RFC4271 section 3.2 b), any route in Loc-RIB must have a resolvable next hop.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I do understand that Bird does not follow the traditional path of other BGP<br>
> speakers and has no Adj-RIB-In/Out.<br>
That is true that we do not have Adj-RIB-In by default, but note that<br>
routes kept by BIRD in regular tables are not just Loc-RIB (as that would<br>
be just the selected best routes), but any routes that passed import<br>
filters. </blockquote><div><br></div><div>IMO Loc-RIB is not only the best path, but accepted routes = those that passed the import filters.</div><div>And RFC4271 does not mandate you to have a strict distinction between these tables, but uses those for explaining the logic.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In that case changing the behavior to have explicit 'route is ineligible' and importing such routes (but not selecting or exporting<br>
them to other protocols) would make sense.<br></blockquote><div><br></div><div><div>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?</div><div>0x1 = next_hop unresolvable</div><div>0x2 = OTC route leak</div><div>0x4 = route damped</div><div>...</div><div><br></div><div>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.</div><div><br></div><div>Would that be a major undertaking?</div><div>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.</div><div><br></div><div>Have a pleasant weekend,</div><div>André</div></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>
</div>
</div>
</div>
</div>