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 farina...@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 farina...@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.txtrfcdiff-lisp-lcaf-06-to-07.html ___ 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
Re: [lisp] Proposing Encapsulation Format LCAF type
On Nov 27, 2014, at 5:34 PM, Luigi Iannone g...@gigix.net wrote: 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. 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 ciao Luigi On 25 Nov 2014, at 21:20, Dino Farinacci farina...@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 farina...@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.txtrfcdiff-lisp-lcaf-06-to-07.html ___ 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Proposing Encapsulation Format LCAF type
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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
