Martin Pels wrote on 10/3/2016 4:15 μμ: > On Thu, 10 Mar 2016 08:23:30 +0200 > Tassos Chatzithomaoglou <ach...@forthnet.gr> 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. >>> You're wrong here. The IXP switch platform cannot send ICMP Packet >>> Too Big messages. That's why everybody must agree on one MTU. >>> >>> >> 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? > None. Until someone actually tries to make use of the higher MTU. Then > things start breaking. >
I can understand the above issue. But as i said that's customer's decision. Exactly the same will happen if the customer increases its mtu now. > In order for Jumboframes to be successful on IXPs _on a large scale_ > the technology has to change. There needs to be a mechanism to negotiate > MTU for each L2 neighbor individually. Something like > draft-van-beijnum-multi-mtu-03, which was mentioned before in this > thread. With this in place individual sets of peers could safely use > different MTUs on the same VLAN, and IXPs would have a migration path > towards supporting larger framesizes. Agreed. But that doesn't forbid the IXPs to use the max MTU now. -- Tassos