Re: best practice for advertising peering fabric routes

[Leo Bicknell <bicknell () ufp org>]

On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" <rdobbins () 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 () ufp org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail