Relaxed handling of OTC attribute

André Grüneberg andre.grueneberg at bcix.de
Thu Jun 12 22:17:09 CEST 2025


Hi Erin,

On Thu, 12 Jun 2025 at 16:16, Erin Shepherd <bird-users at erinshepherd.net>
wrote:

> > 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).
> Does "import keep filtered on" preserve these routes (when viewed with
> "show route filtered")? (Now, I think that leaves questions around
> identifying the reason why a route was filtered etc. But that might be [the
> start of] an approach)
>

Looking at the code (calling WITHDRAW()) I couldn't find any interaction
with 'import keep filtered'.


> > Our current alternative is to avoid using BGP roles capability, but only
> implement OTC handling in filters.
> A disadvantage of that, of course, is that you lose peer role checking
> (although peers supporting roles are very rare today - despite having run
> with OTC support enabled ourselves for a couple of years now, we have only
> one bilat on BCIX which advertises role support towards us)


Indeed, I'd miss the role validation in the session. Having thought about
it, I am missing to see the advantage of that.
For proper handling of the OTC I need to know my role -- and I do, I am
rs_server.

Provided the other side implements RFC9234 and has a local role set, we can
look at the consequences of them setting their local role incorrectly:
- rs_client (as should be): they do not set OTC -> we will accept, we set
OTC -> they will accept
- peer: they set OTC -> we will drop, we set OTC -> they will accept
- provider: they set OTC -> we will drop, we set OTC -> they will drop
- customer: they do not set OTC -> we will accept routes as expected, we
set OTC -> they will accept
- rs_server: they set OTC -> we will drop, we set OTC -> they will drop
A misconfiguration of their role may cause routes not to be accepted, but
since we are always flagging with OTC on export, we will not create
additional route leaks. I'd call that fail-safe?!

As a reference: OpenBGPd 7.8+ distinguishes between setting the local role
(and thus implementing OTC handling) and announcing the BGP roles
capability.

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/20250612/df42b40d/attachment.htm>


More information about the Bird-users mailing list