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 <fischerdoug...@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-us...@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 >
