Re: [v6ops] Erik Kline's Yes on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)

[Erik Kline <[e-mail]>]

On Wed, Feb 24, 2021 at 11:41 PM Fernando Gont <[e-mail]>
wrote:

> Hello, Erik,
>
> Thanks a lot for your comments! In-line....
>
> On 25/2/21 03:21, Erik Kline via Datatracker wrote:
> [....]
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > [[ comments ]]
> >
> > [ section 3.4 ]
> >
> > * At the end of the 2nd paragraph and the 2nd NOTES paragraph, I think it
> >    could be made clearer that this recommendation especially applies to
> ND
> >    Options that contain address or prefix information from within a
> prefix
> >    learned on the WAN side.
>
> Are you referring that of "the lifetimes not spanning past the remaining
> lifetime", or to the recommendation to set the PIO lifetimes to
> (ND_VALID_LIMIT, ND_PREFERRED_LIMIT).
>
> If the former, I definitely agree. If the latter, I'd probably argue
> that when it comes to PIOs the advice is also valid even if the prefix
> is locally generated. -- e.g., consider the case where a CE Router is
> simply replaced by another one. If the (VL, PL) was (1 week, 1 month)
> you'd have them around for quite a while (same for e.g. RDNSS options).
> -- that said, I wouldn't mind clarifying that this only applies to
> sub-prefixes of prefixes learned from the WAN-side if you think that's
> warranted.
>

>    These timers seem fine in general as well, but I think as written it's
> >    a blanket recommendation without explicitly saying why these options
> >    need updating, i.e. if someone asks what does "if and where
> applicable"
> >    actually mean -- it means ND options with address/prefix information
> >    taken from a delegated prefix whose lifetime has been reduced
> >    (possibly to zero, possibly progressively shorter values trending to
> zero).
>
> FWIW, what we *meant* with "if and where applicable" was essentially
> "[any future] Neighbor Discovery options that depend in any way on
> changes in the prefix employed for address configuration on the LAN-side"
>
> Just let us know how we should clarify the above.
>

If memory serves, I was thinking about clarifying that only options that
use WAN-side sub-prefix information (routes/CIDR prefixes/addresses) need
timer clarity.

Looking again at -07, it seems like "options that depend in any way on
changes in the prefix employed for address configuration" probably captures
this sentiment adequately.