> 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.
How about a three-step approach: BCP documenting you should (A) set origin to IGP when originating and (B) scrub origin on incoming updates Turning BCP into SHOULD behavior Deprecate ORIGIN attribute and its role in route selection If everything else fails because of bikeshedding, we could still have a RIPE document describing #1 like we had the “IPv6 requirements” RIPE document a long while ago. Ivan > 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 > <[email protected] <mailto:[email protected]>> 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/ > ----- > 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/
----- 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/
