On 12/14/17 10:11 AM, Joel M. Halpern wrote:
Let's separate things:
1) We can have a call for adoption of LISP GPE. Meetings are not
special in terms of working group formal actions.
agree. Doing it seems to be helpful whatever the WG decides to do with
6830bis.
2) My personal read is that if we assign the bit a meaning in 6830bis,
then the reference has to be normative, as a reader seeking to
understand the RFC would need to read the other document to know what
the bit meant. (My thanks to Luigi for catching this.)
Sounds reasonable, the reference should be normative then.
Now, there are other drafts in the normative section: once GPE is
adopted we would be in the same situation, and we could deal with it in
the same way we do for the others.
2') I see no reason why the bit should be assigned in 6830bis. As
long as we leave it reserved in 6830bis, LISP-GPE can assign it. That
is what RFCs and registries are for.
It would be helpful to document all the LISP dataplane features in
6830bis. I think this was one of the goals of having a dataplane document.
Since we are so close, and there's consensus, if 1 and 2 above makes
sense the WG could start the call for adoption of GPE asap. If that
works the WG could then proceed with the last call for 6830bis.
Fabio
So my personal preference would be to leave the protocol
identification bit out of 6830bis.
Yours,
Joel
On 12/14/17 12:59 PM, Fabio Maino wrote:
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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
