And now to respond to my own email 🙂 The problem with not explicitly deprecating the attribute is that we may end up with even more inconsitencies in routing decisions in the DFZ.
A BCP that recommends rewritng all prefixes to IGP will result in the following world: * Some networks have implement this BCP, and some have not. * It's already tricky to predict if another network will prefer a certain path (due to BGP implemenation variances), this BCP would exacerbate that problem. * I'm a downstream of two networks, one rewrites all origins to IGP (as per the BCP), the other doesn't. I actually want the 2nd one to be my primary, but the 1st network becomes primary because they implemented a BCP designed to stop exactly this scenario. If we had a BCP which introduces some sort of "ignore origin type" knob, I think we'd end up in the same world? So, is the only way forward, in fact, to fully/explicitly deprecate the attribute from BGP? * We'll still end up in a world where some people haven't got these lastest code changes deployed. * We'll still introduce more uncertanty in knowing how my peers will route stuff, until the changes are deployed widely enough. * But! Maybe this method is more likely to get us to the point where most networks do have the code changes deployed, because at some point, either people do firmware upgrades, or they get new hardware (with newer firmware), with the code changes. Whereas optional BCPs, people are free to ignore forever. Thoughts? With kind regards, James Bensley (he/him) ________________________________ From: James Bensley <[email protected]> Sent: 31 October 2025 15:21 To: [email protected] <[email protected]> Subject: [routing-wg] Re: bgp origin attribute ⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. I have had some people tell me that they do or have used the origin type, as a gentler way to prioritise/deprioritise stuff than MED or AS prepending. If that is a good idea or not is a different questing, everyone has different contexts. Also, we have to consider they we are all probably approaching this with our hats on, as operators in the DFZ. They may be some use case(s) for origin types inside other networking environments, away from the DFZ, we're note thinking off. This is why I think it could be a good idea to not try and explicitly remove the attribute, but rather produce a BCP that recommends to either implicitly deprecate the attribute *specifically in the DFZ* (by manually setting all learned prefixes via a routing policy, or an implementation knob to ignore origin type, or a knob which overwrites all learned origin types to a specified value, or whatever). We could write a draft BCP and throw that into an IETF WG to see what happens (to see what feedback / backlash / praise comes out of it). Who'd be interested in collaborating on such a draft? With kind regards, James Bensley (he/him) [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: [email protected]<mailto:[email protected]> | Web: inter.link<https://inter.link>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
