I’ll try to get an update to you before then so it can be easier. Thanks Luigi.
Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone <[email protected]> wrote: > > > >> 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
