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

From: Erik Kline <[email-masked]>
Date: Wed, 10 Feb 2021 22:17:15 -0800

On Wed, Jan 27, 2021 at 6:10 PM Fernando Gont <[email-masked]> 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 */

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 15:31:58 -0300

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

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

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

> prefix/option information whereas all other cases only SHOULD really

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"

>      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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492