right.
Up to now the authors of the related documents have made an effort to
keep the Next Protocol registries aligned, but it would be nice to have
a single registry for the three applications.
Fabio
On 12/15/17 8:26 AM, Joel M. Halpern wrote:
I have issued the adoption call.
There is one obvious question that does not block adoption, but does
block completion. Is there some way we can use a common registry for
the next protocol field for this, vxlan gpe, and NSH?
Yours,
Joel
On 12/15/17 11:17 AM, Fabio Maino wrote:
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
