+1 too. This extension enables the possibility to carry L2 packets and provides a path to completely support the eid-mobility draft.
Marc From: lisp <[email protected]> on behalf of "Vina Ermagan (vermagan)" <[email protected]> Date: Thursday, November 30, 2017 at 10:55 AM To: "[email protected]" <[email protected]> Subject: Re: [lisp] RFC6830bis and multiprotocol support +1 on proposed extension. This would enable LISP to carry L2 payload and NSH as well, which are all implemented in FD.io (VPP) and and interoperable with ODL Mapping Server. Best, Vina From: lisp <[email protected]<mailto:[email protected]>> on behalf of Dino Farinacci <[email protected]<mailto:[email protected]>> Date: Thursday, November 30, 2017 at 7:32 AM To: Albert Cabellos <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [lisp] RFC6830bis and multiprotocol support +1 here too. I can do an implantation so I can interoperate with the other implementations. Dino On Nov 30, 2017, at 2:46 AM, Albert Cabellos <[email protected]<mailto:[email protected]>> wrote: Hi all Support proposed 6830bis extension. This is indeed implmemented in OOR. Albert On Thu, Nov 30, 2017 at 9:47 AM, Albert López <[email protected]<mailto:[email protected]>> wrote: +1 I also support extending RFC 6830bis as suggested. We have an initial implementation of LISP-GPE in OOR and we think this extension could be really useful. Albert López El 30/11/17 a les 07:32, Florin Coras ha escrit: +1 The LISP implementation in FD.io<http://FD.io> VPP makes use of it to distinguish between Ethernet, IP and NSH payloads. Florin On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) <[email protected]<mailto:[email protected]>> wrote: I’m strongly supportive of this proposal as it completes the necessary specifications to support the L2 services proposed in the eid-mobility draft. Victor On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <[email protected]<mailto:[email protected]>> wrote: sounds good. Fabio On 11/29/17 3:13 PM, Dino Farinacci wrote: I’d also add before the last sentence: If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are set to 0. Dino On Nov 29, 2017, at 3:07 PM, Fabio Maino <[email protected]<mailto:[email protected]>> wrote: On 11/29/17 3:05 PM, Dino Farinacci wrote: How about this wording Fabio: P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used for the Next Protocol field. When the N-bit is also set with the P-bit, the Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, the Version field is the middle 16 bits. Details on Next Protocol field usage are described in [draft-lewis-lisp-gpe]. Comments? much better. Thanks, Fabio Dino On Nov 29, 2017, at 2:49 PM, Fabio Maino <[email protected]<mailto:[email protected]>> wrote: Definition of the P bit will look like: P: The P-bit is the Next Protocol bit. When this bit is set to 1, Nonce length, when used, is limited to 16 bits and the lenght of the Source and Destination Map-Version fields, when used, is limited to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details. The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol field encoded as: Do you think the overall proposed extension makes sense? Thanks, Fabio On 11/29/17 2:38 PM, Fabio Maino wrote: On 11/29/17 2:36 PM, Dino Farinacci wrote: The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that. Well it could be. Just like you did with the Nonce field. Make the Version field the middle 16-bits. So V and P can be set at the same as well as N and P. Dino Good point, shortening versions to 8 bits... Seems fine to me. Fabio _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
