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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Jen,

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

BR
Zahed

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

    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