Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04

[Fernando Gont <[e-mail]>]

Hello, Ted,

On 20/10/20 19:23, Ted Lemon wrote:
> On Oct 20, 2020, at 3:51 PM, Fernando Gont <[e-mail] 
> <mailto:[e-mail]>> wrote:
>>> This is relevant because some IoT deployments make use of sleepy 
>>> devices that may only wake up once per day or even less frequently. 
>>> The suggested parameters would be inappropriate for such a device.
>>
>> Just me double-checking: Do you mean it would be to short for them?
>>
>> Please note that the default router lifetime is 1800 seconds. So a host
>> that sleeps for longer than that will presumably not have a default 
>> router when it wakes up, and would need to do a "refresh" procedure 
>> (RS/RA exchange) before it would be able to send a packet, anyway.
> 
> Right, in a situation like this, where the network is pretty stable, it 
> would make sense to use longer lifetimes. Also bear in mind that the 
> communication on this network might be between two hosts on the same 
> link—one a data collector and one a reporting device. So the router 
> lifetime might not be an issue. If the communication is going 
> off-network, a longer router lifetime would be required.

(food for thought) It would seem to me that from a robustness principle, 
the nodes should be able to deal with this type of scenarios gracefully. 
That said, if you're communicating on the local link, you'd employ 
link-locals (and hence don't care about the RAs and associated 
parameters). And if you do mean to communicate off-link, thenthe first 
concern would be the Router Lifetime, rather than the prefix lifetimes.



>>> At the same time such a device likely is not relying on RA, since it
>>> would not be awake for periodic refreshes. Nevertheless the 
>>> operational mitigations section could use some additional verbiage 
>>> about applicability so that readers do not assume that the advice 
>>> given there is universally applicable.
>>
>> Please clarify the above, and based on that, we could craft some text if
>> necessary.
> 
> What I’m suggesting is simply that you mention that the defaults you are 
> recommending are really most applicable in home networks, and may not be 
> applicable in various commercial networks, including the IoT deployment 
> I used as an example.  IOW, make it clear that these defaults are not 
> universally applicable. There’s no text right now that says that (unless 
> I missed it).

I'd argue that they are applicable to most general cases, not just home 
networks. e.g., I know of several enterprise deployments that employ 
"shorter than RFC4861" RAs. e.g., radvd employs 4 hours/1 day for the 
PL/VL.  An operator may always manually override these values, anyway.

In any case, how about adding this to the "Notes" in Section 3.2:

--- cut here ----
The aforementioned values for AdvPreferredLifetime and AdvValidLifetime 
are expected to be appropriate for most general network scenarios. 
However, operators should analyze what specific values for these 
configuration variables would better suit their specific network scenarios.
---- cut here ----

...or the like?

Thanks!

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