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

[Vasilenko Eduard <[e-mail]>]

Hi Erik,
> 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.
Ed: What if prefix would become invalid because somebody (not properly developed SDN controller or Management system or human in CLI) would abruptly change prefix configuration on the LAN interface?
People are doing mistakes. Protocol resiliency is not a luxury.
Eduard
From: v6ops [mailto:[e-mail]] On Behalf Of Erik Kline
Sent: Wednesday, May 26, 2021 3:16 AM
To: Fernando Gont <[e-mail]>
Cc: V6Ops Chairs <[e-mail]>; v6ops list <[e-mail]>; [e-mail]; The IESG <[e-mail]>
Subject: Re: [v6ops] Erik Kline's Yes on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)



On Wed, Feb 24, 2021 at 11:41 PM Fernando Gont <[e-mail]<mailto:[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.