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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 29 Jun 2021 11:12:51 -0700

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-6man-grand-05: 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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

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

Thanks for the very good document. It was clear about the need and the solution
choice.

I have some comments, addressing them  I believe will improve the document even
more -

   * Section 3: already a great job done in the terminology section, please add
   the STALE definition to that list with reference.

   * 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.

      * 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.

   * 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.

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?

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Jun 2021 12:14:19 +1000

>    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.

>       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"

>    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."

>    case of unsolicited NAs. May be a hint is enough that it is covered in

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.

>       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

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 30 Jun 2021 08:55:10 +0000

Hi Jen,

Thanks for addressing my comments. All those changes look good to me.

BR
Zahed

On 2021-06-30, 04:14, "Jen Linkova" <[email-masked]> wrote:

    How about:

    I've updated the text: