best practice for advertising peering fabric routes

Wed Jan 15 15:31:07 UTC 2014

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

> Not really.  What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison.

I think we're looking at two different aspects of the same issue.

I believe you're coming at it from a 'for all users of the Internet, what's the chance they have connectivity that does not break PMTU-D.'  That's an important group to study, particularly for those DSL users still left with < 1500 byte MTU's.  And you're right, for those users IXP's are the least of their worries, mostly it's content-side poor networking, like load balancers and firewalls that don't work correctly.

I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?'  I'm the network guy who wants to buy transit in the US, and transit in Germany and run a tunnel of 1500 byte packets end to end, necessitating a ~1540 byte packet.  Finding transit providers who will configure jumbo frames is trivial these days, and most backbones are jumbo frame clean (at least to 4470, but many to 9K).  There's probably about a 25% chance private peelings are also jumbo clean.  Pretty much the only thing broken for this use case is IXP's.  Only a few have a second VLAN for 9K peerings, and most participants don't use it for a host of reasons, including PMTU-D problems.

I'm an oddball.  I think MPLS VPN's are a terrible idea for the consumer, locking them into a single provider in the vast majority of cases.  Consumers would be better served by having a tunnel box (IPSec maybe?) at their edge and running there own tunnel over IP provider-independently, if they could get > 1500B MTU at the edge, and move those packets end to end.  While I've always thought that, in the post-Snowden world I think I seem a little less crazy, rather than relying on your provider to keep your "VPN" traffic secret, customers should be encrypting it in a device they own.

But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end.  Customers could then buy a VPN appliance and manage their own VPN's with no vendor lock-in.  MPLS VPN revenues would tumble, and customers would move more fluidly between providers.  That's terrible if you're an ISP.

-- 
       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/6ff1c087/attachment.sig>