> Concerning your last question, the following sentence in 3.5 indicates that > MTU discovery is the TS's responsibility: > > "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."
In that case, the use of "interface MTU" seems off, as I interpret that term as the link MTU presented by the network interface to the TS (that interface may be virtual or physical. That interpretation would not be correct for a Tenant System implementation of RFC 4821 (PL PMTUD) that's integrated with a transport protocol such as TCP because the result has no effect on interface MTU (if the path MTU is smaller than the interface MTU, TCP sends smaller packets). If RFC 4821 is implemented to deal with this path MTU discovery requirememnt, where would that implementation be located? Thanks, --David > -----Original Message----- > From: LASSERRE, MARC (MARC) [mailto:[email protected]] > Sent: Thursday, May 22, 2014 4:12 AM > To: Black, David; [email protected] > Subject: RE: Dataplane requirements draft - section 3.5 - path MTU text > > 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
