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