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

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 22:17:57 -0300

Hi, Erik,

This one remained unresponded. Apologies for that.

On 22/10/20 11:28, Erik Kline wrote:
> I agree.  I just think then the text about "the lesser of two lifetime
> values" doesn't quite read correctly nor give the impression that this
> applies to things like ULA prefixes.  I think it's probably pretty
> easy to fix with minimal text.

What you say does indeed make sense.

How about this:

After this para in Section 3.1:
    CE Routers providing stateful address configuration via DHCPv6 SHOULD
    set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
    the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
    valid-lifetime of the same option to the lesser of the remaining
    valid lifetime and ND_VALID_LIMIT.

Add (as a parenthetical note?) the following text:

    If the prefix employed for DHCPv6 stateful address configuration
    has been locally-generated (e.g., a locally-generated ULA prefix)
    or manually-configured on the CE router,
    the preferred-lifetime and the valid-lifetime of the
    corresponding DHCPv6 IA Address Option SHOULD be set to
    ND_PREFERRED_LIMIT, and ND_VALID_LIMIT, respectively.

Then, right after this para:
    CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
    IA Prefix Option preferred-lifetime to the lesser of the remaining
    preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of
    the same option to the lesser of the remaining valid lifetime and
    ND_VALID_LIMIT.

Add this text (parenthetical note or main text?):
    If the prefix employed for DHCPv6-PD
    has been locally-generated  (e.g., a locally-generated ULA prefix)
    or manually-configured on the CE router,
    the preferred-lifetime and the valid-lifetime of the
    corresponding DHCPv6 IA Address Option SHOULD be set to
    ND_PREFERRED_LIMIT, and ND_VALID_LIMIT, respectively.

?

Since this resulting value is then used throughout Section 3.2, I wonder if:

* We can assume that it is clear what we mean by e.g. "lesser of
    the remaining preferred lifetime", or,

* Whether we should coin some term for the values resulting from Section 
3.1 (e.g. "effective preferred-lifetime" and "effective valid-lifetime", 
or something like ND_PREFERRED, and ND_VALID), and then use that 
throught Section 3.2.

Thoughts?

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 23:10:09 -0300

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

?

I wonder if we should s/delegated prefix/prefix employed for automatic 
address configuration/ . i.e., you don't want e.g. a default pio valid 
lifetime of 1 month, even if you have e.g. configured the prefix 
manually. Otherwise, if the CPE crashes and is replaced with a different 
box, the associated information will lying around forever.

>    For example, none of these comparative lifetime recommendations apply to
>    a stable ULA for a router that meets requirements ULA-[1..5] and chooses
>    to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.
> 
>    That being said, should this document also be saying that the ULA-derived
>    options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
>    causes a new ULA to be generated (i.e. the one supposedly in stable storage
>    is lost or otherwise unrecoverable)?

Indeed. FWIW, I've moved the discussion of this topic to a separate 
email (which I posted in the subthread where you discssed this with Ted).

> 
> [ section 3.1 ]
 >
> * With respect to the second bullet: the lifetimes need to be dynamically
>    *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
>    values are always lower than the remaining PD lifetimes.  In this situation,
>    the requirement is still that the lifetimes can be updated, but to the
>    casual observer of the steady state the RA contents might appear static
>    (e.g., while the PD'd prefix is continuously renewed).
> 
>    Maybe there's no text required here, but I didn't want a reader to be left
>    with the impression that no two RAs could be identical

How about adding, at the end of the bullet:

In scenarios where the  valid-lifetime and the preferred-lifetime of the 
prefix leased via DHCPv6 on the WAN-side are always lower than 
ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values 
advertised on the LAN-side will see no changes during the lifetime of 
said prefix.

....or the like?

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

> it might be good to clarify that "the *deprecated* prefix can
>    simply be advertised..."

Done.

Thanks!

Regards,