[lisp] Éric Vyncke's No Objection on draft-ietf-lisp-rfc6830bis-32: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-32: 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-rfc6830bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. This is really useful work and
the document is easy to read. I also appreciate the way the document handles
IPv6 and IPv4 at the same level. Selecting the UDP source port for ECMP based
on the inner 5-tuple is smart .

Please find below a couple of non-blocking COMMENTs.

I also support Martin Duke's DISCUSS on ICMP.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
I find the use of "prepending a LISP header" unusual. Why not using the word
"encapsulating" in a LISP packet? Or did I miss something? It may also slightly
be confusing when parts of the text use "prepending" and others use
"encapsulating".

-- Section 3 --
In "Egress Tunnel Router (ETR): ", is it required to be a 'server' to be able
to do "A server host can be the endpoint of a LISP tunnel as well.". I would
assume that any host can do it as well. In "Ingress Tunnel Router (ITR):" per
symmetry with ETR, can a server/client host also be the encapsulating endpoint
of a LISP tunnel?

-- Section 4 --
I STRONGLY suggest to remove the "telnet" example and keep only "SSH".

Cosmetic: suggest to add reference to SSH, BGP, SNMP, ...

-- Section 5.3 --
For "outer header", there is specific text for the IPv4 DF-bit, DSCP, ... but
what about specific IPv6 fields such as "flow label"?

Beside the convenience of making a bis document reflecting the original,
defining the "R" bit as reserved when at the same IESG telechat there is the
GPE document is really a missed opportunity IMHO.

Side comment (no need to reply), I am also puzzled why the outer DSCP is copied
to the inner DSCP on decapsulation.

-- Section 10 --
Is it on purpose that IPv6 is ignored in "This is typically done when a /32
address is configured on a loopback interface." ?

-- Section 12 --
What is meant by "flow" in "The Source port SHOULD be the same for all packets
belonging to the same flow." Probably worth defining it as packets with
identical 5-tuple ?

I also suggest not to limit the load-balancing text to LAG but also to any
topology where ECMP occurs.

Is there a reason why the hashing for LAG/load balancing is under the title of
"Routing Locator Hashing"? The UDP source port selection is vaguely related but
different than RLOC hashing.

-- Section 15 --
Unsure whether this performance section is still relevant in 2020, there are
many similar overlay techniques.

== NITS ==

-- Section 1 --
There are some repetitions in this section such as "[I-D.ietf-lisp-rfc6833bis]
specifies the LISP control plane. "

-- Section 3 --
When defining "anycast", I find that "An EID or RLOC can be an anycast address
in each of their own address spaces." is more a property of EID/RLOC than
adding anything to "anycast".