Hi Joe, See my comments below.
Thanks, Marc > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, May 22, 2014 6:46 PM > To: LASSERRE, MARC (MARC); Black, David; [email protected] > 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:[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 > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
