On 10/9/20 07:13, Juergen Schoenwaelder wrote:
On Thu, Sep 10, 2020 at 06:00:02AM -0300, Fernando Gont wrote:
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:
[....]
Perhaps indicate a bit earlier what unacceptably long means, i.e. we
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.
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.
Oh, I see. Will do! (and thanks for the clarification ;-) )
(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.)
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.".
Thanks.
Great. Will add this in the next rev.
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.
Normally, you renew the lease before the lease expires.
But also this is triggered by a timer, no?
Yep
IP address
mappings to Ethernet addresses expire when their lifetime timer goes
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).
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.
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,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
