> On 14 Dec 2017, at 19:28, Fabio Maino <[email protected]> wrote: > > On 12/14/17 10:11 AM, Joel M. Halpern wrote: >> Let's separate things: >> >> 1) We can have a call for adoption of LISP GPE. Meetings are not special in >> terms of working group formal actions. > agree. Doing it seems to be helpful whatever the WG decides to do with > 6830bis.
That works for me. > >> >> 2) My personal read is that if we assign the bit a meaning in 6830bis, then >> the reference has to be normative, as a reader seeking to understand the RFC >> would need to read the other document to know what the bit meant. (My >> thanks to Luigi for catching this.) > > Sounds reasonable, the reference should be normative then. > > Now, there are other drafts in the normative section: once GPE is adopted we > would be in the same situation, and we could deal with it in the same way we > do for the others. > That is not correct. As part of my review (Send it out later today) I have seen that a lot of references that are declared Normative are actually not at all so. The only Normative reference which is in draft status is 6833bis, which is a different matter. So the way to proceed is: Mark the bit reserved in 6830bis and say nothing. Nobody can allocate the bit without WG consensus, hence there is risk in proceeding this way. Adopt LISP-GPE which will be a self contained document allocating the bit. Ciao Luigi >> 2') I see no reason why the bit should be assigned in 6830bis. As long as >> we leave it reserved in 6830bis, LISP-GPE can assign it. That is what RFCs >> and registries are for. > > It would be helpful to document all the LISP dataplane features in 6830bis. > I think this was one of the goals of having a dataplane document. > > Since we are so close, and there's consensus, if 1 and 2 above makes sense > the WG could start the call for adoption of GPE asap. If that works the WG > could then proceed with the last call for 6830bis. > > Fabio > > >> >> So my personal preference would be to leave the protocol identification bit >> out of 6830bis. >> >> Yours, >> Joel >> >> On 12/14/17 12:59 PM, Fabio Maino 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 > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
