Subject: [v6ops] AD review of draft-ietf-v6ops-nd-cache-init

From: Warren Kumari <[email-masked]>
Date: Thu, 20 Aug 2020 18:13:21 -0400

Hi there authors, and WG,

Thank you very much for this document -- as you probably know, I
already think it is an important and useful one.

As a result of the recent discussion at the plenary, I'm being
especially diligent (nit-picky?) with editorial stuff before starting
IETF LC, and so ran this through a spell and grammar check. Be ye not
afraid, the below are all nits, and should be easy and fast to
address...

Please SHOUT LOUDLY once you've had a chance to address them and I'll
kick off LC.

Thanks again,
W

O: A very common use case is a mobile device sending probes to detect
the Internet connectivity and/or the captive portals presence on the
network.
P: A very common use case is a mobile device sending probes to detect
the Internet connectivity and/or the presence of a captive portal on
the network.

O: The router ND cache, however, might contain an entry for the device
link-local address (if the device has been performing the address
resolution for the router LLA) but there are no entries for the device
GUA.
P: The router ND cache, however, might contain an entry for the device
link-local address (if the device has been performing the address
resolution for the router LLA), but there are no entries for the
device GUA.

O: 4.  If the host sends multiple probes in parallel it would consider
all but one of them failed.
P: 4.  If the host sends multiple probes in parallel,  it would
consider all but one of them failed.

O: This scenario illustrates the problem happening when the device
   connects to the network for the first time or after a timeout long
   enough for the device address to be removed from the router's
   neighbor cache.  However the same sequence of events happen
   when the host starts using a new GUA ...
P: This scenario illustrates the problem occurring when the device
   connects to the network for the first time or after a timeout long
   enough for the device address to be removed from the router's
   neighbor cache.  However, the same sequence of events happen
   when the host starts using a new GUA ...

O: experience and contributing to negative perception of IPv6-only
P: experience and contributing to A negative perception of IPv6-only

O: This document discusses operational implications of
P: This document discusses the operational implications of

O:  RA: outer Advertisement, [RFC4861].
P:  RA: Router Advertisement, [RFC4861].

O: It would be highly desirable to improve the Neighbor Discovery
   mechanics so routers have a usable cache entry for a host address by
   the time the first packet for that address is received by the router.

P: It would be highly desirable to improve the Neighbor Discovery
   mechanics so routers have a usable cache entry for a host address by
   the time the router receives the first packet for that address.

O: o  In topologies with multiple first hop routers the cache
P: o  In topologies with multiple first-hop routers the cache

O: MUST be compatible with the recomendations provided
P: MUST be compatible with the recommendations provided
C: typo in recommendations

O: In summary the following changes to [RFC4861] are suggested:
P: In summary, the following changes to [RFC4861] are suggested:

O: Administrators could enable creating neighbor discovery cache entries based
P: Administrators could enable the creation of neighbor discovery
cache entries based

O: if FCFS SAVI is implemeneted on the network infrastructure.
P: if FCFS SAVI is implemented on the network infrastructure.

O: In some cases unsolicited NAs might not even reach the routers.
P: In some cases, unsolicited NAs might not even reach the routers.

O: However this approach can not be used if the GUA
P: However, this approach can not be used if the GUA

O: state: the section 2.2 of [RFC4429] explicitly
P: state: section 2.2 of [RFC4429] explicitly

O: If no entry exists the router
P: If no entry exists, the router

O: However this approach
P: However, this approach

O: In that case the host SHOULD ...
P: In that case, the host SHOULD ...

O: When a router receives a transit packet it might check the presence
P: When a router receives a transit packet, it might check the presence

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Jen Linkova <[email-masked]>
Date: Fri, 21 Aug 2020 10:36:38 +1000

Hi Warren,

Thanks for your review - sorry for not fixing typos prior to sending
the document your way, the lesson learned.
I've just submitted -04 to address your comments. One more change was
made: the text in Section 2.2 which describes the overview of the
proposed changes to RFC4862 was updated to reflect what the GRAND
draft is currently saying. Basically, the proposed changes are applied
not to hosts but to nodes and not just to GUA but to all addresses.
The diff fragment:

264c265
<        Hosts SHOULD send at least one unsolicited NA packet with the
Override flag cleared to all-routers multicast address (ff02::2) as
soon as one of the following events happens:
---
>        A node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NA packet with the Override flag cleared to all-routers multicast address (ff02::2) as soon as one of the following events happens:
267c268
<                                                     (if Optimistic
DAD is used): a new Optimistic GUA is assigned to the host interface.
---
>                                                     (if Optimistic DAD is used): a new Optimistic address is assigned to the node interface.
270c271
<                                                     (if Optimistic
DAD is not used): a GUA changes the state from tentative to preferred.
---
>                                                     (if Optimistic DAD is not used): an address changes the state from tentative to preferred.

On Fri, Aug 21, 2020 at 8:14 AM Warren Kumari <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry

---

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Aug 2020 14:48:51 -0400

> the document your way, the lesson learned.

No worries, typos have an amazing ability to evade spell-checkers; I
once managed to get "DNS revolvers" through AUTH48 - it was only when
making a last minute change to the acknowledgements section that
someone noticed it... and it still makes me sad that we did...

IETF LC has been requested; thank you for so quickly addressing the comments...
W