Re: 6man w.g. last call for <draft-ietf-6man-grand>

[Jen Linkova <[e-mail]>]

Hi Eric,

Thanks for your review and comments!
In my response below when I say 'done' I mean 'will be fixed in -03
which I'll submit as soon as datatracker gets unlocked'.

On Fri, Jul 17, 2020 at 7:19 PM Eric Vyncke (evyncke)
<evyncke=[e-mail]> wrote:
>
> Without any hat
>
> I obviously support this document and I appreciate the discussion about multicast traffic. Some comments/suggestions below
>
> Section 1: "RFC4861 implies" or "RFC4861 assumes" ?
> Section 1: missing the final '.' at the end of paragraph 2

Fixed.

> Everywhere: ensure to use consistent capitalization for " Link-Layer Address", suggest all lower cases except when introducing acronyms.
> Strongly suggest not to use LLA for link-layer address... as it is confusing with Link-Local Address... What about L2A ? Also some typos such as " link-layaer"

The Terminology section does define 'LLA' as 'Link-Layer Address'. My
main reason to use it was that it's consistent with such
well-established acronyms as 'SLLA' and 'TLLA'. At the same time I
agree that LLA could be easily confused with 'link-local address'. So
I've replaced 'LLA' with 'Link-Layer Address' everywhere but kept SLLA
and TLLA.

> Section 2.1, 1st para: why limiting the last sentence to global IPv6 addresses? Need to check but I guess link-local address may also change (albeit rarely)

The reason the draft does not include link-local addresses is that I'm
not sure it would solve any real problem.
The issue the draft is trying to address has two distinct properties:
1) it affects the transit (not originated by the router) traffic;
2) It disappears as soon as the discovery process finishes.
Therefore scenarios when traffic to link-local destinations is
affected seem to be mostly theoretical. The only real case is one Mark
has mentioned: two hosts communicating using its link-local addresses
via the router. However it still look rather imaginary:
- host A appears on the network (or configures a new link-local
address) either using Optimistic DAD or not including SLLA into RS for
some reason;
- *before* the host A starts NUD for its default gateway address* host
B sends multiple packets (or multiple hosts are sending packets) to
the host A new link-local address (how would the host B know that
address?

I have no problem expanding the scope for all addresses, just not sure
how useful it would be.
How about
1) saying that the host MAY follow the same procedure for informing
the routers about new link-local address?
2) adding a section to discuss why the proposed mechanism has more
sense for GUA than for link-local addresses?

I'd like to hear the host implementers - I'm not sure if they'd prefer
to send those packets for GUA only or it would be simpler to avoid
additional logic and send NAs for any address.

-
>Need to check but I guess link-local address may also change (albeit rarely)

It may indeed. The question is: can we expect a router to receive
flows for that address *before* the router receives either RS with
SLAA or an NS from that address?

> Section 2.1 mixes normative text and explanations. Suggest to create a subsection for explanations/justifications

OK, I've removed the normative language from that section so now it
discusses the proposed changes while Section 4 contains the exact text
using the normative language.

> Section 2.2 the normative does not specify what to do when an ND entry already exist. A pointer to section 3 is really welcome here (even if it immediately follows)

The following sentence has been added to Section 2.2:

The proposed changes do not modify routers behaviour specified in
RFC4861 for the scenario when the corresponding Neighbor Cache entry
already exists.

> Section 2.2 suggest to change " This document suggests that" into "This document updates RFC 4861 so that"
> Section 3.2, if there is no entry, then how can it be 'updated' ?

Fixed.

> Section 4.1.2 sentence " These advertisements MUST be separated by at least RetransTimer seconds." is repeated unnecessary IMHO

Existing 'These advertisements MUST be separated by a least
RetransTimer seconds.' statement in the section-7.2.6 seems to be
related to sending unsolicited NAs to announce the link-layer address
change. However after re-reading the section 7.2.6 I've realized that
the proposed change is suboptimal: I was trying to insert the new text
between two paragraphs describing sending unsolicited NAs for
link-layer address change. It would make the following paragraph
(beginning with 'The Target Address field in the unsolicited
advertisement' a bit confusing. It looks like the better place for the
new text is below, right after

 'Also, a node belonging to an anycast address MAY multicast
unsolicited Neighbor Advertisements for the anycast address when the
   node's link-layer address changes.'

> Please run a spell checker: " nessesary", and possibly other typos

Sure, will be done for -03.

>
> Good job: simple modification, easy to deploy and debug
> -----Original Message-----
> From: ipv6 <[e-mail]> on behalf of Bob Hinden <[e-mail]>
> Date: Wednesday, 15 July 2020 at 19:18
> To: IPv6 List <[e-mail]>
> Cc: Bob Hinden <[e-mail]>
> Subject: 6man w.g. last call for <draft-ietf-6man-grand>
>
>     Hello,
>
>     This message starts a new two week 6MAN Working Group Last Call on advancing:
>
>             Title:    Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-
>                       Hop Routers
>             Author:   Jen Linkova
>         Filename: draft-ietf-6man-grand-00
>         Pages:    11
>         Date:     March 9, 2020
>
>            https://tools.ietf.org/html/draft-ietf-6man-grand
>
>     as a Proposed Standard.
>
>     Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the author.  This last call will
>     end on 29 July 2020.
>
>     Thanks,
>     Bob & Ole
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
SY, Jen Linkova aka Furry