On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: > 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.
Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream AS results in a change to the ORIGIN code for a given path, you've _created INconsistent ORIGIN codes for the prefix in the routing system. I suppose I understand why this might be desirable for a transit network provider, but as an edge AS I'd prefer to not have intermediate networks changing the values I set. > 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. I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in practice than ORIGIN code (e.g., [1]), especially when comparing across paths learned from different adjacent ASes. -danny [1] <http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njk2Jm5hbm9nMjk=&nm=nanog29> _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
