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

[Warren Kumari <[e-mail]>]

On Thu, Aug 20, 2020 at 8:36 PM Jen Linkova <[e-mail]> wrote:
>
> Hi Warren,
>
> Thanks for your review - sorry for not fixing typos prior to sending
> 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

> 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 <[e-mail]> wrote:
> >
> > 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
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
> SY, Jen Linkova aka Furry



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