Thanks Dino.
Fabio
On 12/13/17 3:02 PM, Dino Farinacci wrote:
After I go through Alberto’s response for RFC6833bis and one comment from
Albert regarding RFC6830bis, I’ll document the P-bit and reference this spec in
RFC6830bis. I plan to send email this week with both updates at one time.
This should be the final updates to both specs. I’d like to request last call
and possibly complete it before year-end. Is that possible chairs?
Dino
On Dec 13, 2017, at 2:57 PM, Fabio Maino <[email protected]> wrote:
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 <[email protected]>
To: [email protected] <[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]
https://www.ietf.org/mailman/listinfo/lisp
