On 06/02/2012 02:42 AM, Richard A Steenbergen wrote:
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?
It depends, not everything looking as proper from single network operator in the middle can be proper in end-to-end user experience, where multiple networks are traversed.
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.
If someone comes with some implementation overwriting ASPATH (even it may not) and excuses this by RFC incorrectness from his perspective, you'll understand it? Probably not. It's relative.
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).
Well, this matches situatios, where two networks have more than single interconnection and still for prefixes originated from that particular network. But when there's only one interconnection, there's no such reason. Intermediate networks, even having multiple peers will probably see similar origin on all their peers.
Please see the previous commentary from Joe Provo, Saku Ytti, etc, they are quite correct.
I don't think they admits all consequences. When some knob (origin) is not disabled by policy for single prefix visible at multiple points, some "creative" operators should come with other methods to achieve what they wants. Prefix deagregation is first thing, that comes to mind. Even they'll also slightly violate RFC (having not single policy - well, they assume RFC is not correct), they simply start to announce deagregated prefixes next to aggregate one. But deaggregated prefixes are announced only to specific peers - and yes, this works. Then, you can have any policy, have everything normalized at all peers - but most specific prefix in your table visible over particular path simply wins over everything. And this is not a imaginary case - this is clearly visible in real routing table - 41% of address space (in IPv4) is deaggreated, in my experience mainly due to "traffic engineering" purposes - smaller end networks are simply enforced to do this, and some people here confirmed this in this discussion... - Daniel