Hi David,

Thanks for the suggested text. It will be incorporated in the next revision.

Concerning your last question, the following sentence in 3.5 indicates that MTU 
discovery is the TS's responsability:

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

Marc

> -----Original Message-----
> From: nvo3 [mailto:[email protected]] On Behalf Of Black, David
> Sent: Wednesday, May 21, 2014 6:14 PM
> To: [email protected]
> Subject: [nvo3] Dataplane requirements draft - section 3.5 - 
> path MTU text
> 
> Turning to the dataplane requirements draft, here's proposed 
> elaboration text for the path MTU material in section 3.5 (no 
> change to the second and third bullet items - they're 
> included for completeness):
> 
> OLD
>        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
>        At least one 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].  Both techniques are based on use of 
> probe packets.
>               Classical MTU Path Discovery requires 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.
>     
>           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.
> 
> ------------------------------
> 
> There's an additional question - what does that initial 
> "MUST" ("At least one of the following options MUST be 
> supported:") apply to??
> 
> The framework draft text on this topic describes Tenant 
> Systems using MTU discovery techniques, whereas some of the 
> options above apply to the nvo3 dataplane (e.g., overlay 
> segmentation and reassembly could reside in NVEs).
> 
> 
> 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

Reply via email to