Open Stack

Hello,

There was alot of work to get MTU advertisement working well in Mitaka.
With the work that was done we can finally have 1500 mtu networks for
tunneled networks if the underlying infrastructure supports jumbo frames.

Its fantastic for people who have 1500 mtu networks and want to use vxlan,
no more hacks to get the instance to use 1450 mtu. Its fantastic for people
who want to use 1500+ networks and get the instances setup with 9000 mtu
interfaces. Its is not good for people who want consistent mtu no matter
the network type. But thats fine, since mtu advertisement _could_ be
disabled. Its a fantastic default to have it turned on.

With a recent patchset [1] the ability to turn off MTU advertisements was
deprecated in Newton. In the review it was stated there is no valid use
case for it. I disagree.

The scenario is the infrastructure has jumbo frames enabled, but I do not
want the instances to be using jumbo frames, but I want them to be using
the default 1500 mtu that the rest of the world operates on. This would
still setup all of the virtual switching infrastructure to the correct
MTUs, but not try to adjust the instances MTUs. In this way the instances
are only communicating at 1500 mtu, but never having to fragment/drop
inside of the SDN when communicating with other networks even if it is a
VXLAN or other tunneled network.

Without the option to disable mtu advertisement, inside the same
environment flat/vlan and gre/vxlan network will always have different mtu,
even if the backend supports jumbo frames.

My ask is we keep the advertise_mtu option, and keep it enabled by default.
This would allow for the default, common 1500 mtu across networks of
different types.

This scenario would be very similiar to having a computer with 1500 mtu
attached to a switch which supports jumbo frames. Just because the switch
will accept and process a 9000 mtu frame, doesnt mean the computer has to
send a 9000 mtu frame. A very common scenario in the real world.

[1] https://review.openstack.org/#/c/310448/

Sam Yaple
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160711/443a77b1/attachment.html>