Relaxed handling of OTC attribute

[Maria Matejka]

Hi André,

> 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.

Oh there could be many different options … maybe this way?
(Still speculating in my personal capacity, it's weekend and the next
team meeting is on tuesday.)

    allow leaks [off/filtered/on]
    allow invalid next hop [off/filtered/on]
    allow as sets [off/filtered/on]
    allow malformed [off/filtered/on]
    ...

Here `off` would reject these altogether (default option), `filtered`
would pass them to filters but always reject, and `on` would allow
accepting them to the 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).

Oh yes, but it's kinda similar to rejecting AS sets ... :wink:

> My understanding: a leaked route should be present in Adj-RIB-In, but not
> into Loc-RIB.

That's what would actually be possible with that `allow leaks filtered`.

> 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?

Not with the current implementation, but it's doable e.g. in the way
shown above.

> 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"?

Well, errmhm … these with unreachable nexthops are usually ineligible
but kept in the table (just not selected). Usually. Some nexthops are
also considered malformed (e.g. a zero nexthop) and rejected without
reaching filters.

Occassionally we open this can of worms in our office, find out that
there are much more worms than we expected, see that some of them are
holding holy hand grenades, and we wisely decide to let the whole thing
sleep for several more years.

Have a nice day!  
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250613/cf575fb2/attachment.htm>