I'd be concerned that this could lead to a *long* discussion of alternative implementation approaches in this requirements draft.
Thanks, --David From: [email protected] [mailto:[email protected]] On Behalf Of Anoop Ghanwani Sent: Tuesday, June 03, 2014 12:20 PM To: Black, David Cc: [email protected] Subject: Re: [nvo3] Dataplane requirements draft - section 3.5 - *revised* path MTU text >>> o Providing NVE segmentation and reassembly support in overlay operations that avoids IP fragmentation caused by additional headers. >>> It may be worth pointing out that this option significantly complicates the design of hardware NVEs because they need to buffer packets and have reassembly logic (timeouts, etc.) to in order to perform the reassembly. Anoop On Fri, May 23, 2014 at 2:06 PM, Black, David <[email protected]<mailto:[email protected]>> wrote: 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 protected]<mailto:[email protected]> Mobile: +1 (978) 394-7754<tel:%2B1%20%28978%29%20394-7754> ---------------------------------------------------- _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
