Re: Zaheduzzaman Sarker's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

[Jen Linkova <[e-mail]>]

On Wed, Jun 30, 2021 at 4:14 AM Zaheduzzaman Sarker via Datatracker
<[e-mail]> wrote:
>    * Section 3: already a great job done in the terminology section, please add
>    the STALE definition to that list with reference.

I've expanded the Neighbor Cache definition with the following:
"The Neighbor Cache entry can be in one of five states, as described
in section 7.3.2 of [RFC4861]:
   INCOMPLETE, REACHABLE, STALE, DELAY, PROBE."

I think copying the state definitions from RFC4861 into the
terminology section is suboptimal, so I include the reference to the
formal definition of each state.

>    * Section 4.1:
>       * Please provide ref to "onlink routers" or add verbose description of
>       it. Best to add this to section 3, even if this might be very well known
>       term to the active participants.

As it's the only place when this term is used, I've just changed that
to "routers on the given network segment/link"

>       * It would be great if there is some text describing what if "multicast
>       traffic should not
>    increase" is not true and what precaution should be taken.

How about:
"Therefore, unsolicited NAs sent by hosts do not lead to
 increased amount of multicast traffic, if the routers on that network
   segment use those NAs to create STALE entries.  Even if the routers
   do not yet implement the proposed changes and discard unsolicited
   NAs,  each host would only send MAX_NEIGHBOR_ADVERTISEMENT
   unsolicited NAs (see Section 6.1.2 each time a global IPv6 address is
   assigned on the interface.  That additional traffic would be a few
   orders of magnitude less than the usual level of Neighbor Discovery
   multicast traffic."

>
>    * Section 4.2 : this section might be improved by providing some information
>    about duplicate entries unless there is no chance of duplicate addresses in
>    case of unsolicited NAs. May be a hint is enough that it is covered in
>    section X.X.

Added the following text to the very end of Section4:
"The next section analyses various scenarios of duplicated addresses
and discusses the potential impact of creating a STALE entry for a
duplicated IPv6 address.

> And one question -
>
>    * Section 5.2 :
>        "Those packets would be sent to the
>       host with the optimistic address instead of its rightful owner."
>
>       Could this problem be amplified to create issues in the network?

I've updated the text:
"However, it should be noted that the probability of such scenario is
rather low as it would require the following things to happen almost
simultaneously (within tens of milliseconds in most cases):
- One host starts using a new IPv6 address and sending traffic without
sending an unsolicited NA first.
- Another host configures the same IPv6 address in Optimistic mode
before the router completes the address resolution for the rightful
owner."


-- 
SY, Jen Linkova aka Furry