Subject: [Last-Call] Opsdir last call review of draft-ietf-v6ops-slaac-renum-03

From: Jürgen Schönwälder via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 15:05:01 -0700

Reviewer: Jürgen Schönwälder
Review result: Has Issues

I have reviewed draft-ietf-v6ops-slaac-renum-03 as part of the ops-dir
review efforts. The document addresses a problem that is of certain
operational relevance. This document is labeled as informational.

Perhaps indicate a bit earlier what unacceptably long means, i.e. we
are talking about days and weeks. The scenarios described read a bit
like somewhat rare events and hence it is useful for the reader to
have an idea what unacceptably long means in such events. (BTW, I find
the scenario not described at the beginning where a router announces
SLAAC lifetimes that are not synchronized with obtained prefix
lifetimes operationally the more tricky problem since this can lead to
regular failures.)

Section 2.2 seems to confuse soft-state (this is what a learned IPv6
prefix is for me) with certain protocol timers. There are many places
where protocols use soft-state and implementations use timers to purge
or refresh soft-state. That timers generally do not go off in normal
conditions is not really correct in this context, DHCP leases are
renewed when their lifetime expires, a normal operation. IP address
mappings to Ethernet addresses expire when their lifetime timer goes
off. Switches purge forwarding state regularly when forwarding entries
expire. Cached DNS name to IP resolutions expire. The only problem
here seems to be that a lifetime of 7 days / 30 days is a bit
ridiculous. Is anyone shipping the RFC 4861 defaults? The few
implementations I have seen do use a bit more reasonable defaults.  I
think this section should be rewritten to replace the "timer going off
is associated with a failure" text with a discussion of	soft-state in
other protocols. (Section 2.2 is why I ticked 'has issues'.)

Isn't a part of the solution (other than moving to less ridiculous
default) that SLAAC hosts experiencing connectivity problems should
try to validate the prefix that they have learned (and if the
validation fails move to a newly learned prefix)? Involving the hosts
in a resolution of the problem may be	more robust than expecting that
something in the network takes care of invalidating stale soft-state.
Well, this comment is likely outside the scope of this problem
statement document.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 06:00:02 -0300

Hi, Jürgen,

Thanks a lot for your comments! In-line....

On 9/9/20 19:05, Jürgen Schönwälder via Datatracker wrote:
[....]
> are talking about days and weeks.

This is a bit subjective. If I'm sitting on my computer doing e.g. 
video-conferencing (i.e., anything interactive), probably anything over 
a few minutes would be unacceptable. In a more general case, what's 
acceptable is a function of how often the problem happens and whether 
there's any ongoing interactive usage -- and that's still subjective.

> The scenarios described read a bit
> have an idea what unacceptably long means in such events.

I wondering if adding something like:
" Any definition of what is considered 'acceptable' here would be 
subjective, and would probably also depend on how often these 
flash-renumbering events occur, whether the affected hosts are employing 
any interactive applications, and other parameters. However, one rough 
estimate would be that hosts should be able to deal with 
flash-renumbering events with a similar timeliness with which they can 
deal with failing default routers."

would help?

> (BTW, I find

Fair enough. How about adding this to the bulleted-list:

" o A router (e.g. Customer Edge router) may advertise autoconfiguration 
prefixes corresponding to prefixes learned via DHCPv6-PD with constant 
PIO lifetimes that are not synchronized with the DHCPv6-PD lease time 
(as required in Section 6.3 of [RFC8415]). While this behavior violates 
the aforementioned requirement from [RFC8415], it is not an unusual 
behavior, particularly when e.g. DHCPv6-PD is implemented in a different 
software module than the SLAAC router component.".

?

> renewed when their lifetime expires, a normal operation. 

Normally, you renew the lease before the lease expires.

> IP address
> off. 

This one is not the necessarily the best example ;-) (while RFC1122 
requires that, IIRC in many implementations the entry is refreshed when 
referenced, and it only expires when not referenced/refreshed frequently 
enough).

But I do see where you are going and I realize that the text is a bit 
sloppy in this respect. How about tweaking the text as follows:

---- cut here ----
    Many protocols, from different layers, normally employ timers for 
fault isolation/recovery.  The
    general logic is as follows:

    o  A timer is set with a value such that, under normal conditions,
       the timer does *not* go off.

    o  Whenever a fault condition arises, the timer goes off, and the
       protocol can perform fault recovery

    For example, when implementing reliability mechanisms, a timer is 
normally set when a packet is transmitted and, unless a response is 
received before the timer goes off, a fault recovery action (such as 
packet re-transmission) is triggered.
---- cut here ----

?

One might also look at this same issue as the timer implying a sensible 
period of time where information should be refreshed, as you correctly 
point out, though.

(I guess the only difference is that when looking at this form the 
soft-state angle, you're mostly considering the case where information 
changes, whereas when looking at this from the fault-recovery pov, 
you're mostly thinking about failures, rather than updates).

> Switches purge forwarding state regularly when forwarding entries
> ridiculous.

Agreed.

> Is anyone shipping the RFC 4861 defaults? 

Yes, unfortunately. Some implementations override the RFC4861 defaults. 
Still, RFC4861 defaults are extremely common and widespread.

> The few

As a second alternative to what I've suggested above:

---- cut here ----
    Many protocols, from different layers, normally employ timers for a
    variety of purposes, such as in fault isolation/recovery mechanisms,
    and in the maintenance of data structures that contain bindings of
    some sort (e.g., the IPv6 Neighbor Cache [RFC4861]).

    In the case of fault recovery/isolation, the general logic is as
    follows:

    o  A timer is set with a value such that, under normal conditions,
       the timer does *not* go off.

    o  Whenever a fault condition arises, the timer goes off, and the
       protocol can perform fault recovery

     For example, when implementing reliability mechanisms, a timer is
     normally set when a packet is transmitted and, unless a response is
     received before the timer goes off, a fault recovery action (such as
     packet re-transmission) is triggered.

     On the other hand, when maintaining bindings in data structures, 
timers are usually selected in a way that any bindings that become stale 
are updated in a timely manner.
---- cut here ----

?

> validation fails move to a newly learned prefix)?

Yes, indeed. That's what we are pursuing in draft-ietf-6man-slaac-renum. 
(see Section 4 of this (draft-ietf-v6ops-slaac-renum-03) document).

draft-ietf-v6ops-slaac-renum-03 contains the problem statement and 
*operational* mitigations only.

> Involving the hosts

I agree 100%. That is and has been, indeed, the motivation for pursuing 
draft-ietf-6man-slaac-renum.

Thanks!

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Sep 2020 12:13:20 +0200

On Thu, Sep 10, 2020 at 06:00:02AM -0300, Fernando Gont wrote:
> video-conferencing (i.e., anything interactive), probably anything over a
> few minutes would be unacceptable. In a more general case, what's acceptable
> is a function of how often the problem happens and whether there's any
> ongoing interactive usage -- and that's still subjective.

My point was that at the beginning there is just 'unacceptably long'
and I had not clue whether I should think in terms of seconds,
minutes, hours, days, weeks. It is only later that I am getting told
we talk about days. Writing earlier something like "unacceptably long
(up to multiple days)" would have helped me to appreciate the problem.
 
> flash-renumbering events occur, whether the affected hosts are employing any
> interactive applications, and other parameters. However, one rough estimate
> would be that hosts should be able to deal with flash-renumbering events
> with a similar timeliness with which they can deal with failing default
> routers."
> 
> would help?

Does not hurt. I think my main issue was that I had no clue about the
dimension of 'unacceptably long', which can be fixed easily by making
it clear we are not talking about minutes.

> prefixes corresponding to prefixes learned via DHCPv6-PD with constant PIO
> lifetimes that are not synchronized with the DHCPv6-PD lease time (as
> required in Section 6.3 of [RFC8415]). While this behavior violates the
> aforementioned requirement from [RFC8415], it is not an unusual behavior,
> particularly when e.g. DHCPv6-PD is implemented in a different software
> module than the SLAAC router component.".
> 

Thanks.
 
> Normally, you renew the lease before the lease expires.

But also this is triggered by a timer, no?
 
> This one is not the necessarily the best example ;-) (while RFC1122 requires
> that, IIRC in many implementations the entry is refreshed when referenced,
> and it only expires when not referenced/refreshed frequently enough).
> 
> But I do see where you are going and I realize that the text is a bit sloppy
> in this respect. How about tweaking the text as follows:
> 
> ---- cut here ----
>    Many protocols, from different layers, normally employ timers for fault
> isolation/recovery.  The
> normally set when a packet is transmitted and, unless a response is received
> before the timer goes off, a fault recovery action (such as packet
> re-transmission) is triggered.
> ---- cut here ----
> 
> ?
> 
> period of time where information should be refreshed, as you correctly point
> out, though.
> 
> changes, whereas when looking at this from the fault-recovery pov, you're
> mostly thinking about failures, rather than updates).

I would probably simply remove text that talks about the general use
of timers. It is not needed to understand the problem, I think it
actually confuses the problem. For me, the prefix is soft-state that a
box learned (like it learns a lot of other soft-state) and so you
either go for 'reasonably short' lifetimes or you design mechanisms to
detect and handle stale information gracefully.
 
>     On the other hand, when maintaining bindings in data structures, timers
> are usually selected in a way that any bindings that become stale are
> updated in a timely manner.
> ---- cut here ----
>

As said above, I do not think a generic discussion of timers is needed
to make the point this document is trying to make, namely (i) the
suggested default lifetimes are ridiculous long and (ii) there should
be robust ways to recover quickly from situations where a prefix
becomes unusable within its lifetime.

In fact, if one would go and remove redundancy in the document, it
could be way shorter, but that may be a stylistic issue. ;-)

> draft-ietf-6man-slaac-renum.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Sep 2020 07:33:09 -0300

> (up to multiple days)" would have helped me to appreciate the problem.

Oh, I see. Will do! (and thanks for the clarification ;-) )

>> module than the SLAAC router component.".

Great. Will add this in the next rev.

> But also this is triggered by a timer, no?

Yep

> detect and handle stale information gracefully.

Fair enough. So, removing beginning of the section up to, and including 
the sentence that says "For obvious reasons, the whole ...", then?

Thanks again!

Regards,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Sep 2020 13:10:04 +0200

On Thu, Sep 10, 2020 at 07:33:09AM -0300, Fernando Gont wrote:

[...]
 
> Fair enough. So, removing beginning of the section up to, and including the
> sentence that says "For obvious reasons, the whole ...", then?

Yes.

/js