Communities BCP [was: RE: BGP Path Filtering]
bicknell at ufp.org
Fri May 16 22:50:37 UTC 2003
In a message written on Fri, May 16, 2003 at 05:28:37PM -0500, Guy Tal wrote:
> All a matter of perspective. I would assume most people want to use
> closest exit on their networks. Imagine how nice it would be if you could
> hand off traffic to a peer that is your closest exit, then force them to
> carry the traffic back to you at that same point from across the country
> or across the globe!
Since this started off talking about customers, I must also point
Many customers want MEDs to be honored. They don't want their
transit provider, who they are paying money to carry the bits where
they want them to be, to be closest exiting to them.
I would think the most common configuration in large networks is to
honor meds from customers, not honor them from peers, but send them
to peers. Note I said common, and not majority.
Do MEDs have their problems? Sure. Are they worse than the
alternatives? I don't think so. A lot of people do a lot of
handwaving about how dangerous it is to use meds. I find that
funny, working on a global network that uses them without major
problem. Do you have to avoid some situations, sure...but that's
no different than if you don't use them. I know more than a few
networks that avoid MPLS traffic engineering through clever use of
meds, for instance, a good trade off in my book.
At the end of the day the best advice I have is to be mindful of
what you do with MEDS. Too many people like to ignore them, and
that is a problem. Don't want to send them, fine, but be religous
about getting rid of them everywhere or you'll cause problems.
Want to use them, fine, but make sure they mean something and
aren't garbage. Ignoring the consequences of meds in your config
choices _will_ cause you problems.
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the NANOG