On Fri, Jun 01, 2012 at 10:19:16AM +0200, Daniel Suchy wrote:
On 05/31/2012 07:06 PM, Saku Ytti wrote:
On (2012-05-31 08:46 -0700), David Barak wrote:
On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules.
When provider rewrites MED, they do it, because they don't want peer to cause them to cold-potato, to which they may have compelling reason. Then some clever people realize they forgot to rewrite origin, working around the implicit agreement you had with them.
You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin.
I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly.
Please remind yourself the standard language from rfc 2119. SHOULD NOT is not in the same ball park as MUST NOT: "4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label."
I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a "cool" idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin.
You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is "cool" but also just good business and proper network hygiene. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG