Re: [nvo3] Update on encapsulation design team

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 21 October 2016 15:55 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C112940B for <nvo3@ietfa.amsl.com>; Fri, 21 Oct 2016 08:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Yh-bJMuvcx2y for <nvo3@ietfa.amsl.com>; Fri, 21 Oct 2016 08:55:15 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B716512942F for <nvo3@ietf.org>; Fri, 21 Oct 2016 08:55:14 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id x79so157355706lff.0 for <nvo3@ietf.org>; Fri, 21 Oct 2016 08:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=cjwHcPwhbq3wpVCiTdWG1/gOT1mt1hczAxDlgDhyIaM=; b=DxaebAr9WTejd7KUNqdLutBmQ5f5XomAqHQEE6ngmvN7jYdNfZssJqIyXWXwvIU+F2 L29Jt8ysSoEDrqQLBnYPBhdklTn+QiP3OwRYc/7hCLNfcbwUDLMqXSbVukKGGkYgGuxI pKOe6OKTW5D1ICFNTgS276t1TKr9couwZ0urVMnU4jIVuNhChwC+6pGWfImE2WlqKdkT UdoAhuyE9q2gR/4X01cE2clatNMo6szC73y20CgW5iUIuuJoVTFLBjRW5zZyq787B2iB 3JXJry13fwL/86yrgiyvjuiL1Q+v+5MMtAkehVVFJoekl0oP166VXjR7SSUpsOuwiNIy PjNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=cjwHcPwhbq3wpVCiTdWG1/gOT1mt1hczAxDlgDhyIaM=; b=ALeJVHZOjzip2rEfYjv3n0hYX87kW8e/sNAURUdhnvh97E/Im5XyzqKeHNk34QK03v 0oZm9HRJ2y1NlDLuc9+801CSTQygJrMtxS5moNPDGqsTZMsKQ02YNSA6qXFhp4rJp26r yPP15xIq+ARLahT5Sh8OM/KQyrq8Q5R2SeveOWFze5W9onCXkDaKp2CcvRnaf4Tjnxfw 6G1wHpQWoUZeXs3wHzzHw5Zu7sCxCWcT3kJf3SCFkXIvizS0k36fO4J29zbZWV+jeeQr LB8q+cb5TEuTfj+dR24roMYk8inWEvS1FzYXeJnUKWSJtoph8K33XBpdAfllqt8nRYT9 /ivA==
X-Gm-Message-State: ABUngvfhL7us4KYk92ma7NjFpkmoC3mwu8w55giHJ7+drn9i1p845ZhXazLx/5ziuWR0sjXPuSW0wq38L+3q+w==
X-Received: by 10.25.162.202 with SMTP id l193mr978094lfe.173.1477065312635; Fri, 21 Oct 2016 08:55:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.16.195 with HTTP; Fri, 21 Oct 2016 08:55:11 -0700 (PDT)
In-Reply-To: <85F5BCC2-CFFD-41CC-A4E6-EF6AE218FBEC@nokia.com>
References: <CAH==cJzDKyQa+3L-vsw1LeMT3-X7Xfg1A137=o5pQ_X0jFJOcg@mail.gmail.com> <85F5BCC2-CFFD-41CC-A4E6-EF6AE218FBEC@nokia.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 21 Oct 2016 10:55:11 -0500
Message-ID: <CAC8QAcdVwn5+LMa2vcZBnmDn0zaYinjrwvyeZAbC2QcFhAFc4A@mail.gmail.com>
To: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/IKwnDjp2WQxOLfXBhKdLEEuS4u0>
Cc: "fmaino@cisco.com" <fmaino@cisco.com>, Tom Herbert <tom@herbertland.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "farinacci@gmail.com" <farinacci@gmail.com>, Lizhong Jin <lizho.jin@gmail.com>
Subject: Re: [nvo3] Update on encapsulation design team
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: sarikaya@ieee.org
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Oct 2016 15:55:19 -0000

Hi Matthew,

I suggest Joe Touch to be included in the design team.
I believe he can do a good job.


As I had expressed before, I believe there is little need for a next
gen encap while the current ones like VXLAN and ILA are in use and
people seem to be happy with them?


Regards,

Behcet

