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

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 <farinacci@gmail.com> wrote:
> 
> 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
> 
> <rfcdiff-lisp-lcaf-06-to-07.html>
> 
> <draft-ietf-lisp-lcaf-07.txt>
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Dino Farinacci <farinacci@gmail.com>
>> Subject: Proposing "Encapsulation Format" LCAF type
>> Date: November 13, 2014 at 12:45:42 PM PST
>> To: LISP mailing list list <lisp@ietf.org>
>> 
>> 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:
>> 
> <PastedGraphic-10.png>
>> 
>> 
>> 
>> 
>> Proposed -07 and html diff also enclosed.
>> 
>> Dino
>> 
> <draft-ietf-lisp-lcaf-07.txt><rfcdiff-lisp-lcaf-06-to-07.html>
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp