<div dir="ltr">I don't know much...<br>But I imagined a solution along the lines you mentioned, Erin Shepherd.<br><br>What I thought of is actually a step backwards, because from what I know all IXPs have tried to avoid Multi-RIB.<br>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.<br><br>This seems like total overkill to me, but I imagine it could work.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sex., 13 de jun. de 2025 às 07:47, Erin Shepherd <<a href="mailto:bird-users@erinshepherd.net">bird-users@erinshepherd.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div><br></div><div><br></div><div>On Fri, 13 Jun 2025, at 12:31, André Grüneberg wrote:</div><blockquote type="cite" id="m_1651582667701334522qt"><div dir="ltr"><div>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).</div><div><br></div><div>My understanding: a leaked route should be present in Adj-RIB-In, but not into Loc-RIB.</div><div><br></div><div>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.</div><div>So the question is: Could you imagine another way (i.e. different from Treat-as-withdraw) of handling "ineligible" routes?<span style="font-size:10px"><span style="font-family:Calibri,"sans-serif""></span></span><br></div></div></blockquote><div><br></div><div>Bird normally operates without Adj-RIB-In, but can be configured to operate with one:</div><div><br></div><blockquote type="cite"><div><code style="border-width:1px;border-style:solid;border-color:rgb(204,204,204);border-radius:3px;background-color:rgb(246,246,246);background-repeat:repeat;background-image:none;background-size:auto;background-origin:padding-box;background-clip:border-box;font-family:menlo,consolas,monospace;font-size:90%;padding:1px 3px">import table <i>switch</i></code></div><div>A BGP import table contains all received routes from given BGP neighbor,
before application of import filters. It is also called <i>Adj-RIB-In</i> 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 <code style="border-width:1px;border-style:solid;border-color:rgb(204,204,204);border-radius:3px;background-color:rgb(246,246,246);background-repeat:repeat;background-image:none;background-size:auto;background-origin:padding-box;background-clip:border-box;font-family:menlo,consolas,monospace;font-size:90%;padding:1px 3px">import table</code> allows to store unprocessed routes, which can
be examined later by <code style="border-width:1px;border-style:solid;border-color:rgb(204,204,204);border-radius:3px;background-color:rgb(246,246,246);background-repeat:repeat;background-image:none;background-size:auto;background-origin:padding-box;background-clip:border-box;font-family:menlo,consolas,monospace;font-size:90%;padding:1px 3px">show route</code>, and can be used to reconfigure
import filters without full route refresh. Default: off.<br></div></blockquote><div><br></div><div>(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)</div><div><br></div><div>- Erin</div></div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>