Hi Maria, Ondrej, Bird community,

We have now (silently) implemented OTC handling in our route servers without setting the role in the protocol.

For the reference, we extended the ingress filter with:

define IXP_LC_FILTERED_ROUTE_LEAK_DETECTED = ( routeserverasn, 1101, 50 );
if defined( bgp_otc ) then {
bgp_large_community.add( IXP_LC_FILTERED_ROUTE_LEAK_DETECTED );
}

The egress filter (which already implicitly rejects routes with the community above) was enhanced with:

if ! defined( bgp_otc ) then {
bgp_otc = routeserverasn;
}

[actually it's a bit more complex, but this is due to non-standard route server features for BCIX Outreach]

BTW: I have already created a feature request for Alice-LG to display the OTC attribute (https://github.com/alice-lg/alice-lg/issues/174).

I'd really love to also announce the roles capability, but we'd need some way in Bird to say "do not treat-as-withdraw". Is there any chance we can get this functionality?

Best wishes,

André

On Fri, 13 Jun 2025 at 17:19, André Grüneberg <andre.grueneberg@bcix.de> wrote:

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