After I go through Alberto’s response for RFC6833bis and one comment from Albert regarding RFC6830bis, I’ll document the P-bit and reference this spec in RFC6830bis. I plan to send email this week with both updates at one time.
This should be the final updates to both specs. I’d like to request last call and possibly complete it before year-end. Is that possible chairs? Dino > On Dec 13, 2017, at 2:57 PM, Fabio Maino <[email protected]> wrote: > > I have refreshed the LISP-GPE draft > (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit > compatible with the data plane encoding in RFC6830bis, as discussed in the > thread started on Nov. 29 > (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19). > > As a summary of the long thread: > - bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next > Protocol field > > - the Next Protocol field shares 8 bits with the Nonce/Map-Version field > > - when the P-bit is set, the Nonce/Map-Version features are still available > with shorter (16-bit vs 24-bit) Nonce/Map-Version fields > > Thanks, > > Fabio > > > -------- Forwarded Message -------- > > 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
