Re: [lisp] RFC6830bis and multiprotocol support

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) <fbrockne@cisco.com> 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:
> [lisp] RFC6830bis and multiprotocol support
> Date:
> Wed, 29 Nov 2017 14:32:40 -0800
> From:
> Fabio Maino <fmaino@cisco.com>
> To:
> lisp@ietf.org <lisp@ietf.org>
>  
> 
> 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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp