Subject: Re: [lisp] RFC6830bis and multiprotocol support

From: "Marc Portoles Comeras (mportole)" <[email-masked]>
Date: Mon, 4 Dec 2017 05:28:43 +0000

+1 too.
This extension enables the possibility to carry L2 packets and provides a path to completely support the eid-mobility draft.

Marc

From: lisp <[email-masked]> on behalf of "Vina Ermagan (vermagan)" <[email-masked]>
Date: Thursday, November 30, 2017 at 10:55 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [lisp] RFC6830bis and multiprotocol support

+1 on proposed extension.

This would enable LISP to carry L2 payload and NSH as well, which are all implemented in FD.io (VPP) and and interoperable with ODL Mapping Server.

Best,
Vina

From: lisp <[email-masked]<mailto:[email-masked]>> on behalf of Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 30, 2017 at 7:32 AM
To: Albert Cabellos <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lisp] RFC6830bis and multiprotocol support

+1 here too. I can do an implantation so I can interoperate with the other implementations.

Dino

On Nov 30, 2017, at 2:46 AM, Albert Cabellos <[email-masked]<mailto:[email-masked]>> wrote:
Hi all

Support proposed 6830bis extension.

This is indeed implmemented in OOR.

Albert

On Thu, Nov 30, 2017 at 9:47 AM, Albert López <[email-masked]<mailto:[email-masked]>> wrote:
+1

I also support extending RFC 6830bis as suggested. We have an initial implementation of LISP-GPE in OOR and we think this extension could be really useful.

Albert López

El 30/11/17 a les 07:32, Florin Coras ha escrit:
+1

The LISP implementation in FD.io<http://FD.io> VPP makes use of it to distinguish between Ethernet, IP and NSH payloads.

Florin

On Nov 29, 2017, at 10:20 PM, Victor Moreno (vimoreno) <[email-masked]<mailto:[email-masked]>> wrote:

I’m strongly supportive of this proposal as it completes the necessary specifications to support the L2 services proposed in the eid-mobility draft.
Victor

On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <[email-masked]<mailto:[email-masked]>> wrote:
sounds good.

Fabio

On 11/29/17 3:13 PM, Dino Farinacci wrote:

I’d also add before the last sentence:

If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are set to 0.

Dino

On Nov 29, 2017, at 3:07 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:

On 11/29/17 3:05 PM, Dino Farinacci wrote:
How about this wording Fabio:

P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used for the Next Protocol field. When the N-bit is also set with the P-bit, the Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, the Version field is the middle 16 bits. Details on Next Protocol field usage are described in [draft-lewis-lisp-gpe].

Comments?
much better.

Thanks,
Fabio

Dino

On Nov 29, 2017, at 2:49 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:

Definition of the P bit will look like:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, Nonce length, when used, is limited to 16 bits and the lenght
      of the Source and Destination Map-Version fields, when used, is limited
      to 8 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:

Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:
On 11/29/17 2:36 PM, Dino Farinacci wrote:
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.
Well it could be. Just like you did with the Nonce field. Make the Version field the middle 16-bits. So V and P can be set at the same as well as N and P.

Dino

Good point, shortening versions to 8 bits...

Seems fine to me.

Fabio

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________

lisp mailing list

[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 14 Dec 2017 11:58:39 +0100

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-masked]> 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 <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: 
> 
>       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. 
>      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. 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Dec 2017 09:01:24 -0800

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-masked]> wrote:
> 
> His All,
> 
>> 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).

---

From: Fabio Maino <[email-masked]>
Date: Thu, 14 Dec 2017 09:59:18 -0800

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 14 Dec 2017 10:00:34 -0800

It is different but I’m okay with your suggestion.

Dino

> On Dec 14, 2017, at 9:59 AM, Fabio Maino <[email-masked]> 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?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Dec 2017 13:11:31 -0500

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:
>> 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
>>
>>> 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.
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>>> 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).
>>>>     I \ 
>>>>     P   
>>>> 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.
>>>>
>>>> I can very quickly update the LISP-GPE draft to reflect this, but I 
>>>> wanted to hear what the group thinks first.
>>>>
>>>> Thanks,
>>>> Fabio
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Fabio Maino <[email-masked]>
Date: Thu, 14 Dec 2017 10:28:16 -0800

> special in terms of working group formal actions.
agree. Doing it seems to be helpful whatever the WG decides to do with 
6830bis.

> 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
>
>> 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?
>>
>>>> for future use. draft-lewis-lisp-gpe will than allocate this last 
>>>> bit and detail the operations.
>>>>
>>>>> This is based on using the last reserved bit in the LISP header as 
>>>>> P bit to indicate support for multiprotocol encapsulation, as 
>>>>>        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
>>>>> I can very quickly update the LISP-GPE draft to reflect this, but 
>>>>> I wanted to hear what the group thinks first.
>>>>>
>>>>> Thanks,
>>>>> Fabio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 15 Dec 2017 10:08:46 +0100

> On 14 Dec 2017, at 19:28, Fabio Maino <[email-masked]> wrote:
> 
>> 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.)
> 
> 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
>>

---

From: Fabio Maino <[email-masked]>
Date: Fri, 15 Dec 2017 08:17:27 -0800

Sounds good Luigi.

I have just updated https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 
that has now an intended status of standard track.

We are ready for WG adoption.

Thanks,
Fabio

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Dec 2017 11:26:40 -0500

I have issued the adoption call.

There is one obvious question that does not block adoption, but does 
block completion.  Is there some way we can use a common registry for 
the next protocol field for this, vxlan gpe, and NSH?

Yours,
Joel

On 12/15/17 11:17 AM, Fabio Maino wrote:
>>>> 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.)
>>> 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.
>>
>> 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.
>>
>>>> long as we leave it reserved in 6830bis, LISP-GPE can assign it. 
>>>> That is what RFCs and registries are for.
>>>>>> 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
>>>>>>
>>>>>>> creating an authoritative dependency on a to a document that as 
>>>>>>> for now is not even WG item.
>>>>>>> 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.
>>>>>>>
>>>>>>>> This is based on using the last reserved bit in the LISP header 
>>>>>>>> as P bit to indicate support for multiprotocol encapsulation, as 
>>>>>>>>         The P-bit is set to 1 to indicate the presence of the 8 
>>>>>>>> bit Next
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> I can very quickly update the LISP-GPE draft to reflect this, 
>>>>>>>> but I wanted to hear what the group thinks first.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Fabio
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>

---

From: Fabio Maino <[email-masked]>
Date: Fri, 15 Dec 2017 08:39:20 -0800

right.

Up to now the authors of the related documents have made an effort to 
keep the Next Protocol registries aligned, but it would be nice to have 
a single registry for the three applications.

Fabio

On 12/15/17 8:26 AM, Joel M. Halpern wrote:
>> I have just updated 
>> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 that has now an 
>> intended status of standard track.
>>
>>>>> 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.)
>>>> 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.
>>>
>>> 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.
>>>
>>>> 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
>>>>
>>>>
>>>>>>>> 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.
>>>>>>>> reserved for future use. draft-lewis-lisp-gpe will than 
>>>>>>>> allocate this last bit and detail the operations.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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 
>>>>>>>>>         The P-bit is set to 1 to indicate the presence of the 
>>>>>>>>> 8 bit Next
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>