Re: [nvo3] NVO3 WG Adoption of draft-quinn-vxlan-gpe-04

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 01 May 2015 16:25 UTC

Return-Path: <sarikaya2012@gmail.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 69E141A8AA7; Fri, 1 May 2015 09:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no
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 3H8rgDNuL-zb; Fri, 1 May 2015 09:25:42 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 E46D21A8935; Fri, 1 May 2015 09:25:41 -0700 (PDT)
Received: by lbcga7 with SMTP id ga7so67765447lbc.1; Fri, 01 May 2015 09:25:40 -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:date:message-id :subject:from:to:cc:content-type; bh=+Hyroio9jW8Yp9wMzG6B8BEDj3M5LTFpnhVkHKDsk8Q=; b=cv0n7NNgJwBgQfuuFVqC7mAUhnJ01FhcsA4l/hQW4wJaf82PQfs1CCFlLvsB4iWSD0 /2OxzRD3LvRCiTLaEE7sp/IrEE0IZz9V9S1HQXv/SpV3igUnzmsbbOYtoQqFBi92Lfeu UxcEG/zwBUkCW82v+/GkPShQZJ+F0vj8Lb8bbkyBsRnrr7cu5YpP8fXD2i5qUf2v1+Rz shWX7x9blUv8RaL7AltI2w48BzxzyJ2r+SGLwba2gwatKffs9HNAPiXbPussY5pQ58E8 W/pjVGJoSluo8LixZNWawHMWWYRq43NnjTB17L1qVd3LAQVaWK+XU2T8x/Wgt1zqyDL/ 0Xbg==
MIME-Version: 1.0
X-Received: by 10.152.25.167 with SMTP id d7mr8895745lag.108.1430497540452; Fri, 01 May 2015 09:25:40 -0700 (PDT)
Received: by 10.114.74.225 with HTTP; Fri, 1 May 2015 09:25:40 -0700 (PDT)
In-Reply-To: <CAP4=VcjOsbAtrTDwqDiG=D1Fq=NeFnOjkNgNRtC5fTT=p-XVDw@mail.gmail.com>
References: <55358764.9080406@queuefull.net> <CAC8QAcedMhbcs2XjfEYupre5Gt3A+fe_NxfN=ja+KiWRnvLACA@mail.gmail.com> <553FF2FF.6020709@queuefull.net> <CAC8QAcdOpy3YciBS8vEavSrbN1e8dbXDGWV+ZiR1jixpSshBiw@mail.gmail.com> <CAC8QAcdyEaej54tfhdO=+KzjbGvYwZzq0EMhxx=Fdw2kj2AQ3w@mail.gmail.com> <C35FEF60-6278-4BA6-83C0-8FA918561EE1@cisco.com> <CAC8QAce34=8YLPaqzxCX5deRpzwfzC-wYx4fjLsVWt-+8HkD9w@mail.gmail.com> <D166793B.1470AC%kreeger@cisco.com> <CAC8QAccteZqN6mV8i9F85sRVfh+bbA9w0JYgJzSVUsx_aDBQGg@mail.gmail.com> <CAP4=VcgAguiAr5Keav+KyVAJeJG2_Sqi9G_BWcHOXwi-qHcbmw@mail.gmail.com> <CAC8QAccnxTYyare8_wei1ysyMurzB19uS0u2-U2ujG4ES224sQ@mail.gmail.com> <79E0CCDC-7375-49A8-B61D-4F3001D04CE8@cisco.com> <CAP4=VcgMz3TtR45OHxjJV8DjDH6LqOE8B0EnvCKO0eiaGDCAQw@mail.gmail.com> <0145A9DE-93E2-4203-9486-606F8899A00E@cisco.com> <CAP4=VcjOsbAtrTDwqDiG=D1Fq=NeFnOjkNgNRtC5fTT=p-XVDw@mail.gmail.com>
Date: Fri, 01 May 2015 11:25:40 -0500
Message-ID: <CAC8QAcfYW2_M8WjDx0wMXDBJ70f8sqcWM_7WAKMhjNuSRzd2aQ@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Benson Schliesser <bensons@queuefull.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/nvo3/swdZByhbu11mec-Yk7-Y0uTO6KM>
Cc: "Paul Quinn (paulq)" <paulq@cisco.com>, "draft-quinn-vxlan-gpe@ietf.org" <draft-quinn-vxlan-gpe@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>
Subject: Re: [nvo3] NVO3 WG Adoption of draft-quinn-vxlan-gpe-04
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
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: <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, 01 May 2015 16:25:46 -0000

