Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Lucy yong <lucy.yong@huawei.com> Thu, 26 September 2013 21:06 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40A21E80B5; Thu, 26 Sep 2013 14:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.486
X-Spam-Level:
X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkAA13nTc4nb; Thu, 26 Sep 2013 14:06:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 089F421E8085; Thu, 26 Sep 2013 14:06:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYH84410; Thu, 26 Sep 2013 21:06:28 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 22:05:32 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 22:06:27 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 14:06:23 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt
Thread-Index: AQHOuvfXOEzzW7npoUKyOBoxO9YOZJnYgl2w
Date: Thu, 26 Sep 2013 21:06:22 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D1F16@dfweml509-mbx.china.huawei.com>
References: <20130924150710.B45F118C094@mercury.lcs.mit.edu> <524329EB.7050704@cisco.com> <CF7B7553-BBE5-482C-AB29-D4F3B92680CD@gmail.com> <CAKFn1SHOCV-V+dodAgLk73CBCzv_vYD2rh_KTZnBJrc5i2EC8A@mail.gmail.com> <16DF95BC-8820-4318-899B-DA0AC10BF19E@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452D1EBC@dfweml509-mbx.china.huawei.com> <BB77A3FF-6939-4568-82C2-361F03F4D1E8@gmail.com>
In-Reply-To: <BB77A3FF-6939-4568-82C2-361F03F4D1E8@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.129.68]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Roger Jørgensen <rogerj@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>, "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 21:06:53 -0000

-----Original Message-----
From: Dino Farinacci [mailto:farinacci@gmail.com] 
Sent: Thursday, September 26, 2013 3:35 PM
To: Lucy yong
Cc: Roger Jørgensen; Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

> Dino,
> 
> Current VXLAN format is much simpler format compared to LISP format. To use it with LISP protocol, do you need to modify VXLAN format to support LISP features?

Lucy, the format is exactly the same. If you choose to not implement the LISP data plane features and disable the flags, then it is exactly the same implementation as LISP. 

However ...

VXLAN is actually harder because if you get a cache miss, you have to look in another table to find a group address to encapsulate to. So if you take a closer look under the cover, it is arguably harder. It requires a hardware implementation to build a different lookup memory or partition one memory to do two different types of lookups.

[Lucy] I get it. Thank you for the explanation. It tells me that it is better not going that way.

Lucy

Dino

> 
> Regards,
> Lucy
> 
> -----Original Message-----
> From: Lucy yong
> Sent: Thursday, September 26, 2013 2:44 PM
> To: 'Dino Farinacci'; Roger Jørgensen
> Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org
> Subject: RE: [nvo3] [lisp] New Version Notification for 
> draft-quinn-vxlan-gpe-00.txt
> 
> Please see inline.
> 
> -----Original Message-----
> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf 
> Of Dino Farinacci
> Sent: Thursday, September 26, 2013 1:57 PM
> To: Roger Jørgensen
> Cc: Fabio Maino; nvo3@ietf.org; Noel Chiappa; lisp@ietf.org
> Subject: Re: [nvo3] [lisp] New Version Notification for 
> draft-quinn-vxlan-gpe-00.txt
> 
>> On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci <farinacci@gmail.com> wrote:
>>>> Hi Noel,
>>>> there's certainly no intention of keeping this out of the LISP WG, since this is not part of the charter we just thought an individual submission was more appropriate.
>>>> 
>>>> We just started from the very practical consideration of the proliferation of encapsulations in the data center, and the lack of multiprotocol support in both VXLAN and LISP.
>>> 
>>> Sorry I have to disagree. The protocols that LISP supports are *IP* protocols and the protocols that VXLAN supports are *the rest* since it is layer-2 solution. So this appears to be just rearranging the deck chairs.
>> 
>> This trouble me... why do we want to mix LISP and VXLAN? What is the 
>> gain in it? I only smell complexity. L2 in L3 over L3?
> 
> We shouldn't but let the authors reply. If you want to carry more than IP protocols in LISP, then you use the L2 UDP port and carry MAC addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane, the LISP mapping database using LISP-DDT.
> 
> [Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP protocol. However, Overlay virtual networks that use VXLAN encapsulation may be implemented in other way too, e.g. SDN controller, not LISP protocol. Therefore, there is a desire to extend VXLAN encapsulation to support multiple protocols beside L2 only and make it a generic overlay encapsulation schematics to support an overlay application.
> 
> BTW: IMO: using UDP port to indicate payload type is not elegant design, but acceptable for history reason only.
> 
> Lucy
> 
>> How will a mix of LISP and VXLAN benefit the administrators of 
>> datacenters, end-users in the end?
> 
> The VXLAN authors have to answer that. They came afterwards (by 5 years).
> 
> Dino
> 
>> 
>> 
>> 
>> --
>> 
>> Roger Jorgensen           | ROJO9-RIPE
>> rogerj@gmail.com          | - IPv6 is The Key!
>> http://www.jorgensen.no   | roger@jorgensen.no
>> 
>> (I really start to really dislike gmails new better editor)
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3