Re: [lisp] RFC6830bis and multiprotocol support

["Joel M. Halpern" <[e-mail]>]

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.

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

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