Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino <[e-mail]>]

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.

>
> 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.

> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp