Subject: [lisp] Proposing "Encapsulation Format" LCAF type

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 12:45:42 -0800

I've been having discussions with various people and there is a rough concensus that if the LISP mapping system can aid in helping encapsulators know what encapsulation formats a decapsulator supports, we will get better interoperability in the face of the myriad of overlay data-planes that are being proposed in the IETF.

Here is the section that was added to the LCAF draft:

Proposed -07 and html diff also enclosed.

Dino

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 13 Nov 2014 20:51:23 +0000

I think this is a good idea, but I believe that flags are the wrong way to encode this information, as the number is surely going to grow over time.  For instance, an (8 bit?) field managed by an IANA registry seems more clear, and appropriate.

Also, encoding the capabilities is only one aspect, I believe we need to indicate the preference of the decapsulator, as there could be performance variations - or even sub-capabilities (like LSBs) that are or are not supported.

-Darrel
On Nov 13, 2014, at 12:45 PM, Dino Farinacci <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
> <draft-ietf-lisp-lcaf-07.txt><rfcdiff-lisp-lcaf-06-to-07.html>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 14:10:07 -0800

> I think this is a good idea, but I believe that flags are the wrong way to encode this information, as the number is surely going to grow over time.  For instance, an (8 bit?) field managed by an I…

I thought about making it more general but I really don't want to encourage more encapsulations. This situation of having so many data-planes is certainly not a feature but really a uncoordinated bug. And I hope the market will allow this problem to converge to LESS data-planes and not more.

> Also, encoding the capabilities is only one aspect, I believe we need to indicate the preference of the decapsulator, as there could be performance variations - or even sub-capabilities (like LSBs)…

That creates more combinations and more things for network operators to deal with. This is not a policy parameter or a traffic engineering feature, this is just so multiple vendors can interoperate. This allows encapsulators to know if they can even talk to the decapsulator. This allows L2 and L3 overlays to use one control-plane (the LISP mapping database).

Dino

---

From: Damien Saucez <[email-masked]>
Date: Thu, 13 Nov 2014 13:30:03 -1000

Shouldn't we have some way to allow option for encapsulation? Each encap system has a set of parameters that should be possible to add here. 

Damien Saucez 

> On 13 Nov 2014, at 10:45, Dino Farinacci <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 15:16:30 -1000

> Shouldn't we have some way to allow option for encapsulation? Each encap

Not sure what you mean exactly Damien.

If you want some general option negotiation, remember the working group was not thrilled about capability negotiation in the mapping database?

Dino

> system has a set of parameters that should be possible to add here. 
> 
> Damien Saucez 
> 
> 
>

---

From: Damien Saucez <[email-masked]>
Date: Thu, 13 Nov 2014 16:58:19 -1000

> If you want some general option negotiation, remember the working group was not thrilled about capability negotiation in the mapping database?

My point was that if we permit to specify different encapsulation techniques,
we have also to give the room to specify parameters associated to the
encapsulation scheme (e.g., a port number, a cookie, )

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Nov 2014 19:03:27 -0800

> encapsulation scheme (e.g., a port number, a cookie, )

As for the port number, the references are in the description of each bit. And the data-plane protocol spec indicates what port is used.

As for parameters, well, right now there aren't any and requirements are vague on parameters.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Nov 2014 12:20:20 -0800

I sent this out a couple of weeks ago. There has been some discussion but wanted to move this along. So bringing this back on the list.

I had some private discussions with Damien and Darrel, who had comments on the idea as well as the format of this new Encapsulation Format LCAF type. I would like to summarize the discussion and open discussion up on the list.

I would like to submit this by end of week if there are no strong objections.

To summarize the comments from Damien, Darrel, Luigi, and Joel (please correct me if I missed anything):

(1) My goal of this new LCAF type was to create a specific need to identify what encapsulations a decapsulator can support and not make this a general negotiation facility. The proposal is to not document all types of encapsulation formats that have ever been designed in the IETF but ones that are or may gain popularity in the industry for data-center overlay applications.

(2) There was a request to make the format more general to allow data-plane options to be transmitted in Map-Reply messages. The current format uses only 7 bits out of 32 bits, so future encapsulations can be added. Therefore, the current format is extensible but purposely not generally extensible. If we need to add anything more, we can always add new LCAF types in the future.

(3) A compromise among Dino, Darrel, and Damien was to submit what we have now for experimentation and to discuss more about a adding an LCAF type that will more general to convey data-plane parameters. The chairs indicated we should discuss adding this as a WG item when the recharter discussions occur.

See diff enclosed.

Thanks,
Dino

> Begin forwarded message:
> 
> From: Dino Farinacci <[email-masked]>
> Subject: Proposing "Encapsulation Format" LCAF type
> Date: November 13, 2014 at 12:45:42 PM PST
> To: LISP mailing list list <[email-masked]>
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 27 Nov 2014 16:34:26 +0100

Hi All,

I would like to encourage the WG to post their thoughts about Dino’s proposal of a new LCAF type for Encapsulation Format.

Also, a couple of corrections/Additions to Dino’s mail.

About point (1) of Dino’s mail: 

The proposed encoding is based on a bitwise approach that today reserves specific bits to encapsulation formats that at this time are not WG documents anywhere in the IETF. The WG should be aware that the dependencies introduced in the document may slow down its progress.
Dino thinks that this will be settled before LCAF will go to last call. 
Bits reserved for disappeared encapsulations will be not used anymore.

About point (3) of Dino’s mail:

The correct question the chairs would like to see answered the following: 

Is the WG OK to work on the proposed encoding and push the work on a more general format to later times (i.e. after rechartering)?

If not, have people any alternative suggestion?

Again: please comment in order to make progress.

ciao

Luigi

> On 25 Nov 2014, at 21:20, Dino Farinacci <[email-masked]> wrote:
> 
> <rfcdiff-lisp-lcaf-06-to-07.html>
> 
> <draft-ietf-lisp-lcaf-07.txt>
> 
> 
> 
>> Begin forwarded message:
>>

---

From: Lori Jakab <[email-masked]>
Date: Thu, 27 Nov 2014 18:13:16 +0200

> Again: please comment in order to make progress.

I have heard a few times the accusation that LISP doesn’t properly separate the control and data planes.  I think this proposal is a very good idea, and shows just how untrue that accusation is.  So I think the WG should work on the proposed encoding.

-Lori

---

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Nov 2014 10:24:04 +0400

Hi Luigi,

> I would like to encourage the WG to post their thoughts about Dino’s proposal of a new LCAF type for Encapsulation Format.

I keep worrying about the implementation consequences of stuffing so much different types of information into an AF. That concern isn't only for this new LCAF type though but about feature creep in LISP/LCAF in general.

Cheers,
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Nov 2014 08:53:58 -0500

> I keep worrying about the implementation consequences of stuffing so much different types of information into an AF. That

Well it's not really a single AF, the encoding is functionally the equivalent to TLV encodings which we have a lot of experience with in dozens of protocols. 

> concern isn't only for this new LCAF type though but about feature creep in LISP/LCAF in general.

The features added to LCAFs are coming from real customer requirements. That is the reason they are being added. As well as, to experiment the protocol with new ideas. 

Dino