Subject: [lisp] RFC6830bis and multiprotocol support

From: Fabio Maino <[email-masked]>
Date: Wed, 29 Nov 2017 14:32:40 -0800

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 1to 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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Nov 2017 14:36:51 -0800

> 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

---

From: Fabio Maino <[email-masked]>
Date: Wed, 29 Nov 2017 14:38:31 -0800

> 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.
Good point, shortening versions to 8 bits...

Seems fine to me.

Fabio

---

From: Fabio Maino <[email-masked]>
Date: Wed, 29 Nov 2017 14:49:17 -0800

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 1to 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:
>>> 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
>>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Nov 2017 15:05:00 -0800

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?

Dino

> On Nov 29, 2017, at 2:49 PM, Fabio Maino <[email-masked]> wrote:
> 
>       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: 
> 
> 
>

---

From: Fabio Maino <[email-masked]>
Date: Wed, 29 Nov 2017 15:07:46 -0800

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

much better.

Thanks,
Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Nov 2017 15:13:57 -0800

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]> wrote:
>

---

From: Fabio Maino <[email-masked]>
Date: Wed, 29 Nov 2017 16:53:51 -0800

sounds good.

Fabio

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Thu, 30 Nov 2017 06:20:48 +0000

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

Dino

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

Comments?
much better.

Thanks,
Fabio

Dino

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

Thanks,
Fabio

Dino

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

---

From: Florin Coras <[email-masked]>
Date: Wed, 29 Nov 2017 22:32:51 -0800

+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]> wrote:
> 
> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> sounds good.
>> 
>> Fabio
>> 
>>>> On Nov 29, 2017, at 3:07 PM, Fabio Maino <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>> On Nov 29, 2017, at 2:49 PM, Fabio Maino <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
>>>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>

---

From: Albert López <[email-masked]>
Date: Thu, 30 Nov 2017 09:47:45 +0100

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

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 30 Nov 2017 11:46:56 +0100

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]> wrote:

> The LISP implementation in FD.io VPP makes use of it to distinguish
> between Ethernet, IP and NSH payloads.
>
> Florin
>
> 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]>
> wrote:
>
> sounds good.
>
> 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
>
>
> 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
>
>
> lisp mailing [email-masked]://www.ietf.org/mailman/listinfo/lisp
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Nov 2017 07:32:27 -0800

+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]> wrote:
> 
> Hi all
> 
>> 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
>> 
>> 
>> 
>>> The LISP implementation in FD.io VPP makes use of it to distinguish between Ethernet, IP and NSH payloads. 
>>> 
>>> Florin
>>> 
>>>> On Nov 29, 2017, at 4:54 PM, Fabio Maino (fmaino) <[email-masked]> wrote:
>>>> 
>>>>> sounds good.
>>>>> 
>>>>> Fabio
>>>>>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 30 Nov 2017 15:36:50 +0000

Fabio,

extending LISP encap with multiprotocol support would be beneficial. It would also give us a way to introduce IOAM into LISP – along very similar lines to what we discussed in Singapore as part of the IOAM with VXLAN-GPE encap discussion.

Thanks, Frank

Subject:

[lisp] RFC6830bis and multiprotocol support

Date:

Wed, 29 Nov 2017 14:32:40 -0800

From:

Fabio Maino <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

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

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Nov 2017 08:32:26 -0800

I strongly suggest that the proponents for the P-bit do not couple this with IOAM because there is a lot more machinery to be described which may be too late for 6830bis. 

When RFC 8061 LISP-crypto was written, the authors anticipated the P-bit and hence why the two low-order bits in the flags filed was selected. 

We are now out of flag bits. 

Dino

> On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) <[email-masked]> wrote:
> 
> Fabio,
>  
> Fabio Maino <[email-masked]>
> To:
> [email-masked] <[email-masked]>
>  
>

---

