I would prefer to not merge the two documents. Should we say in RFC6830bis that the R-bit is already allocated but don’t way why and make no reference. If no, I go for option A.
Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone <[email protected]> wrote: > > His All, > > happy to see so much consensus :-) > > <chair hat on> > > As a chair I have to point out that if you add text in 6830bis to allocate > the last bit and refer to draft-lewis-lisp-gpe you are creating an > authoritative dependency on a to a document that as for now is not even WG > item. > This will block the publication of 6830bis as RFC (remember the intro > document…….). > > There are two possible solutions: > > A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future > use. draft-lewis-lisp-gpe will than allocate this last bit and detail the > operations. > > B. We merge the two documents. > > I do not have a preference, up to the WG to decide, but better to avoid > document dependencies that will block publication. > > <chair hat off> > > Ciao > > L. > > > >> On 29 Nov 2017, at 23:32, Fabio Maino <[email protected]> wrote: >> >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
