Hello! On Mon, Oct 27, 2025 at 01:15:48PM +0000, James Bensley wrote:

If someone really wants to take this to the IETF, probably the path of lesser resistance would be to get a new BCOP published which recommends everyone bleach the origin type to IGP to implicitly deprecate the attribute, and advise networks do things that avoid the FSM getting as far down the process as router ID.

I think this kind of attribute bleaching and implicit deprecation needs a standards track draft anyway, possibly in a similar way as the AS Sets went into deprecation. It's gonna be indeed years before adoption anyway, yet we should at least "officially" do a statement that this is indeed that direction. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

An option in BGP implementations might help, like "bgp bestpath ignore-origin-type"

On 31. Oct 2025, at 14:08, Maria Matejka via routing-wg <routing-wg@ripe.net> wrote:

think this kind of attribute bleaching and implicit deprecation needs a standards track draft anyway, possibly in a similar way as the AS Sets went into deprecation. It’s gonna be indeed years before adoption anyway, yet we should at least “officially” do a statement that this is indeed that direction.

-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne

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 <james@inter.link> Sent: 31 October 2025 15:21 To: routing-wg@ripe.net <routing-wg@ripe.net> 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: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link>

Hi all, I agree with all the concerns and questions. But all that is exactly the reason to raise the problem at IETF and make some consensus on where the community want to move with it - what should we do long term with the attribute, transition recommendations, etc. If something is going to happen, I would be glad to collaborate / participate in the discussion also. I don't think that much entropy would be added in the BGP decision process, becuase as it is correctly noted, it is already hard to guess what routes would be prefered, because of different implementation, policy configurations. So the aim is to call one of the behaviours a BCP at least, or (if we are lucky) to get rid of unnecessary entropy here. Regards, Alexander Zubkov On Fri, Oct 31, 2025 at 5:33 PM Maria Matejka via routing-wg < routing-wg@ripe.net> wrote:

A BCP that recommends rewritng all prefixes to IGP will result in the following world:

[…]

We should *not* recommend *rewriting* prefixes to IGP, but update the section of 4271 where *originating* the prefix makes it incomplete.

Thus all networks which would implement this BCP, would simply always originate their prefixes as IGP, and these who don’t, would keep suffering of crazy misrouting. Later, like 5+ years in future, we may push a draft advocating for treat-nonIGP-origin-as-withdraw. Basically the same way as with AS Sets.

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.

Considering that the transits are *motivated* to rewrite every origin to IGP anyway, I think that anything else would disappear from the world sooner than later.

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?

*raises hand*

Maria

– Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. ----- 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/