Since there seem to be consensus, can we ask for WG adoption of LISP-GPE
and include it as an informative reference as the other drafts that are
in 6830bis?
Can the chairs open a call for adoption in the mailing list, or do we
need to wait the next IETF?
This might be similar to what Dino proposes below.
Thanks,
Fabio
On 12/14/17 9:01 AM, Dino Farinacci wrote:
I would prefer to not merge the two documents. Should we say in RFC6830bis that
the R-bit is already allocated but don’t way why and make no reference. If no,
I go for option A.
Dino
On Dec 14, 2017, at 2:58 AM, Luigi Iannone <[email protected]> wrote:
His All,
happy to see so much consensus :-)
<chair hat on>
As a chair I have to point out that if you add text in 6830bis to allocate the
last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative
dependency on a to a document that as for now is not even WG item.
This will block the publication of 6830bis as RFC (remember the intro
document…….).
There are two possible solutions:
A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future
use. draft-lewis-lisp-gpe will than allocate this last bit and detail the
operations.
B. We merge the two documents.
I do not have a preference, up to the WG to decide, but better to avoid
document dependencies that will block publication.
<chair hat off>
Ciao
L.
On 29 Nov 2017, at 23:32, Fabio Maino <[email protected]> wrote:
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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
