best practice for advertising peering fabric routes

Wed Jan 15 14:18:13 UTC 2014

On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" <rdobbins at arbor.net> wrote:

> Again, folks, this isn't theoretical.  When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues.

I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale.

However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations.  There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better.

By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone.  I don't like a world where connecting to an exchange point forces a particular network design on participants.

> IXPs are not the problem when it comes to breaking PMTU-D.  The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'.

That's some circular reasoning.

Networks won't 9K peer at exchange points for a number of reasons, including PMTU-D discovery issues.

Since there are virtual no 9K peering at exchange points, PMTU-D is a non-issue.

Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers, or there might even be a future where 9K peering was required?

This whole problem smacks to me of exchange points that are "too big to fail".  Since some of these exchanges are so big, everyone else must bend to their needs.  I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants.

-- 
       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: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140115/435ece7e/attachment.sig>