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