HE.net BGP origin attribute rewriting

Fri Jun 1 17:38:42 UTC 2012

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