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 < [email protected]> 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
