Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

["Templin, Fred L" <[e-mail]>]

Hi,

> -----Original Message-----
> From: tsv-area [mailto:[e-mail]] On Behalf Of Black, David
> Sent: Wednesday, May 14, 2014 1:53 PM
> To: [e-mail]; [e-mail]
> Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> <WG chair hat off>
> 
> Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains
> some text on dealing with the fragmentation and MTU effects of tunnels.
> I thought I'd ask for some early review of this text, given recent IESG
> excitement around fragmentation and Path MTU topics in another draft:

All tunnels have trouble with path MTU, and in some cases have no choice
but to fragment. However, they should strive to tune out fragmentation
and forward whole packets whenever possible.

Over in the intarea, there have been sporadic ongoing discussions about
how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark
Townsley have been working for a long time on a document titled
"Tunnels in the Internet Architecture":

http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt

That document should be the place to put generic recommendations for
tunnel MTU handling that apply to all tunnel types.

Tunnel MTU issues keep popping up in all places, and this is just
another example. Is it time to revive Joe and Mark's document?

Thanks - Fred
fred.l.templin@boeing. 

> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/
> 
> I believe that the nvo3 draft is in better shape in these areas.  Nonetheless,
> I've included its current text on fragmentation and path MTU below, and (on
> behalf of the draft authors and nvo3 WG chairs) I'm looking for input on
> what that text should say and why.
> 
> In nvo3 terminology, an overlay network is an inner network that is tunneled
> over an outer underlay network.  The nvo3 WG also uses "Tenant System" as
> the term for a sender/receiver of network traffic because multi-tenancy is
> an important motivation for the WG's activities in network virtualization.
> 
> --------------------------------------
> 
> 3.5. Path MTU
> 
>        The tunnel overlay header can cause the MTU of the path to the
>        egress tunnel endpoint to be exceeded.
> 
>        IP fragmentation SHOULD be avoided for performance reasons.
> 
>        The interface MTU as seen by a Tenant System SHOULD be adjusted such
>        that no fragmentation is needed. This can be achieved by
>        configuration or be discovered dynamically.
> 
>        Either of the following options MUST be supported:
> 
>           o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
>             Extended MTU Path Discovery techniques such as defined in
>             [RFC4821]
> 
>           o Segmentation and reassembly support from the overlay layer
>             operations without relying on the Tenant Systems to know about
>             the end-to-end MTU
> 
>           o The underlay network MAY be designed in such a way that the MTU
>             can accommodate the extra tunnel overhead.
> 
> --------------------------------------
> 
> </WG chair hat off>
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------