Relaxed handling of OTC attribute

[Alexander Zubkov]

BMP might be the answer? It seems to me one should be able to observe those
routes there.

On Fri, Jun 13, 2025 at 1:41 PM Douglas Fischer <fischerdouglas at gmail.com>
wrote:

> I don't know much...
> But I imagined a solution along the lines you mentioned, Erin Shepherd.
>
> What I thought of is actually a step backwards, because from what I know
> all IXPs have tried to avoid Multi-RIB.
> But I imagined a Multi-RIB where the peer does not impose RFC9234 on the
> participant peers in each respective RIB, and when it comes time to leak
> from the per-participant RIB to the main one, then it does impose OTC and
> similarities.
>
> This seems like total overkill to me, but I imagine it could work.
>
> Em sex., 13 de jun. de 2025 às 07:47, Erin Shepherd <
> bird-users at erinshepherd.net> escreveu:
>
>>
>>
>> On Fri, 13 Jun 2025, at 12:31, 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.
>>
>> 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?
>>
>>
>> Bird normally operates without Adj-RIB-In, but can be configured to
>> operate with one:
>>
>> import table *switch*
>> A BGP import table contains all received routes from given BGP neighbor,
>> before application of import filters. It is also called *Adj-RIB-In* in
>> BGP terminology. BIRD BGP by default operates without import tables, in
>> which case received routes are just processed by import filters, accepted
>> ones are stored in the master table, and the rest is forgotten. Enabling import
>> table allows to store unprocessed routes, which can be examined later by show
>> route, and can be used to reconfigure import filters without full route
>> refresh. Default: off.
>>
>>
>> (I assume this contains routes discarded because of an incorrect OTC
>> attribute but I have not verified this. Even then I'm not sure Bird can
>> (currently) use it to give you information on why routes were filtered)
>>
>> - Erin
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250613/c425a521/attachment.htm>