[v6ops] Re: AD Review of: draft-ietf-v6ops-nd-considerations

[Warren Kumari <[e-mail]>]

Excellent, thank you very much!
W


On Sun, Aug 11, 2024 at 10:09 AM, Xipengxiao <[e-mail]> wrote:

> Hi Warren,
>
>
>
> Thank you for the detailed review and suggestion.  We the authors will
> revise and simplify the document and resubmit it.
>
>
>
> XiPeng
>
>
>
> *From:* Warren Kumari <[e-mail]>
> *Sent:* Sunday, August 11, 2024 12:07 AM
> *To:* [e-mail]; IPv6 Operations <v6ops@
> ietf.org>
> *Subject:* AD Review of: draft-ietf-v6ops-nd-considerations
>
>
>
> Hi there, authors (and WG),
>
>
>
> Thank you for this document, and apologies for the delay in reviewing it.
> This is definitely a document that will be very useful — but, in its
> current state, it is difficult to read/understand.  I have spent some time
> reviewing and trying to improve it, and you'll find some examples of
> proposed text revisions at the end of this email.
>
>
>
> Most importantly, though, I *do* agree that this document will be very
> useful once it's ready. Neighbor Discovery is a critical part of the IPv6
> protocol and IPv6 operation, and it is both complicated and sometimes
> fragile. As you state, the issues and mitigations are documented in around
> 30 RFCs. Therefore, finding, reading, and understanding all of these is
> challenging , and having a document which collates and summarizes these
> will be very helpful. That said, I don't think that the document is ready
> for IETF LC / IESG Eval quite yet.
>
>
>
> I went to review the WGLC comments to see how we ended up here, and it
> looks like there has not been very much discussion on the document, other
> than from the authors, and some in-depth comments from Lorenzo.
>
>
>
> General notes:
>
> Much of the document seems very disorganized and, therefore, hard to
> follow. For example, Section 2 is titled "Review of ND Issues", and
> discusses issues, and then Section 3 is titled "Review of ND Solutions" and
> discusses mitigations / solutions — but both issues and solutions are also
> discussed in other sections.
>
>
>
> For example Sec 2.3 ("Router-NCE-on-Demand Causes Forwarding Delay, NCE
> Exhaustion and Lack of Subscriber Management Issues") discusses the issues
> with routers not keeping the neighbor cache entries hot, and mitigations
> are discussed in Section 3.8 ("Gratuitous Neighbor Discovery")... but Sec
> 2.3 also contains some set of mitigations ("To prevent this NCE Exhaustion
> problem, some implementations limit the maximal number of NCEs a router
> will maintain for each host.").
>
>
>
> I think that the document would be *much* better if it listed each issue,
> and then the mitigations that exist to, er, mitigate the issue. That way,
> it is more clear to the reader both what the issue is and what the
> associated mitigation is. The information and table in "3.15. Observations
> on the Solutions" helps significantly with this, but it comes very late in
> the document.
>
>
>
> As a reader of  the document, if I am experiencing issues because my
> router doesn't (yet) have an ND entry for the host, seeing the issue
> described in Sec 2.3 is useful. It would be even more useful if this
> section then discussed solutions for the same, such as RFC 9131, RFC 8273,
> etc.
>
>
>
> Again, I really *do* think that this is a worthwhile document, and
> encourage the WG to review and comment.
>
>
>
> For now I'll return the document to the WG; I'll be more than happy to
> review it more once issues have been addressed.
>
>
>
>
>
>
>
> More specific notes (most of these are only suggestions, feel free to edit
> or push back):
>
> Throughout:
>
> s/link layer/link-layer/
>
> s/in link/on link/ (I think)
>
> s/MAC/MAC address/ (in places like "to find the MAC of the host")
>
>
>
>
>
> Section: Abstract
>
> 1: "Neighbor Discovery (ND) is a key protocol of IPv6 first-hop." — I
> don't really understand this sentence / think it is incomplete. Perhaps
> "Neighbor Discovery (ND) is a critical part of the IPv6 protocol", or "is
> critical for resolving the IPv6 link-layer address" or something? It's not
> only used for "first-hop".
>
>
>
> O: "In some scenarios like wireless networks, multicast can be
> inefficient. In other scenarios like public access networks, hosts may not
> be trustable."
>
> P: "In some scenarios, such as wireless networks, multicast can be
> inefficient. In other scenarios, like public access networks, hosts may not
> be trustable."
>
> C: Note: 2 changes.
>
>
>
> O: "Consequently, ND has potential issues in various scenarios."
>
> C: This sentence doesn't seem to add anything to the paragraph.
>
>
>
> O: "The issues and the solutions for them are documented in more than 30
> RFCs. It is difficult to keep track of all these issues and solutions.
> Therefore, an overview is useful."
>
> P: "The issues and solutions for them are documented in more than 30 RFCs,
> making it challenging to track all these issues and solutions. Therefore,
> an overview document is helpful."
>
> C: Rewritten for clarity / flow.
>
>
>
> O: "This document firstly summarizes the known ND issues and optimization
> solutions into a one-stop reference."
>
> P: "This document summarizes both the known ND issues and the optimization
> solutions into a one-stop reference."
>
> C: There is no "secondly"...
>
>
>
> O: "This simplifies the IPv6 first- hops."
>
> P: As above - this sentence doesn't make much sense - perhaps "link-layer
> resolution"?
>
>
>
>
>
> Section 1:
>
> O: "For description simplicity, GUA DAD and ULA DAD are not further
> distinguished."
>
> P: "GUA DAD and ULA DAD are not further distinguished for simplicity of
> description."
>
> or "In order to simplify description, GUA DAD and ULA DAD are not further
> distinguished within this document".
>
>
>
>
>
>
>
> Section 1.1:
>
> O: "MAC -  To avoid confusion with Link Local Address (LLA), link layer
> address is called MAC in this document."
>
> P: "MAC -  To avoid confusion with Link Local Address (LLA), link-layer
> addresses are referred to as MAC addresses in this document."
>
>
>
> O: "a bridging proxy either passes the message to the host or directly
> answer with the host's MAC."
>
> P: "a bridging proxy either passes the message to the host or directly
> answers with the host's MAC."
>
>
>
> O: "This is also applicable to ULA, but to be simple, it is also called
> GUA Isolation in this document."
>
> P:" This is also applicable to ULA, but, for clarity, it is also called
> GUA Isolation in this document." (or "for simplicity")
>
>
>
>
>
> O: "For example, ND uses no response as an indication of no duplication in
> DAD."
>
> P: "For example, DAD uses the lack of a response as an indication that the
> address is not currently in use."
>
>
>
> O: ". Router's address resolution for hosts: in a large L2 network of N
> hosts, there can be N such multicast messages. This may cause performance
> issues."
>
> C: In a small network of N hosts, there can also be N such multicast
> messages. Please rewrite this (same for the following).
>
>
>
>
>
> Section 2.2:
>
> O: "In some scenarios like public access networks, some hosts may not be
> trustable."
>
> P: "In some scenarios, such as public access networks, some hosts may not
> be trustworthy."
>
>
>
> O: "An attacker host in the link can cause the following security issues
> [RFC3756][RFC9099]:"
>
> P: "An attacker on the link can cause the following security issues
> [RFC3756][RFC9099]:" - throughout the document I think "on the link" makes
> more sense than "in the link".
>
>
>
>
>
>  — This is a only a partial review until structural and editing issues
> have been addressed —-
>
>
>
> Thank you again; I know that making edits to address nits can be annoying,
> but we are expecting many people to read and review the document, and so
> having it polished is important and polite (also, once people start
> commenting on nits, they seem to continue :-) )
>
> W
>