<div dir="ltr"><div dir="ltr">Hi Erin,</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 12 Jun 2025 at 16:16, Erin Shepherd <<a href="mailto:bird-users@erinshepherd.net">bird-users@erinshepherd.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Instead of just logging, we would really like to apply our "blame and shame" policy, i.e. make the invalid routes (in our case, anything with an OTC set) visible in our looking glass (similar to RPKI invalids). To do so, we'd need the "ineligible" routes to be imported into the main table, tagged in a sensible way.<br>> I understand that RFC9234 section 5 mandates that the behaviour wrt OTC attribute handling shall not be configurable by the operator. But ineligible does not require the route to be invisible (see section 3).<br>

Does "import keep filtered on" preserve these routes (when viewed with "show route filtered")? (Now, I think that leaves questions around identifying the reason why a route was filtered etc. But that might be [the start of] an approach)<br></blockquote><div><br></div><div>Looking at the code (calling WITHDRAW()) I couldn't find any interaction with 'import keep filtered'.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Our current alternative is to avoid using BGP roles capability, but only implement OTC handling in filters.<br>A disadvantage of that, of course, is that you lose peer role checking (although peers supporting roles are very rare today - despite having run with OTC support enabled ourselves for a couple of years now, we have only one bilat on BCIX which advertises role support towards us)</blockquote><div><br></div><div>Indeed, I'd miss the role validation in the session. Having thought about it, I am missing to see the advantage of that.</div><div>For proper handling of the OTC I need to know my role -- and I do, I am rs_server.</div><div><br></div><div>Provided the other side implements RFC9234 and has a local role set, we can look at the consequences of them setting their local role incorrectly:</div><div>- rs_client (as should be): they do not set OTC -> we will accept, we set OTC -> they will accept</div><div>- peer: they set OTC -> we will drop, we set OTC -> they will accept</div><div>- provider: they set OTC -> we will drop, we set OTC -> they will drop</div><div>- customer: they do not set OTC -> we will accept routes as expected, we set OTC -> they will accept</div><div>- rs_server: they set OTC -> we will drop, we set OTC -> they will drop</div><div>A misconfiguration of their role may cause routes not to be accepted, but since we are always flagging with OTC on export, we will not create additional route leaks. I'd call that fail-safe?!</div><div><br></div><div>As a reference: OpenBGPd 7.8+ distinguishes between setting the local role 
(and thus implementing OTC handling) and announcing the BGP roles capability.</div><div><br></div><div>André</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>