Re: [nvo3] Dataplane requirements draft - section 3.5 - path MTU text

["LASSERRE, MARC (MARC)" <[e-mail]>]

Hi Joe,

See my comments below.

Thanks,
Marc 

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Thursday, May 22, 2014 6:46 PM
> To: LASSERRE, MARC (MARC); Black, David; [e-mail]
> Subject: Re: [nvo3] Dataplane requirements draft - section 
> 3.5 - path MTU text
> 
> Hi, all,
> 
> Why not just have the Tenant Systems that act as end hosts 
> just follow RFCs 1122 and 1123?

This is the expectation for IP tenant systems.

L2/non-IP tenant systems are also supported.

> 
> I.e,:
> 
> ----
> Tenant Systems that source or sink IP traffic are Internet 
> hosts, and thus are (already) required to be compliant with 
> RFC 1122 and 1123.
> 
> Tenant Systems that forward IP traffic are Internet routers, 
> and thus are (already) required to be compliant with RFC 1812 (etc.).
> ---
> 
> (that goes for a lot of other stuff in this doc - if properly 
> mapped to existing Internet components, there is no need for 
> either new mechanism or even new requirements).

True. A lot of existing mechanisms can and should be re-used. 
The intent of this draft is to describe a list of (not necessarily new) requirements for nvo3 solutions to address.

> 
> Joe
> 
> On 5/22/2014 1:11 AM, LASSERRE, MARC (MARC) wrote:
> > 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:[e-mail]] On Behalf Of Black, David
> >> Sent: Wednesday, May 21, 2014 6:14 PM
> >> To: [e-mail]
> >> 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
> >> [phone]             FAX: [phone]
> >> [e-mail]        Mobile: [phone]
> >> ----------------------------------------------------
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >>
> > _______________________________________________
> > nvo3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nvo3
> >
>