From: Fabio Maino <[email-masked]>
Date: Thu, 30 Nov 2017 10:46:39 -0800

100% agree Dino.

The proposed changes to RFC6830bis, as discussed so far, are:
- allocate the last reserved bit in RFC6830bis as a P-bit,
- use the last 8-bit of the first word as nonce, and
- use 16 bits only to allocate nonce and versioning fields (when used).

LISP-GPE will reflect the KK bits and will be bit-aligned with 
RFC6830bis (including NLEV bits). This will mean that the OAM bit in 
LISP-GPE will not be there anymore.

What Frank is saying is that this will enable the IOAM use case with 
LISP, because IOAM doesn't actually use the OAM bit, but relies only on 
the Next Protocol field.

Thanks,
Fabio

On 11/30/17 8:32 AM, Dino Farinacci wrote:
> I strongly suggest that the proponents for the P-bit do not couple 
> this with IOAM because there is a lot more machinery to be described 
> which may be too late for 6830bis.
>
> When RFC 8061 LISP-crypto was written, the authors anticipated the 
> P-bit and hence why the two low-order bits in the flags filed was 
> selected.
>
> On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Fabio,
>>
>> extending LISP encap with multiprotocol support would be beneficial. 
>> It would also give us a way to introduce IOAM into LISP – along very 
>> similar lines to what we discussed in Singapore as part of the IOAM 
>> with VXLAN-GPE encap discussion.
>>
>> Thanks, Frank
>>
>> *Subject: *
>>
>> 	
>>
>> *Date: *
>> *From: *
>> Fabio Maino <[email-masked]> <mailto:[email-masked]>
>>
>> *To: *
>>
>> 	
>>
>> [email-masked] <mailto:[email-masked]> <[email-masked]> 
>> <mailto:[email-masked]>
>>
>> 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 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.
>>
>> 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.
>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Nov 2017 10:49:18 -0800

> - use the last 8-bit of the first word as nonce, and 

I think you mean the Next Protocol field and not the nonce.

> LISP-GPE will reflect the KK bits and will be bit-aligned with RFC6830bis (including NLEV bits). This will mean that the OAM bit in LISP-GPE will not be there anymore. 
> 
> What Frank is saying is that this will enable the IOAM use case with LISP, because IOAM doesn't actually use the OAM bit, but relies only on the Next Protocol field. 

Agree. Ack.

Dino

---

From: Fabio Maino <[email-masked]>
Date: Thu, 30 Nov 2017 10:54:39 -0800

> I think you mean the Next Protocol field and not the nonce.

yes!

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Thu, 30 Nov 2017 18:55:12 +0000

+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

Dino

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

Hi all

Albert

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

Albert López

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

sounds good.

Fabio

On 11/29/17 3:13 PM, Dino Farinacci wrote:
I'd also add before the last sentence:

Dino

Comments?
much better.

Thanks,
Fabio

Dino

Thanks,
Fabio

Dino

Seems fine to me.

Fabio

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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Thu, 30 Nov 2017 11:35:00 -0800

The addition of the P-bit/next-protocol is more than welcome. In my
experience with OOR and VPP I can confirm that this feature is already
working flawlessly in both. It is indeed a really flexible thing to
have.

Thanks,
Alberto

---

From: John Lemon <[email-masked]>
Date: Thu, 30 Nov 2017 11:58:06 -0800

Fabio,

+1 more on supporting this proposed extension, and with using it to
bring IOAM into LISP.
Both very useful.

Thanks, John

Subject: [lisp] RFC6830bis and multiprotocol support
Date: Thu, 30 November 2017 15:36 UTC
From: "Frank Brockners (fbrockne)" <[email-masked]><[email-masked]>
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Fabio,

Thanks, Frank

Subject: [lisp] RFC6830bis and multiprotocol support
Date: Wed, 29 Nov 2017 14:32:40 -0800
From: Fabio Maino <[email-masked]><mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Thanks,
Fabio