Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

Hi, Erik,

I've posted our working copy of the upcoming -07 version at: 
https://raw.githubusercontent.com/fgont/draft-slaac-renum/master/draft-ietf-v6ops-cpe-slaac-renum-07.txt

My comments below refer to further changes on such (upcoming) doc.

In-line...

On 11/2/21 03:17, Erik Kline wrote:
> On Wed, Jan 27, 2021 at 6:10 PM Fernando Gont <[e-mail]> wrote:
>>
>> Hi, Erik,
>>
>> In-line...
>>
>> On 22/10/20 02:37, Erik Kline via Datatracker wrote:
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> [ section 3.2 ]
>>>
>>> * I absolutely agree in principle at these other lifetimes should be updated
>>>     to the shorter of the two applicable lifetimes, but I'm worried that this
>>>     text is not sufficiently precise.  Specifically, this recommendation only
>>>     applies to options that depend in any way on the change in the delegated
>>>     prefix, yes?  Perhaps just this qualifier is sufficient?
>>
>> How about tweaking the first paragraph of Section 3.2 as:
>>
>>     CE Routers SHOULD override the default lifetime values of Neighbor
>> Discovery options that depend in any way on the change delegated prefix,
>> and employ shorter lifetime values to improve the robustness to
>> renumbering events, while complying with the requirements from Section
>> 2.1 of this document and the recommendations in [RFC7772].
>>
>> ?
> 
> Something like this sounds good.  My main concern is that someone
> parachuting into this document looking for MUSTs and SHOULDs that they
> need to implement could miss the discussion in 3(.0) and 3.1 that sets
> the context of referring to lifetimes for options that depend on
> prefixes delegated from upstream (by any mechanism, actually).

I think I now see where you're going. So, how about tweaking L-16 from 
Section 3 as:

    o  L-16: CE routers SHOULD employ capped option lifetimes on the
       LAN-side for any SLAAC or DHCPv6 options that depend on any way
       on changes in the prefixes employed for automatic configuration,
       as specified in Section 3.4 of this document.


Note that the Section 3.4 of the upcoming -07 has already incorporated 
text in this respect.



> Locally assigned/generated prefixes, ULA or otherwise, do not need to
> adhere to these lifetime recommendations, although these are certainly
> quite reasonable default choices.  When I referenced ULA I was really
> meaning any locally generated/assigned prefix/option; the issue is
> about delegated vs locally-originated prefixes/options.

The text now has that qualifier.

Note: the crafted text I suggested above says "...depend on a change in 
the prefix employed for automatic configuration". This kind of makes it 
irrelevant on how you got the prefix or generated it --- if changing the 
prefix employed for automatic configuration, this would still apply.

Note that e.g. a CE Router with multiple lan-side networks that do not 
consistently locally-generate the same prefix for the same subnet (or 
that does not consistently DHCPv6-pD leases the same prefixes 
downstream) would also benefit from this.



> I certainly agree that the lifetime recommendations make some
> universal sense, but I think MUSTs can only be applied to delegated
> prefix/option information whereas all other cases only SHOULD really
> applies.

But we seem to be okay in that respect:
L-15 takes care of the option lifetimes not spanning past the remaining 
lifetimes from the upstream. (with a MUST)

L-16 talks about overriding the default lifetimes (with a SHOULD).


The only possible confusion would seem that L-16 talks about "remaining 
lifetime", which comes from L-15.  THat's why I was wondering if one 
might want to add a note that, when working with delegated prefixes, 
"remaining lifetime" means what you compute in L-15, whereas in other 
cases it simply means "whatever is the locally configured lifetime"



>>> [[ nits ]]
>>>
>>> [ section 3.3 ]
>>>
>>> * In the 2nd bullet's 2nd bullet (this might be easier if these lists were
>>>     numbered),
>>
>> Change both lists (innet an outter) to numbered lists?
> 
> Whatever you like.  My observation is that if it's something you think
> that an implementer will need to refer to, perhaps in documentation/a
> code comment/a commit message, then numbered/lettered lists are more
> useful for that purpose.
> 
>      // Blarg the foobar so we can quux it later if we have to,
>      // per RFC XYZ section A.B.C, item 1.2 (b).
>      state_machine.blarg(foobar);  /* Fixes: #17 */

That's a good point. I believe the "RATONALE" bits can be left "as is", 
since they are mostly informational (you only need to go through it if 
you want to understand the motivation).  For Section 3.5, we should 
probably at least make it such that we have only one level of bullets.

(regarding numbered vs un-numbered, the reason why we used unnumbered 
bullets is that they don't convey "order" -- e.g., some of the bullets 
are essentially IF-THEN-ELSE clauses)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492