Thanks for your review Eric. Please see below our replies.
On 7/7/20, 1:02 AM, "lisp on behalf of Éric Vyncke via Datatracker"
<[email protected] on behalf of [email protected]> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for the work put into this document. This is really useful work
and
the document is easy to read.
Please find below a couple of non-blocking COMMENTs (and I would appreciate
a
reply to each of my COMMENTs).
I hope that this helps to improve the document,
Regards,
-éric
== COMMENTS ==
As this document is in the same 'batch'/timing as the RFC 6830 bis, is
there a
reason why this extension is not in the bis document itself?
[FM] there were quite a few changes and discussions introduced in 6830bis. The
WG thought that keeping lisp-gpe as a separate document would simplify the
review process.
-- Section 3 --
What is the reason why not reusing an existing 'next protocol' registry? Or
using a 16-bit Ethernet type like field (as in GRE) ?
[FM] the LISP header uses the last 3 octets in the first 32-bit word for the
nonce/versioning features. We designed a reduced NP field to try to squeeze a
limited version of those features using octets 2-3 of lisp-gpe. It turned out
that the limitations imposed by the shorter field where too much, and
eventually the WG decided to eliminate the nonce/versioning features altogether
from lisp-gpe. Reversing now back to 16-bit NP field, would impact the early
lisp-gpe implementations that have been built so far.
As a side cosmetic note, I would have preferred to have 0x04 for IPv4 and
0x06
for IPv6.
[FM] we decided to assign them incrementally. We really didn’t have enough
meaningful payloads to get up to 6...
"the shim header MUST come before the further protocol" but, if there are
other
headers defined in LISP (I must confess my ignorance on this), should the
shim
header be just after the LISP header ? I.e. the first one of a potential
chain
(cfr IPv6 extension header chains) ?
It is unclear whether a shim header 'next protocol' field can also have a
value
associated to yet another shim header.
[FM] Good catch. We have re-phrased the text to make clear that there might be
multiple shim headers, and they should be in front of the actual payload
identified by NP 0x01-0x7F.
This is ithe new text: " When shim headers are used with other protocols
identified by next protocol values from 0x0 to 0x7D, all the shim headers MUST
come first."
== NITS ==
The document title "LISP Generic Protocol Extension" is generic while the
document is mainly about "multi-protocol encapsulation". Should the title be
changed? As a non-English speaker, I read the title as how to make
any/generic
extension to the LISP protocol and not as a LISP extension to support the
transport of generic/any protocol.
[FM] one can use lisp-gpe to extend the LISP encapsulation protocol to support
generic payloads (IPv6, ethernet, NSH, iOAM, GBP, ...) in addition to IP.
However it is also possible to use lisp-gpe to extend LISP features. For
example, one could use a shim header to implement a nonce/versioning field of
arbitrary size. That's the reason we think of the draft as a LISP Generic
Protocol Extension.
-- Section 3 --
[FM] all the suggestions below are addressed in rev-17
Strongly suggest to make it clear by adding a MUST in "and ignored on
receipt", i.e., "and MUST be ignored on receipt"
"0x05 to 0x7D " the final ':' is missing.
Why not writing " 0x7E, 0x7F:" ?
"deploy new GPE features", GPE is not expanded before this first use (even
if
quite obvious in this document).
s/octect/octet/
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
