Re: [lisp] LISP Overlay Model

Dino Farinacci <farinacci@gmail.com> Tue, 25 August 2015 16:33 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F9E1A00D0 for <lisp@ietfa.amsl.com>; Tue, 25 Aug 2015 09:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 qZt-2tXsc5vx for <lisp@ietfa.amsl.com>; Tue, 25 Aug 2015 09:33:12 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 9E0D91A00B5 for <lisp@ietf.org>; Tue, 25 Aug 2015 09:33:07 -0700 (PDT)
Received: by padfo6 with SMTP id fo6so12514011pad.3 for <lisp@ietf.org>; Tue, 25 Aug 2015 09:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VbVW2H0CruTUQyHFg3BdiZ96ul5wdhyy3ylQeL0fL5A=; b=y7M9ox0Ouj+Q2lUtStqfIH9QsqYd81ym9+926TeUJeNFd8N5uGYV/RmFuxX16WRIRk jj+yd0HGUbXR6hS8akoRlnrBSp7bgZ2eX2jJGo8tvWBuWqIgAU9D2e2eoENSyq315m6z swWtBUGITGBbPgHlCrFHhEuMVPp81Wws93SifW81mUgFVo2sGfS4r9rOzCSzCHkJdLj4 wBj+UDWx3YIvah6PzZpR7K8WN50lhjM04Lp26kg3AYzJlNeNz+0Yl1AjBz//ZB6Xeq2l ZIuNonZaljRqNBETspRxHkBY+RtHYHIsqvTMvcTCQri+/jnUkeM+t3f59J5v/2v/3e8i oClg==
X-Received: by 10.66.236.74 with SMTP id us10mr59178788pac.64.1440520387307; Tue, 25 Aug 2015 09:33:07 -0700 (PDT)
Received: from [172.20.10.2] ([166.170.42.197]) by smtp.gmail.com with ESMTPSA id pj3sm21642134pdb.6.2015.08.25.09.33.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 09:33:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <55DC76E1.3040109@cisco.com>
Date: Tue, 25 Aug 2015 09:27:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5B700FC-7596-497F-8B03-7FAD548A33EC@gmail.com>
References: <89CA974F-ADB1-444E-BF65-7C2B8C572AA6@gigix.net> <2819C9B6-4BD7-438A-BEF7-6AAB85AD136F@gigix.net> <55DC76E1.3040109@cisco.com>
To: Fabio Maino <fmaino@cisco.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/gKYLa6i8cNEkEYHmowYxK3Pyxxk>
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] LISP Overlay Model
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 25 Aug 2015 16:33:15 -0000

I agree with everything Fabio stated. To me this means, in totality, we support the following data-planes and corresponding well-known port numbers:

(1) L3 LISP ala RFC 6830, port 4341
(2) L2 LISP ala Smith Internet Draft, port 8472
(3) VXLAN already in the field, port 4789
(4) LISP-GPE, port 4341
(5) VXLAN-GPE, port 4790

And nothting else.

Supporting (4) and (5) will allow (2) and (3) to eventually go away. Which means we end up with port 4341 for L2 and L3 overlay support using a LISP header, and L2 and L3 overlay support using a VXLAN header.

And the LISP header and the VXLAN header look so much alike that we can conclude that VXLAN is just a less-feature data-plane than LISP.

We go this route, we head in a direction of *less* encapsulations that do *more* functionality than we have today.

Dino

> On Aug 25, 2015, at 7:08 AM, Fabio Maino <fmaino@cisco.com> wrote:
> 
> As an author, I certainly support inclusion of VXLAN-GPE (and its counterpart LISP-GPE) and I'll continue to contribute to that work.
> 
> Given the wide availability of VXLAN in many HW and SW platforms, it may make sense to include VXLAN as well, especially for the NVO3 use cases. Note that with VXLAN-GPE, support for VXLAN will come almost implicitly.
> 
> 
> Fabio
> 
> 
> On 8/25/15 2:02 AM, Luigi Iannone wrote:
>> Hi All,
>> 
>> Thanks from the reply so far.
>> 
>> What I gather is that there is interest in extending the LISP overlay model to support other data-planes.
>> 
>> What remain unclear is what those data-planes should be.
>> Note that it is impossible to cover all existing data-planes.
>> 
>> Would be helpful if the group gives a clearer direction by suggesting a set encaps to add support for.
>> (this include as well the willingness to directly contribute to the work)
>> 
>> ciao
>> 
>> L.
>> 
>> 
>>> On 10 Aug 2015, at 00:05, Luigi Iannone <ggx@gigix.net> wrote:
>>> 
>>> Hi,
>>> 
>>> LISP provides a rather complete and powerful control-plane, where
>>> by means of LCAF, possibly any existing namespace can be mapped
>>> on each other.
>>> However, the data-plane is not as flexible. The current specifications
>>> allow only IPv4 over IPv6 and vice versa.
>>> 
>>> In order to create what Sharon Barakai defined “map assisted overlays”
>>> more work is needed.
>>> 
>>> In this context the WG should also decide whether just an extended/enhanced
>>> data-plane is sufficient/needed. Or should the scope be slightly larger and
>>> allow as well to support multiple headers type?
>>> Such header are not necessarily defined by the LISP WG
>>> (e.g.  VXLAN-GPE, GENEVE, GUE, etc.)
>>> 
>>> Would the WG be interested in working in extending the LISP overlay model
>>> in order to provide data-plane support for what the control plane already allows?
>>> And what should be the scope?
>>> 
>>> Joel & Luigi
>>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp