I strongly suggest that the proponents for the P-bit do not couple this with IOAM because there is a lot more machinery to be described which may be too late for 6830bis.
When RFC 8061 LISP-crypto was written, the authors anticipated the P-bit and hence why the two low-order bits in the flags filed was selected. We are now out of flag bits. Dino > On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) <[email protected]> > wrote: > > 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]> > To: > [email protected] <[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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
