Re: [v6ops] Opsdir last call review of draft-ietf-v6ops-slaac-renum-03

[Fernando Gont <[e-mail]>]

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