Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

[Linda Dunbar <[e-mail]>]

I think that the "fragmentation and path MTU text" should be seriously discussed in SFC WG that is considering Service Chain Header format. 

I've heard people mentioning encoding the explicit Service Chain path as metadata to the data packet header for some scenarios where head-end SC classifier node determines the chain path dynamically. 

Just imagine having IPv6 addresses encoded in the packet header to show explicit service chain path, which can be very long.  

Cheers,

Linda





-----Original Message-----
From: tsv-area [mailto:[e-mail]] On Behalf Of Black, David
Sent: Wednesday, May 14, 2014 3: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:

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]
----------------------------------------------------