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

[Erik Kline <[e-mail]>]

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

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.

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.

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

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 */