HE.net BGP origin attribute rewriting

Sat Jun 2 00:42:57 UTC 2012

On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:
> 
> By overwriting origin field, there's no warranty that someone improves 
> performance at all - it's just imagination. In extreme cases, 
> performance can be degraded when someone in the middle plays with 
> origin field and doesn't know reasons, why originating network uses 
> something else than IGP origin. In RFC 2119 words, full implications 
> were not understanded - when this overwriting is done generally.

Uh, what part of "to prevent remote networks from improperly forcing a 
cold potato routing behavior on you" sounds imaginary?

> Also, there must be some historical reason, why origin should not be 
> rewritten (this changed in January 2006). For internal reasons within 
> the network operator still haves enough knobs to enforce own policy 
> (by setting localpref, med on his network).

Not really, no. Not every RFC is 100% correct, and they're often written 
by people who are not operators (because operators are too busy running 
real networks :P). Besides, "SHOULD NOT" means "you probably don't want 
to do this, unless you have a really good reason", and enforcing such an 
important point in a peering policy is a pretty good reason.

You also clearly don't understand the practical use of localpref. When 
you're trying to implement a simple and relatively common policy like 
"closest exit routing to a peer with multiple exits", you set the 
localprefs the same (localpref is usually used to determine WHICH peer 
you'll be sending to), you set the MEDs the same (if you don't want to 
artifically select which EXIT to use), AS-PATH lengths are obviously the 
same if you have multiple exits, and then the next one down is origin 
code. If you can't reset origin code, you run the risk of a remote 
network being able to force your network to do something you probably 
don't want to do (or at least probably wouldn't want to do, if you had 
any idea what you were doing :P).

Please see the previous commentary from Joe Provo, Saku Ytti, etc, they 
are quite correct.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)