> On 14 Dec 2017, at 00:02, Dino Farinacci <[email protected]> wrote: > > 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? >
I will send out my review of 6830bis this weekend at latest. If we converge we can certainly last call the 6830bis while I’ll review the 6833bis and move it forward right after. L. > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
