HE.net BGP origin attribute rewriting

Thu May 31 17:34:39 UTC 2012

In a message written on Thu, May 31, 2012 at 12:22:16PM -0500, Richard A Steenbergen wrote:
> out of the protocol. I don't see anyone complaining when we rewrite 
> someone else's MEDs, sometimes as a trick to move traffic onto your 
> network (*), or even that big of a complaint when we remove another 
> networks' communities, so I don't see why anyone cares about this one.

Take all the politics and contracts out of it, and look at MED from
a 100% pure engineering perspective, with the traditional view that
MED reflects IGP cost, and origin reflects where the route came
from in the first place.

I would argue the right engineering answer is that each network,
on outbound, should set the MED equal to the IGP cost.  Basically
if an ASN gets 4 routes with 4 different MEDS on 4 peering points
and picks the "best", when it passes it on to the next metric the
IGP cost an AS away no longer makes any sense.

If the behavior is for each ASN to inject their own MED on outbound,
then rewriting inbound or outbound is just an extension of the
entirely local policy anyway, no different than changing IGP metrics.
Don't want to reflect IGP metrics, rewrite to a fixed value.

The origin is different, at least conceptually.  The origin type
should reflect the state of the route before it went into BGP, a
property which does not change per-AS hop along the way.

That's why with a pure engineer hat on I would be much more
surprised/upset to see someone rewriting origin while I would expect
them to be rewriting MED.

Of course the real world isn't 100% engineering based.  ISP's do
all sorts of weird and fun things, and customers can (usually) vote
with their dollars.  I don't have a problem with an ISP implementing
pretty much any BGP policy they want /provided they disclose it to
their BGP customers/.

Perhaps if a large number of people were a bit more rational with their
peering policies we wouldn't have enginers dedicated to generating
routing funkyness just to meet peering criteria.  It's not helping
anyone get reliable, high performing network access.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120531/83395cc7/attachment.sig>