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.
We are now out of flag bits.
Dino
On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne)
<[email protected] <mailto:[email protected]>> 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 <[email protected]> <mailto:[email protected]>
*To: *
[email protected] <mailto:[email protected]> <[email protected]>
<mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
