Subject: [nvo3] Dataplane requirements draft - section 3.5 - *revised* path MTU text

From: "Black, David" <[email-masked]>
Date: Fri, 23 May 2014 17:06:57 -0400

Trying again, here's a second attempt at proposing elaboration text
for the path MTU material in section 3.5 of the dataplane requirements
draft.

This is getting longer because the original text mixed dataplane
techniques with Tenant System techniques.  See below the text for a
list of requirements changes that have resulted.

There is enough change in this new text that I'd suggest allowing
time for list discussion before adding the text to the draft - there
are inevitably things that are unclear (or even wrong) in the new text.

OLD
       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.
NEW
       In an nvo3 environment, adding overlay and tunnel headers to a packet
       may cause underlay network IP fragmentation when the resulting
       packet size exceeds a link MTU size.  The value of the interface MTU
       exposed to Tenant Systems SHOULD be small enough to avoid this effect.
       This may be accomplished by a number of means, including:

          o Setting the exposed interface MTU (e.g., to be less than
            the actual link MTU).  The value to use may be statically
            configured or discovered dynamically.  
         
          o Providing NVE segmentation and reassembly support in overlay
            operations that avoids IP fragmentation caused by additional headers.

          o Designing the underlay network to have an MTU that accommodates
            the additional header overhead caused by encapsulation.

       Independent of whether the interface MTU value is small enough to avoid
       IP fragmentation caused by encapsulation, Tenant Systems SHOULD use
       path MTU discovery to determine a transmission MTU size that avoids
       IP fragmentation end-to-end.  Two techniques for this are Classical
       ICMP-based MTU Path Discovery [RFC1191] [RFC1981], and Extended MTU Path
       Discovery as defined in [RFC4821].  Both techniques are based on the
       use of probe packets.

       Classical MTU Path Discovery requires ICMP responses to indicate
       that fragmentation is required; ingress NVEs SHOULD generate these
       responses to Tenant Systems when the DF bit is set in the IP header
       of the packet received at NVE ingress and the encapsulated packet
       size would exceed the MTU of the underlay network.  NVE generation of
       such responses avoids complications in dealing with the corresponding
       ICMP responses from the underlay network.

       Extended MTU Path Discovery requires detection of probe packet loss
       at the receiver and means to communicate that loss to the sender;
       e.g., the loss detection and retransmission request functionality
       in transport protocols such as TCP and SCTP.

---------------------------------

There are several requirements changes in the above text:

a) The "MUST" for IP fragmentation avoidance is gone, as I don't think this
   can reasonably be imposed on all Tenant Systems that may use nvo3, and
   I would expect strong objections to a "MUST" on all dataplanes to avoid
   IP fragmentation ... but please, do surprise me about the latter ;-).

b) In order to avoid a dataplane "MUST", the list of ways in which the
   dataplane can avoid IP fragmentation is now a list of examples.

c) Tenant System usage of path MTU discovery is a "SHOULD".  A "MUST" will
   not work here, IMHO, because we do not have complete control over
   Tenant System networking stacks.

d) I added a "SHOULD" requirement that ingress NVEs generate ICMP "too big"
   responses when the DF bit is set in the inbound packet and the underlay
   network would try to fragment the encapsulated packet.  Figuring out
   how an NVE would convert an underlay ICMP response to an overlay
   response for a Tenant System makes my head hurt.
   
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------