Hi Benson,

Thank you for your kind mail.
Please see inline.

Regards,

Behcet

On Thu, Apr 30, 2015 at 7:01 PM, Benson Schliesser
<bensons@queuefull.net> wrote:
> Hi, Behcet.
>
> Still writing as an individual:
>
> After reading your email (quoted below) several times, I suspect that you
> don't understand the way layering works.


I am willing to learn new things if I missed something. It is always
possible to apologize if I offended someone. I believe here there is
no offense, it is all technical.


> I'm not sure if this is just in the
> context of what NVO3 is doing or in the general case, but I think it is well
> understood by others that have been contributing here. It's up to them to
> decide how much they want to respond to your questions. But I personally
> don't have the time to provide you this education.
>

I am concerned that drafts are being accepted with few or almost no
technical discussions.
If there has been some discussions on the list where my concern has
been addressed, please provide me the link, I am going to check.

I printed the draft and read it again. One thing is they use next
protocol not protocol field as you said. Maybe they are trying to
justify why they need different protocol numbers than already assigned
by IANA.


> Now writing as co-chair:
>
> You can certainly ask people to help you understand and/or explain their
> drafts. I'm very tolerant of open discussion on the list as long as it is
> constructive toward the WG goals.
>
> NVO3 has adopted GUE and VXLAN-GPE, and is in process of adopting GENEVE
> pending an IPR statement from one of the authors. These are potentially
> implemented as overlay data plane encaps.
>
> As a WG chair I am guided by WG consensus. The consensus seems to favor
> these protocols as WG work items. I'm not yet aware of any specific issues
> that need to be addressed by the authors.
>

Let me say this, sorry Benson, no offense to you but in this list I
hardly see chair reviews, unlike most other WGs.

I noticed that the issue tracker has never been used in nvo3.
Once this draft is submitted as WG draft, I am going to be happy to
provide my technical comments on the issue tracker maybe lead the way.


