best practice for advertising peering fabric routes
adam.vitkovsky at swan.sk
Tue Feb 4 13:10:05 UTC 2014
> But hey, I get why ISP's don't want to offer 9K MTU clean paths end to
> 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
No it's exactly why some carriers do their best to provide 9K+ MTU to most
of their POPs so that they can provide L2 services to ISPs and other
carriers that require 9K MTU for their BB links to capitalize on these new
Customers locked in to a single provider (MPLS VPN) can rely on certain
class of service (predictable delay, jitter and packet loss) properties you
can't get out of a pure internet connection from NY to Tokyo.
From: Leo Bicknell [mailto:bicknell at ufp.org]
Sent: Wednesday, January 15, 2014 4:31 PM
To: Dobbins, Roland
Cc: NANOG list
Subject: Re: best practice for advertising peering fabric routes
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/
More information about the NANOG