[lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support]

[Fabio Maino <[e-mail]>]

I have refreshed the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit 
compatible with the data plane encoding in RFC6830bis, as discussed in 
the thread started on Nov. 29 
(https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19) 


As a summary of the long thread:

- bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next 
Protocol field

- the Next Protocol field shares 8 bits with the Nonce/Map-Version field

- when the P-bit is set, the Nonce/Map-Version features are still 
available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields


Thanks,

Fabio



-------- Forwarded Message --------

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



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