> -Benson
>
>
>
> On Thursday, April 30, 2015, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>>
>> On Thu, Apr 30, 2015 at 6:50 AM, Benson Schliesser
>> <bensons@queuefull.net> wrote:
>> > Hi, Behcet. Just speaking as an individual: I understand the purpose of
>> > GPE
>> > as being the addition of a protocol field to VXLAN.
>>
>> This is where I have concerns.
>> Protocol field is defined for IP header. Ethernet also has a similar
>> field (called Ether Type).
>> In RFC 7348, it is clearly defined that the next protocol is UDP
>> (value 17) for VXLAN.
>> Protocol field values are defined in
>> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>>
>> Yes, there is IPv4 (value 4) and IPv6 (value 41). Just like Ethernet
>> Ether Type has values, I think someone mentioned it.
>>
>> GPE draft is introducing another registry for the protocol field,.
>>
>> There must be some reason why they defined protocol field only for
>> IPv4/v6 not e.g. for UDP.
>>
>> VXLAN is UDP encapsulation, it is not a different protocol.
>>
>> It seems like Paul has different opinion on these, because I noticed
>> he added protocol field to his NSH draft also.
>>
>> Benson, is it OK to ask from Paul why?
>> Or you want to ban me from asking these types of technical questions?
>>
>>
>> > It is not specifically a
>> > IPv4/v6 attribute, but more general.
>>
>> Please see above.
>> > If you don't understand the general
>> > case of how or why v4 and v6 are multiplexed with the lower-layer
>> > protocol
>> > field then I don't think that's specifically germane to the nvo3 mailing
>> > list.
>>
>> I made my point above, please see above.
>> >
>> > As for comparing GUE and VXLAN-GPE, that seems like a fair discussion to
>> > have. But I don't currently see any especially constructive way to do
>> > that.
>> >
>>
>> Can you please then explain it? How are these two compared?
>> I am saying they are different things. GUE is currently being
>> discussed in Intarea list.
>>
>> Regards,
>>
>> Behcet
>> > Cheers,
>> > -Benson
>> >
>> >
>> > On Wednesday, April 29, 2015, Behcet Sarikaya <sarikaya2012@gmail.com>
>> > wrote:
>> >>
>> >>  Is gpe talking about encapsulation of inner packets, i.e. data plane?
>> >> If yes then it is like GUE. Then one would ask why do we need another
>> >> GUE?
>> >>
>> >> Looking at the abstract which says
>> >>
>> >> changes to the VXLAN header
>> >>
>> >> I think the answer is no.
>> >>
>> >> I would understand a few flags like OAM that you defined as extensions
>> >> to
>> >> VXLAN.
>> >>
>> >> But I have trouble understanding next protocol field.
>> >> I think VXLAN encapsulation does not need next protocol field because
>> >> what is being encapsulated is completely defined in RFC7348.
>> >>
>> >> If in the future the need arises that something like NSH also needs to
>> >> be defined then the best way to do is to.define RFC7348bis and add it
>> >> there.
>> >>
>> >> Regards,
>> >>
>> >> Behcet
>> >>
>> >>
>> >> On Wed, Apr 29, 2015 at 2:09 PM, Larry Kreeger (kreeger)
>> >> <kreeger@cisco.com> wrote:
>> >> > Regarding Joe Touch's comment about explicitly NOT indicating IPv4 vs
>> >> > IPv6
>> >> > in the Next Protocol (only indicating IP), I don't see what the
>> >> > advantages
>> >> > of doing this are.  It seems more philosophical.
>> >> >
>> >> > By indicating IPv4/IPv6 in the next protocol, it allows
>> >> > implementations
>> >> > to
>> >> > only make one decision before parsing the IP header.  By doing two
>> >> > steps
>> >> > NP->IP->IPv4/v6, it adds one more parsing step to the implementation,
>> >> > for
>> >> > no gain that I can think of.
>> >> >
>> >> > As Diego pointed out earlier, there is already a precedent in
>> >> > Ethernet
>> >> > for
>> >> > indicating the IP version in the next protocol from the layer below
>> >> > it.
>> >> >
>> >> >  - Larry
>> >> >
>> >> > On 4/29/15 11:36 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com>
>> >> > wrote:
>> >> >
>> >> >>On Wed, Apr 29, 2015 at 1:13 PM, Paul Quinn (paulq) <paulq@cisco.com>
>> >> >>wrote:
>> >> >>>
>> >> >>>> On Apr 29, 2015, at 12:01 PM, Behcet Sarikaya
>> >> >>>> <sarikaya2012@gmail.com>
>> >> >>>>wrote:
>> >> >>>>
>> >> >>>> On Tue, Apr 28, 2015 at 5:03 PM, Behcet Sarikaya
>> >> >>>><sarikaya2012@gmail.com> wrote:
>> >> >>>>> Hi Benson,
>> >> >>>>>
>> >> >>>>> Joe Touch wrote this on intarea list:
>> >> >>>>>
>> >> >>>>> There is no reason for having the GUE header differentiate
>> >> >>>>> between
>> >> >>>>> payload=IPv4 and payload=IPv6. The IP version is addressed by the
>> >> >>>>> version field of the IP header. If GUE encapsulates both type of
>> >> >>>>> IP
>> >> >>>>>the
>> >> >>>>> same way (and it should), it should NOT differentiate between
>> >> >>>>> them
>> >> >>>>> in
>> >> >>>>> its (GUE) header.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> I think the same applies to gpe header.
>> >> >>>>>
>> >> >>>>> Plus the issues on the "NSH" protocol.
>> >> >>>>
>> >> >>>> Curiously if you look at the nsh draft, Section 3.2,
>> >> >>>>
>> >> >>>> NSH Base Header
>> >> >>>>
>> >> >>>> also has a next protocol field with the same encoding.
>> >> >>>>
>> >> >>>> Anybody understands what is going on?
>> >> >>>
>> >> >>> Yes, the concept is that you don't know what you want to carry via
>> >> >>> GPE.
>> >> >>> Today it might be v4, v6, ethernet, NSH or something else.
>> >> >>> Tomorrow,
>> >> >>>who knows?  But more importantly, we need to enable that stacking to
>> >> >>>occur.
>> >> >>>
>> >> >>
>> >> >>
>> >> >>Please convince not me but Joe Touch on v4 and v6 thing.
>> >> >>
>> >> >>> The format of NSH is orthogonal -- as is the format of Ethernet for
>> >> >>>that matter.  From an outer header (i.e. VXLAN-GPE or other) you
>> >> >>> need
>> >> >>> to
>> >> >>>be able to identify the inner protocol.
>> >> >>>
>> >> >>
>> >> >>Are we talking about VM-to-VM communication? I think that is what
>> >> >>VXLAN was designed for.
>> >> >>
>> >> >>Regards,
>> >> >>
>> >> >>Behcet
>> >> >>> Paul
>> >> >>>
>> >> >