É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". _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
