Relaxed handling of OTC attribute

[André Grüneberg]

Hi Ondrej,

On Fri, 13 Jun 2025 at 16:12, Ondrej Zajicek <santiago at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250613/a50f05f6/attachment.htm>