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

[Fernando Gont <[e-mail]>]

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492