On Fri, Oct 21, 2016 at 5:04 AM, Bocci, Matthew (Nokia - GB)
<matthew.bocci@nokia.com> wrote:
> Lizhong, Tom
>
>
>
> That is correct. The idea is to pick one of the existing three
> encapsulations and enhance it to address the technical concerns that have
> been expressed on the list.
>
>
>
> Those technical issues have already been documented on the list, but there
> may be more that emerge as work progresses. I am not sure we need to write
> them all up in a separate draft – that was attempted in the past in the form
> of the gap analysis draft that did not progress. I expect the design team to
> take the technical issues into account and it would be useful for their
> draft to explicitly explain them and show how they are addressed.
>
>
>
> Regards
>
>
>
> Matthew
>
>
>
>
>
> From: Dacheng Zhang <nvo3-bounces@ietf.org> on behalf of Lizhong Jin
> <lizho.jin@gmail.com>
> Date: Friday, 21 October 2016 at 07:04
> To: NVO3 <nvo3@ietf.org>
> Cc: "fmaino@cisco.com" <fmaino@cisco.com>, Tom Herbert
> <tom@herbertland.com>, "farinacci@gmail.com" <farinacci@gmail.com>
>
>
> Subject: Re: [nvo3] Update on encapsulation design team
>
>
>
> I get the similar understanding from Tom. But I am not confident with the
> timeline, hope will not be delayed.
>
> Regards
>
> Lizhong
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Tom Herbert <tom@herbertland.com>
> To: Dino Farinacci <farinacci@gmail.com>
> Cc: Fabio Maino <fmaino@cisco.com>, "nvo3@ietf.org" <nvo3@ietf.org>
> Date: Thu, 20 Oct 2016 12:35:40 -0700
> Subject: Re: [nvo3] Update on encapsulation design team
> On Thu, Oct 20, 2016 at 12:10 PM, Dino Farinacci <farinacci@gmail.com>
> wrote:
>> I agree with Fabio.
>>
>> Choosing a single encapsulation that is not 1 of the 3, creates a 4th one
>> that no one wants.
>>
>> And guess what, you make all 3 authors unhappy where none of them will
>> endorse (or implement) the 4th one.
>>
> My $0.02: That's not the way I read Matthew's message. It seems like
> the conclusion to the technical objections query is that objections
> were raised for all three protocols and so none of them were ready for
> standardization. The goal of the design team seems to be to start with
> one, presumably the one with the fewest issues, and enhance it to
> answer all the technical objections with an effort to maintain
> backwards compatibility for that protocol. This might essentially be a
> method of picking one as I believe you proposed earlier.
>
> Tom
>
>> Dino
>>
>>> On Oct 20, 2016, at 12:02 PM, Fabio Maino <fmaino@cisco.com> wrote:
>>>
>>> (for full disclosure I'm one of the authors of VXLAN-GPE)
>>>
>>> Matt, Sam, Alia,
>>> I've expressed multiple times and in multiple venues my adversity (and
>>> the motivations) to set this group to design yet another encapsulation. I
>>> won't repeat it here once again, but I want to re-assert that it's still
>>> were I stand.
>>>
>>> I've seen quite a few people in the mailing list here expressing similar
>>> concerns, but I see that it has not changed the opinion of the chairs and
>>> the AD on what they believe is the best way to move forward.
>>>
>>> That said, here are my comments to the charter.
>>>
>>> I think the design team first goal should be to clearly articulate the
>>> shortcomings of the current encapsulations proposed to the WG. This should
>>> be the very first deliverable of the design team. The actual design work
>>> should start only once the WG has reached consensus on that document.
>>> Especially considering that some of the encapsulations proposed are being
>>> deployed, I think articulating the shortcomings will help to make the best
>>> choice in term of (1) selecting which one will need to be extended, and (2)
>>> designing the actual extensions.
>>>
>>> Below are my proposals on how to modify the wording of the charter.
>>>
>>>
>>>
>>> On 10/20/16 1:37 AM, Bocci, Matthew (Nokia - GB) wrote:
>>>> WG,
>>>>
>>>> We would like to give you an update on the process in the WG for
>>>> progressing the issue of a data plane encapsulation. The chairs and Alia
>>>> believe that the best way forward is to progress a single encapsulation
>>>> format that addresses the technical concerns raised on the list in the
>>>> recent discussions. This would address the clear overall consensus of the
>>>> Berlin meeting and list for a single encapsulation.
>>>>
>>>> The strategy should be to take one of the three existing encapsulations
>>>> and enhance it to address these concerns. This would become the standards
>>>> track output of the WG. The existing three drafts (GENEVE, GUE and
>>>> VXLAN-GPE) should be forwarded to the IESG as informational after the
>>>> standards track draft specifying the single encapsulation. This provides an
>>>> opportunity for those encapsulations to be documented and maintained.
>>>>
>>>> The single encapsulation should be viewed as one that the WG and
>>>> industry can converge around for the future.
>>>>
>>>> We have created a design team to progress work on a single encapsulation
>>>> that can form the basis or work going forward. The design team members are:
>>>> Michael Schmidt, Uri Elzur, Ilango Ganga, Erik Nordmark, Rajeev Manur,
>>>> Prankaj Garg. Many thanks to these individuals for their help.
>>>>
>>>> Please see below for a draft charter for the design team. Please review
>>>> the charter and send comments to the list by 2nd November 2016.
>>>>
>>>> Regards,
>>>>
>>>> Matthew and Sam
>>>>
>>>>
>>>> ====
>>>> NVO3 Encapsulation Design team 2016
>>>>
>>>> Problem Statement
>>>> The NVO3 WG charter states that it may produce requirements for network
>>>> virtualization data planes based on encapsulation of virtual network traffic
>>>> over an IP-based underlay data plane. Such requirements should consider OAM
>>>> and security. Based on these requirements the WG will select, extend, and/or
>>>> develop one or more data plane encapsulation format(s).
>>>>
>>>> This has led to drafts describing three encapsulations being adopted by
>>>> the working group:
>>>> - draft-ietf-nvo3-geneve-03
>>>> - draft-ietf-nvo3-gue-04
>>>> - draft-ietf-nvo3-vxlan-gpe-02
>>>>
>>>> Discussion on the list and in face-to-face meetings has identified a
>>>> number of technical problems with each of these encapsulations. Furthermore,
>>>> there was clear consensus at the IETF meeting in Berlin that it is
>>>> undesirable for the working group to progress more than one data plane
>>>> encapsulation. Although consensus could not be reached on the list, the
>>>> overall consensus was for a single encapsulation (RFC2418, Section 3.3).
>>>> Nonetheless there has been resistance to converging on a single
>>>> encapsulation format, although doing so would provide the best benefit to
>>>> the industry.
>>>
>>> The portion of the last sentence that follows the comma ("although doing
>>> so would provide the best benefit to the industry") doesn't seem to be
>>> adding anything to the charter. I'd suggest it could be removed.
>>>
>>>>
>>>> Design Team Goals
>>> The design team should clearly articulate in a draft which are the
>>> shortcomings of the proposed encapsulations, and where they fall short in
>>> addressing the NVO3 architectural requirements.
>>>
>>> Once the 'shortcomings' draft has reached consensus of the WG,
>>>> The design team should take one of the proposed encapsulations and
>>>> enhance it to address the technical concerns.
>>>> Backwards compatibility with the chosen encapsulation and the simple
>>>> evolution of deployed networks as well as applicability to all locations in
>>>> the NVO3 architecture
>>> , together with the design goals articulated in the 'shortcoming' draft,
>>>
>>>> are goals. The DT should specifically avoid a design that is burdensome
>>>> on hardware implementations, but should allow future extensibility. The
>>>> chosen design should also operate well with ICMP and in ECMP environments.
>>>> If further extensibility is required, then it should be done in such a
>>>> manner that it does not require the consent of an entity outside of the
>>>> IETF.
>>>>
>>>> Timeline
>>>> The design team should
>>> first produce the 'shortcomings' draft, get it adopted by the WG, and
>>> then
>>>
>>>> produce a first draft describing the proposal by end of January 2017.
>>>> Target adoption by the WG by March 2017 IETF.
>>>>
>>> (those two dates may need to be adjusted accordingly)
>>>
>>>
>>> Thanks,
>>> Fabio
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> nvo3 mailing list
>>>>
>>>> nvo3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>