Hi Shane, I always found this presentation very instructive to educate on the practice you are describing: http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTIwMCZuYW5vZzQ1&nm=nanog45
I agree that this is common practice, particularly between content operators. Roque On Oct 24, 2012, at 12:03 AM, Shane Amante wrote: > Danny, > > On Oct 23, 2012, at 3:25 PM, Danny McPherson <[email protected]> wrote: >> On Oct 23, 2012, at 5:05 PM, John G. Scudder wrote: >>> BGPSec protecting Origin would stomp on current operational practice, so it >>> would need to be justified more strongly than "seemed like a good idea at >>> the time". >> >> What does this mean? What operational practice? > > I suspect John is referring to the operational practice employed by some > networks, right now, whereby they overwrite ORIGIN during receipt of an > UPDATE into their network to 'normalize' ORIGIN to a consistent value. This > is especially valuable in cases where one network, A, is multi-homed to an > adjacent network, B, and network A may not be announcing a consistent set of > BGP path attributes associated with a set of IP prefixes at all locations. > Ultimately, this practice allows network B to consistently skip over ORIGIN > and, instead, evaluate more well-understood BGP Path Selection criteria like > MED's, IGP metric, etc. across the full set of "common" BGP routes, (i.e.: > those with the same AS_PATH, LOCAL_PREF, etc.), learned across all exit > points to network B. > > Oh, and FWIW, I agree with the sentiment that "securing" BGP ORIGIN in BGPSEC > is a bad idea, for the very reason that I've stated above and others have > provided on the list. > > -shane > > P.S. -- I would like to coin the saying: "The difference between theory and > practice in BGP is, in practice, BGP works in today's Internet, because it's > not confined by any theory." :-) > > > >> -danny >> >> >> >> >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >> >> >> >> > > > !DSPAM:50871436120611221711528! > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
