Relaxed handling of OTC attribute

[Douglas Fischer]

BMP is only for those that receive the BMP Stream.
And BMP stream is not to be sent publicly.

I guess the bigger pain here is to make those routes appear on Alice-LG.
And it will only appear on Alice if the routes are on RIB.
Remembering that Alice's connector can be deployed:
- Directly on RS, as in DE-CIX.
  This brings much more useful info, but can cause some extra effort on RSs.
- In a reflected RS, as in AMS-IX.
  This protects production RSs from query-floods, but lose several infos.
  P.S.: As a network operator, I don't like this method.

Other points are the route collectors that need to get those routes also
via BGP.
For example(if I'm not mistaken)  it is through this way that MANRS get
their infos to do some reporting of routing security.

Em sex., 13 de jun. de 2025 às 08:52, Alexander Zubkov <green at qrator.net>
escreveu:

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

-- 
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/908b5f27/attachment.htm>