It is different but I’m okay with your suggestion. Dino
> On Dec 14, 2017, at 9:59 AM, Fabio Maino <[email protected]> wrote: > > Since there seem to be consensus, can we ask for WG adoption of LISP-GPE and > include it as an informative reference as the other drafts that are in > 6830bis? > > Can the chairs open a call for adoption in the mailing list, or do we need to > wait the next IETF? > > This might be similar to what Dino proposes below. > > Thanks, > Fabio > > On 12/14/17 9:01 AM, Dino Farinacci wrote: >> 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
