Fabio, +1 more on supporting this proposed extension, and with using it to bring IOAM into LISP. Both very useful.
Thanks, John Subject: [lisp] RFC6830bis and multiprotocol support Date: Thu, 30 November 2017 15:36 UTC From: "Frank Brockners (fbrockne)" <[email protected]><[email protected]> To: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Fabio, extending LISP encap with multiprotocol support would be beneficial. It would also give us a way to introduce IOAM into LISP – along very similar lines to what we discussed in Singapore as part of the IOAM with VXLAN-GPE encap discussion. Thanks, Frank Subject: [lisp] RFC6830bis and multiprotocol support Date: Wed, 29 Nov 2017 14:32:40 -0800 From: Fabio Maino <[email protected]><mailto:[email protected]> To: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore. This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe). The header, as specified in section 5.1, would look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the text in section 5.3 that reserves the 6th bit would be replaced by: P: The P-bit is the Next Protocol bit. When this bit is set to 1, the V-bit MUST be set to 0 and the Nonce length, when used, is limited to 16 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: x x x 0 x 1 x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field. 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. This would address the multiprotocol working item included in the current charter. I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first. Thanks, Fabio
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
