Subject: [lisp] LISP Overlay Model

From: Luigi Iannone <[email-masked]>
Date: Mon, 10 Aug 2015 00:05:29 +0200

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Aug 2015 15:41:27 -0700

> And what should be the scope?

If the charter supports NVO3 use-cases, then the answer must be yes.

Dino

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Thu, 13 Aug 2015 22:49:15 +0000

Yes to extending the overlay model to support multiple data plane encap
types.

Vina

On 8/9/15 3:05 PM, "Luigi Iannone" <[email-masked]> wrote:

>In order to create what Sharon Barakai defined ³map assisted overlays²
>more work is needed.
>
>_______________________________________________
>lisp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lisp

---

From: Florin Coras <[email-masked]>
Date: Fri, 14 Aug 2015 01:38:20 +0200

+1 

Florin

> On Aug 14, 2015, at 12:49 AM, Vina Ermagan (vermagan) <[email-masked]> wrote:
>

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Fri, 14 Aug 2015 03:54:07 +0000

+1

Victor

> On Aug 13, 2015, at 4:40 PM, Florin Coras <[email-masked]> wrote:
> 
> +1 
> 
> Florin
>

---

From: Lori Jakab <[email-masked]>
Date: Fri, 14 Aug 2015 11:25:37 +0300

> (e.g.  VXLAN-GPE, GENEVE, GUE, etc.)

I think supporting multiple headers is the better option.

-Lori

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 14 Aug 2015 13:39:08 +0200

> I also think that multiple header support makes a lot of sense

Alberto

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 25 Aug 2015 11:02:22 +0200

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 <[email-masked]> wrote:
> 
> Hi,
>

---

From: Fabio Maino <[email-masked]>
Date: Tue, 25 Aug 2015 07:08:33 -0700

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

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 25 Aug 2015 14:47:42 +0000

Support.

--szb

> On Aug 25, 2015, at 7:08 AM, Fabio Maino <[email-masked]> 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
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Aug 2015 09:27:18 -0700

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

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 26 Aug 2015 10:45:56 +0200

<no hats on>

> On 25 Aug 2015, at 18:27, Dino Farinacci <[email-masked]> wrote:
> 

I do not think this would work. 
How can you make the difference between a LISP-GPE and a LISP header when both use the same UDP port?
You would need side information about whether or not an xTR supports or not the LISP-GPE header.
Feasible, but I fear that we will end up with so many corner cases that will make the solution complex.

Further, LISP-GPE and VXLAN-GPE are so similar that makes me wonder why should we have both?

L.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Aug 2015 10:07:14 -0700

<no hats on>
> How can you make the difference between a LISP-GPE and a LISP header when both use the same UDP port?

There really isn’t any difference. The P-bit is cleared in the RFC 6830 (because it is unspecified). I was being explicit above to not exclude LISP-GPE.

> You would need side information about whether or not an xTR supports or not the LISP-GPE header.

There is compatability text in the LISP-GPE draft to handle this. But that is why I proposed the Encapsulation Format Type LCAF, so an ITR knows the data-plane formats the ETR supports. We’ll need to depend on this to support multiple data-planes.

> Feasible, but I fear that we will end up with so many corner cases that will make the solution complex.

Well I agree 100%. And I would push for just (1) and (2) only. But people will object. 

So if you really want to be practical (which I do want to be), we should support (1) and (3) only. Because that is what is already deployed in the field. (1) for L3 overlays, and (2) for L2 overlays.

The data-plane situation in NVo3 is a total mess with no adult supervision. I have to state this because we need to be careful how much mess we bring into the LISP WG.

> Further, LISP-GPE and VXLAN-GPE are so similar that makes me wonder why should we have both?

This discussion has already occurred. You need the authors to justify this.

Dino