Subject: Re: [v6ops] Working Group Last Call draft-ietf-v6ops-nd-cache-init

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Jun 2020 22:21:33 +1000

On Sun, May 31, 2020 at 7:05 PM Fernando Gont <[email-masked]> wrote:
> I support publication of this document. Bellow you'll find my review:

Thanks for your review and comments Fernando!
I've just submitted -02 which shall address your comments.

> ** Technical: **
>
> * Section 2.2
>
> You might want to note how the "override" flag in the NA is set, and the
> state in which the NCE should be created.

Done.

> * Section 3.3
>
> Might want to clarify which destination address to use?

Done.

> * Section 3.4:
> >
> >    o  If the address is in the Optimistic state the RS can not contain
> >       SLLAO.  As a result the router would only create a cache entry if
> >       the solicited RAs is sent as as a unicast.  Routers sending
> >       solicited RAs as multicast would not create a new cache entry as
> >       they do not need to send a unicast packet back to the host.
>
> Of the top of my head, I'm not sure if an RA sent to a multicast address
> can be a "solicited RA" (as in "having the 'solicited' flag set). Please
> double-check.

There is no such thing as a 'solicited' flag in RA. By 'solicited' RA
this section means 'an RA sent in response to an RS'.
Such RA can indeed be sent either as a multicast (most routers were
doing it by default initially, hence RFC7772) or as unicast.

> ** Editorial: **

Done.

> * Section 1.2:
>
> Not sure if this section is needed. Just introduce the acronyms the
> first time you use each term, and that's it.

I prefer to keep it as that way I do not need to track where exactly I
mention the acronym for the first time..

> * Section 3:
>
> Thinking out loud: One might move this section (and subsections) to an
> Appendix?

IMHO, as some of those options are implemented by some vendors, so I
believe it makes sense to discuss them.

> On 25/5/20 12:51, Ron Bonica wrote:
> > Folks,
> >
> > This message initiates a WG Last Call on
> > draft-ietf-v6ops-nd-cache-init.
> >
> > Please submit comments by June 8, 2020.
> >
> >
> > Fred and Ron
> >
> >
> > Juniper Business Use Only
> >
> > _______________________________________________ v6ops mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> >
>
>
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Jun 2020 22:21:51 +1000

Hi Mikael,

Thanks for your review, I've just submitted -02 with your comments addressed.
See below.

On Tue, May 26, 2020 at 2:52 AM Mikael Abrahamsson
<swmike=[email-masked]> wrote:
> 3.4
>
> "o  Some wireless devices are known to fiddle with ND packets and
>        perform various non-obvious forms of ND proxy actions.  In some
>        cases RSes might not even reach the routers."
>
> "fiddle" might not be a great term to use here, as it seems to have
> multiple meanings according to Merriam Webster?

Replaced with 'alter' as per Owen's suggestion.

> Then the security consideration section pointed to draft-ietf-6man-grand
> (or actually it didn't, it pointed to linkova-6man-grand which then
> pointed to draft-ietf-6man-grand), so I ended up reading that one as well.

References updated, thanks!

> These documents seem to belong together. I tried going back in 6man as
> well and couldn't find much discussion on how these two documents are
> supposed to be handled as a pair somehow?

IMHO they shall be published as a cluster. I agree that having two
documents is a bit confusing.
The story is:
- the WG agreed that this document shall belong to v6ops@ as it
contains the operational problem statement.
- the solution doc belongs to 6man as it modifies RFC4861.

I have no issues merging both of them into 6man doc but my impression
is the working group suggested to keep the operational doc separate.
Fred, Ron - is my recollection correct?

>If this nd-cache-init is an
> operational document referencing 6man-grand and talking about this from an
> operational POV, then perhaps this should be stated in the introduction?

I've added a sentence to the Introduction section.

> Commenting on both of them, I'd like to see some kind of text indicating
> that SAVI (RFC7039) RFCs had been taken into account and if anything
> specified in there might cause problems with the proposed approach in
> nd-cache-init and -grand.

Good point. I remember you did mention it before, sorry for not addressing it.
I've added a sentence to section 2.2 and will add more details to the
6man document, as it's a better place to discuss interoperability with
SAVI.

> But to sum up, I think the problem space these drafts are tackling is
> worth improving, and I support this work progressing.

Thanks!

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Jun 2020 22:23:41 +1000

On Tue, May 26, 2020 at 1:14 PM Owen DeLong <[email-masked]> wrote:
> > "fiddle" might not be a great term to use here, as it seems to have multiple meanings according to Merriam Webster?

> Perhaps instead of “fiddle with” we could use the more technical term “alter”

The text has been fiddl...sorry, altered in -02 ;)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Jun 2020 17:21:49 -0300

Hello, Jen,

Thanks!

> There is no such thing as a 'solicited' flag in RA.

I have no idea what I was thinking when I wrote this :-) -- sleep 
disorder might be a plausible explanation :-))

> believe it makes sense to discuss them.

I would suggest that you note this at the beginning of this section 
(even if it's just a general comment like the one above ("some of these 
options are implemented by some vendors.."). That would signal folks 
that they might expect to see some of this in the wild.  -- Otherwise 
(like myself), they might assume that these are just potential solutions 
that you evaluated and then discarded.

FWIW, if you decide to apply this "change", feel free to schedule it for 
the next rev (i.e., this is not a show stopper, and you don't need a rev 
just for this).

Thanks!

P.S.: Not sure what's the necessary magic for this to happen, but, if 
possible (i.e., assuming that both docs are progressed smoothly and 
timely), I'd suggest that this doc is put in a cluster with the 
companion 6man document, such that both reference each other's RFC 
versions when published.

Cheers,