[168196] in North American Network Operators' Group
Re: best practice for advertising peering fabric routes
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Jan 15 10:31:32 2014
From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net>
Date: Wed, 15 Jan 2014 09:31:07 -0600
To: "Dobbins, Roland" <rdobbins@arbor.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_D3356091-F2DB-45FD-BBE6-8A161FA46BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Jan 15, 2014, at 8:49 AM, "Dobbins, Roland" <rdobbins@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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Apple-Mail=_D3356091-F2DB-45FD-BBE6-8A161FA46BF1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIVAwUBUtapu7N3O8aJIdTMAQINgBAAsZpkP8UHF/43VvUhy3l7EYmy0V6X7BI8
0tVBXxatDcxMiw3ToULoLPBSLX9hEsMM29SrPGKiTl8g4C7KN5stIgNwTGvsvUYh
KShQ0cz+Cb7hgllBDDYtqXviSwMOZVkGLfdJoA2Bjr8dTUgWZdp6xJhO2TCL749p
6zu0FpKlU8mV2I+HZEGEz4cb0Du/aMbQ9hR5TkqR1U8xl/1ZNKGXHTzsNU9eO2gb
bU9FULXWIwuTczBMHSr+kYMKriL3WZL/u2Koluwb1FqDeP1jq5NRYoXgpt9hs+sI
cERCakdKx5/iw7a/WJXS/mWZKlQp/sqI+ErrUnkSbJ6fND5o8zYd5ctstkNP+0Pi
oqe3+CLsEL2xR3MV1LFZPz4hfBcPcG+t8bu1Y9KmXKyoHDfkEGELy76BqPAkWhGi
riARTqogwwGHKweiNLrKaWOJHCk8IqNWMniMTWL0iIhSLDhUxNlJuR3ccblmTvK+
yRrXMa/owSqUMdxfnCTlP+Y42dO98UR1oLkVbjGEpIaZqQT7KuJJYSZ1hWeVHh9H
L3pC8LqA+RPTBf+oO9+KeXhd0KC4T1RaoL8lZ1soiquriDo86ilM4MgFRLkVsLO4
uC76n68LzNAxVjImwtvI6lrFKoqUz5hBrUFnvJO4gGQAXGe45h8rNkHH7hotCP7E
NoJTsEfBYsU=
=X3pn
-----END PGP SIGNATURE-----
--Apple-Mail=_D3356091-F2DB-45FD-BBE6-8A161FA46BF1--
