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

Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 29 April 2015 21:32 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 2E37A1A6FED; Wed, 29 Apr 2015 14:32:20 -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 60MM3P5QLxte; Wed, 29 Apr 2015 14:32:19 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 B10821A872B; Wed, 29 Apr 2015 14:32:15 -0700 (PDT)
Received: by lbcga7 with SMTP id ga7so30428339lbc.1; Wed, 29 Apr 2015 14:32: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:date:message-id :subject:from:to:cc:content-type; bh=KUmmS3u6Li/d1pLMZ8nnkNpYoeXHHOb0k4HsPw0soEM=; b=PRxO3uOF3DpDx65O3aBxBy3L6YhgLRwuhlWc+80cPadGaqa+80oxTFadqS2ZWBWZmB OeSjkCzjscWiaQe5ljcZcEZnyJlh/2b6p49cgK9XBTO2EWAD9zfVxLL2b95JcoK94zPi XcmaePjSEdqUlcgIeoAsaHvqCZTO/2JFKmgqM1B/N34/zN73k4WpOjyYHwSQtORwenZB UE7j8UpWXMpP8JF2+GtLUM/xdXC5V1GpuVLQeylekFefkm5qJsk3ZK2SxrA8ju871vaX cqpF31UWeLqnqpwnIiIzB88a2GTLjNElv/GqHo1x3QXBq9DDDkTm5KdV4k9jYmxUjOsi BHHA==
MIME-Version: 1.0
X-Received: by 10.152.44.225 with SMTP id h1mr929506lam.5.1430343134290; Wed, 29 Apr 2015 14:32:14 -0700 (PDT)
Received: by 10.114.74.225 with HTTP; Wed, 29 Apr 2015 14:32:14 -0700 (PDT)
In-Reply-To: <D166793B.1470AC%kreeger@cisco.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>
Date: Wed, 29 Apr 2015 16:32:14 -0500
Message-ID: <CAC8QAccteZqN6mV8i9F85sRVfh+bbA9w0JYgJzSVUsx_aDBQGg@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/nvo3/IvTJQoR3Avv15uXTBpiG1TzVFqs>
Cc: Benson Schliesser <bensons@queuefull.net>, "draft-quinn-vxlan-gpe@ietf.org" <draft-quinn-vxlan-gpe@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "Paul Quinn (paulq)" <paulq@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: Wed, 29 Apr 2015 21:32:20 -0000

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