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 <[email protected]>
wrote:
> Hi Ondrej,
>
> On Fri, 13 Jun 2025 at 16:12, Ondrej Zajicek <[email protected]>
> 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
> [email protected]
> +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
>
--
André Grüneberg, Managing Director
[email protected]
+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
