Jeffrey Haas

Working on Internet routing since 2000.

Last Notes

2026-08-02 13:26:03 UTC

- reply

@nprofile…tpfq You've effectively resummarized my points: You can't get rid of it. You can't extend it. You can't stop anyone from setting it to what they like. You can't stop anyone from *re-*setting it to what *they* like.
What we *can* do is document reality. The RFC 4271-bis work is good for such a thing and *now* is the time to contribute to the Issues and eventually a pull-request.

2026-08-01 16:39:10 UTC

There's been some recent discussion covering #bgp routing about the ORIGIN attribute. Pointers to a few items for that discussion follow in the replies, but let's lead with the nice Cloudflare post.[1]
One track follows the fact that RFC 4271 says you SHOULD NOT be changed after it's been originated.[2] But, clearly, that's happening.
Another track has been "we should deprecate this!"[3][4] Good luck with that. Much of the headache for BGP is dealing with incremental deployment. This is baked deep enough into the core protocol that any effort to remove it either at the PDU level or the route selection level sufficient to make a difference isn't something I find likely to happen before I retire.
The missing bit of the conversation is why we're seeing this manipulation at all. The simple answer is that when all you have are hammers, every problem resembles a nail.
Service providers have a very small number of tools in their toolbox to light-handedly shape in-AS traffic. The toolbox to change how traffic is attracted to their AS is just as clumsy.
The subset of BGP's route selection tools available is shown in my very Crayola palette.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/117/021/232/848/161/928/original/36cce8d4e0dbab05.png