[188351] in North American Network Operators' Group
Re: Internet Exchanges supporting jumbo frames?
daemon@ATHENA.MIT.EDU (Chris Woodfield)
Thu Mar 17 13:49:43 2016
X-Original-To: nanog@nanog.org
From: Chris Woodfield <rekoil@semihuman.com>
In-Reply-To: <56E11663.6090100@geier.ne.tz>
Date: Thu, 17 Mar 2016 10:49:37 -0700
To: Frank Habicht <geier@geier.ne.tz>,
nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
I think that=E2=80=99s the problem in a nutshell=E2=80=A6until every =
vendor agrees on the size of a =E2=80=9Cjumbo=E2=80=9D packet/frame (and =
as such, allows that size to be set with a non-numerical configuration =
flag). As is, every vendor has a default that results in 1500-byte IP =
MTU, but changing that requires entering a value=E2=80=A6which varies =
from vendor to vendor.
The IEEE *really* should be the ones driving this particular =
standardization, but it seems that they=E2=80=99ve explicitly decided =
not to. This is=E2=80=A6annoying to say the least. Have their been any =
efforts on the IETF side of things to standardize this, at least for =
IPv4/v6 packets?
-C
> On Mar 9, 2016, at 10:38 PM, Frank Habicht <geier@geier.ne.tz> wrote:
>=20
> Hi,
>=20
> On 3/10/2016 9:23 AM, Tassos Chatzithomaoglou wrote:
>> Niels Bakker wrote on 10/3/16 02:44:
>>> * nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 =
CET]:
>>>> I'm pretty confident there is no need for a specific MTU consensus =
and not all IXP participants are obligated to raise their interface MTU =
if the IXP starts allowing jumbo frames.
>>>=20
>>> You're wrong here. The IXP switch platform cannot send ICMP Packet =
Too Big messages. That's why everybody must agree on one MTU.
>>>=20
>>>=20
>> Isn't that the case for IXP's current/default MTU?
>> If an IXP currently uses 1500, what effect will it have to its =
customers if it's increased to 9200 but not announced to them?
>=20
> none.
> everyone has agreed on 1500. it is near impossible to get close to
> everyone to agree on 9200 (or similar number) and implement it (at the
> same time or in a separate VLAN) (Nick argues, and i see the problem).
> The agreement and actions of the (various) operators of L3 devices
> connected at the IXP is what matters and seems not trivial.
> They are not under one control.
>=20
> Frank
