Sounds good Luigi.
I have just updated https://tools.ietf.org/html/draft-lewis-lisp-gpe-04
that has now an intended status of standard track.
We are ready for WG adoption.
Thanks,
Fabio
On 12/15/17 1:08 AM, Luigi Iannone wrote:
On 14 Dec 2017, at 19:28, Fabio Maino <[email protected]> wrote:
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.
That works for me.
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.
That is not correct. As part of my review (Send it out later today) I have seen
that a lot of references that are declared Normative are actually not at all so.
The only Normative reference which is in draft status is 6833bis, which is a
different matter.
So the way to proceed is:
Mark the bit reserved in 6830bis and say nothing. Nobody can allocate the bit
without WG consensus, hence there is risk in proceeding this way.
Adopt LISP-GPE which will be a self contained document allocating the bit.
Ciao
Luigi
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
