Relaxed handling of OTC attribute

[André Grüneberg]

Hi Maria,

I was considering your "personal speculation" and came to the conclusion
that I agree, this should not be implemented.

For a lot of errors in UPDATE messages, it's perfectly fine to treat those
as an error and do Treat-as-withdraw (as described in RFC7606). This
includes checking the length of the OTC attribute.
I am not asking to see routes with protocol errors in the routing table.

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.

I do understand that Bird does not follow the traditional path of other BGP
speakers and has no Adj-RIB-In/Out. In a multi-table route server setup
Adj-RIB-In/Out is mimicked by the per-peer-table. In a single-table setup,
the leaked route would go into the main table.
So the question is: Could you imagine another way (i.e. different from
Treat-as-withdraw) of handling "ineligible" routes?

How do you treat routes that do not pass next-hop lookup? Shouldn't these
be ineligible as well? How about doing something similar for "ineligible by
OTC"?

Best regards,
André


On Fri, 13 Jun 2025 at 00:50, Maria Matejka <maria.matejka at nic.cz> wrote:

> Hello André,
>
> there is no such feature you are looking for.
>
> The rest of this message is my personal speculation which I may just later
> say strict no-no-no-never to after discussing with the rest of the team.
>
> I'm thinking about a controversial approach, kinda disgusting, kinda
> blasphemy, a configuration knob which you could set in BGP channel (if
> implemented), e.g. like this
>
>     import invalid;
>
> and then you would get all routes including the bad ones, just marked with
> another attribute like "invalidity reason" which could be probably even
> displayable in the table. These routes would stay rejected even if you call
> "accept" on them by mistake.
>
> Or, if you wanna go really messy, you could
>
>     import invalid allow accept;
>
> and you already probably know what happens. That's very cursed though and
> there will be certain people yelling at me for even thinking about this.
>
> Obviously you need import keep filtered for all this to work well.
>
> I'm absolutely unknown whether this sacrilegious abomination ever gets
> even slightly more thoughts on our side… but simply by looking at your
> email, this may be something you may probably theoretically like to go for.
>
> Happy routing!
> Maria
>
>
> On June 12, 2025 3:33:37 PM GMT+02:00, "André Grüneberg" <
> andre.grueneberg at bcix.de> wrote:
>
>> Hi Bird team,
>>
>> We are currently evaluating the implementation of RFC9234 for our IXP
>> route servers. Looking at it naively, one just needs to set local role
>> rs_server in the protocol. And indeed, routes from peers will be
>> rejected and this is logged.
>>
>> Instead of just logging, we would really like to apply our "blame and
>> shame" policy, i.e. make the invalid routes (in our case, anything with an
>> OTC set) visible in our looking glass (similar to RPKI invalids). To do so,
>> we'd need the "ineligible" routes to be imported into the main table,
>> tagged in a sensible way.
>>
>> I understand that RFC9234 section 5 mandates that the behaviour wrt OTC
>> attribute handling shall not be configurable by the operator. But
>> ineligible does not require the route to be invisible (see section 3).
>>
>> Would it be possible to implement a more relaxed behaviour by allowing
>> the import of ineligible routes (but never export)?
>>
>> Our current alternative is to avoid using BGP roles capability, but only
>> implement OTC handling in filters.
>>
>> Thanks and best wishes,
>> André
>>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>


-- 
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/02eba179/attachment.htm>