Re: [nvo3] Dataplane requirements draft - section 3.5 - path MTU text
"LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com> Fri, 23 May 2014 07:49 UTC
Return-Path: <marc.lasserre@alcatel-lucent.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434101A02C2 for <nvo3@ietfa.amsl.com>; Fri, 23 May 2014 00:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHqG-wrwYsRS for <nvo3@ietfa.amsl.com>; Fri, 23 May 2014 00:49:11 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728E71A00F2 for <nvo3@ietf.org>; Fri, 23 May 2014 00:49:11 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4N7n55M006262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 May 2014 02:49:07 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4N7n4x6008847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 May 2014 09:49:05 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 23 May 2014 09:49:05 +0200
From: "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>
To: "Black, David" <david.black@emc.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: Dataplane requirements draft - section 3.5 - path MTU text
Thread-Index: AQHPdep40SlY4ylvA0udRNwPmSbgLZtNxh/w
Date: Fri, 23 May 2014 07:49:04 +0000
Message-ID: <B30152B129674240ADF67727A9673014082997@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <8D3D17ACE214DC429325B2B98F3AE712076C662AEB@MX15A.corp.emc.com> <B30152B129674240ADF67727A967301408173E@FR711WXCHMBA03.zeu.alcatel-lucent.com> <8D3D17ACE214DC429325B2B98F3AE712076C662D71@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C662D71@MX15A.corp.emc.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/t_ql72945kjoQwB3ls4MguCJAdo
Subject: Re: [nvo3] Dataplane requirements draft - section 3.5 - path MTU text
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 07:49:13 -0000
Dave, See my comments below. Thanks, Marc > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, May 22, 2014 8:20 PM > To: LASSERRE, MARC (MARC); nvo3@ietf.org > Subject: RE: Dataplane requirements draft - section 3.5 - > path MTU text > > > 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). Interface MTU is used as the link MTU in this sentence. But I do not see why it is not correct if RFC4821 is used. The path MTU discovered via PLPMTUD is dependent upon the link MTU used... What wording would you suggest? > > If RFC 4821 is implemented to deal with this path MTU > discovery requirememnt, where would that implementation be located? It is the TS's responsability. But in the case where RFC4821 is not supported, The NVE may have to fragment/reassemble IP packets as implied in the 2nd option described in this paragraph. > > Thanks, > --David > > > -----Original Message----- > > From: LASSERRE, MARC (MARC) > [mailto:marc.lasserre@alcatel-lucent.com] > > Sent: Thursday, May 22, 2014 4:12 AM > > To: Black, David; nvo3@ietf.org > > 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:nvo3-bounces@ietf.org] On Behalf Of > Black, David > > > Sent: Wednesday, May 21, 2014 6:14 PM > > > To: nvo3@ietf.org > > > 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 > > > david.black@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > >
- [nvo3] Dataplane requirements draft - section 3.5… Black, David
- Re: [nvo3] Dataplane requirements draft - section… LASSERRE, MARC (MARC)
- Re: [nvo3] Dataplane requirements draft - section… Joe Touch
- Re: [nvo3] Dataplane requirements draft - section… Black, David
- Re: [nvo3] Dataplane requirements draft - section… Joe Touch
- Re: [nvo3] Dataplane requirements draft - section… LASSERRE, MARC (MARC)
- Re: [nvo3] Dataplane requirements draft - section… LASSERRE, MARC (MARC)
- Re: [nvo3] Dataplane requirements draft - section… Black, David