Hi Maria, I was considering your "personal speculation" and came to the conclusion that I agree, this should not be implemented.
For a lot of errors in UPDATE messages, it's perfectly fine to treat those as an error and do Treat-as-withdraw (as described in RFC7606). This includes checking the length of the OTC attribute. I am not asking to see routes with protocol errors in the routing table. 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? How do you treat routes that do not pass next-hop lookup? Shouldn't these be ineligible as well? How about doing something similar for "ineligible by OTC"? Best regards, André On Fri, 13 Jun 2025 at 00:50, Maria Matejka <maria.mate...@nic.cz> wrote: > Hello André, > > there is no such feature you are looking for. > > The rest of this message is my personal speculation which I may just later > say strict no-no-no-never to after discussing with the rest of the team. > > I'm thinking about a controversial approach, kinda disgusting, kinda > blasphemy, a configuration knob which you could set in BGP channel (if > implemented), e.g. like this > > import invalid; > > and then you would get all routes including the bad ones, just marked with > another attribute like "invalidity reason" which could be probably even > displayable in the table. These routes would stay rejected even if you call > "accept" on them by mistake. > > Or, if you wanna go really messy, you could > > import invalid allow accept; > > and you already probably know what happens. That's very cursed though and > there will be certain people yelling at me for even thinking about this. > > Obviously you need import keep filtered for all this to work well. > > I'm absolutely unknown whether this sacrilegious abomination ever gets > even slightly more thoughts on our side… but simply by looking at your > email, this may be something you may probably theoretically like to go for. > > Happy routing! > Maria > > > On June 12, 2025 3:33:37 PM GMT+02:00, "André Grüneberg" < > andre.grueneb...@bcix.de> wrote: > >> Hi Bird team, >> >> We are currently evaluating the implementation of RFC9234 for our IXP >> route servers. Looking at it naively, one just needs to set local role >> rs_server in the protocol. And indeed, routes from peers will be >> rejected and this is logged. >> >> 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. >> >> 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). >> >> Would it be possible to implement a more relaxed behaviour by allowing >> the import of ineligible routes (but never export)? >> >> Our current alternative is to avoid using BGP roles capability, but only >> implement OTC handling in filters. >> >> Thanks and best wishes, >> André >> > -- > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. > -- André Grüneberg, Managing Director andre.grueneb...@bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
