Agree 100%. And if such systems already exist, and just a new encapsulation is added to support NVO3, what makes you think the below bullet will be added to the implementation?
A question for the working group and not Anoop. Dino On Jun 3, 2014, at 9:19 AM, Anoop Ghanwani <[email protected]> wrote: > >>> > 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]> 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] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
