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

From: Ted Lemon via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 09:21:07 -0700

Reviewer: Ted Lemon
Review result: Ready with Nits

This draft does a good job of discussing typical home use scenarios, where the
problems described in the document are most likely to occur. It might be worth
noting that some of the assumptions about prefix stability may not be
applicable to commercial IoT deployments. 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. 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.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 16:51:39 -0300

Hello, Ted,

Thanks a lot for your comments (past and present ;-) )! In-line....

On 19/10/20 13:21, Ted Lemon via Datatracker wrote:
> Reviewer: Ted Lemon Review result: Ready with Nits
> 
> This draft does a good job of discussing typical home use scenarios, 
> where the problems described in the document are most likely to 
> occur. It might be worth noting that some of the assumptions about 
> prefix stability may not be applicable to commercial IoT
> deployments.

Could you please elaborate a bit more?

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

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

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 16:51:39 -0300

Hello, Ted,

Thanks!

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Oct 2020 18:23:21 -0400

On Oct 20, 2020, at 3:51 PM, Fernando Gont <[email-masked]> 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.
> 
> 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.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Oct 2020 18:23:21 -0400

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 20:24:55 -0300

Hello, Ted,

On 20/10/20 19:23, Ted Lemon wrote:
> On Oct 20, 2020, at 3:51 PM, Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 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.

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 20:24:55 -0300

Hello, Ted,

---- cut here ----

...or the like?

Thanks!

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Oct 2020 22:48:47 -0400

On Oct 20, 2020, at 7:24 PM, Fernando Gont <[email-masked]> wrote:
> 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.

That seems pretty vague. It would be better to say something like:

The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are expected to be an appropriate default for most networks. In some networks, particularly where the operator has complete control of prefix allocation and where hosts on the network may spend long periods sleeping (e.g., sensors with limited battery), longer default values may be appropriate.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Oct 2020 22:48:47 -0400

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 00:03:11 -0300

On 20/10/20 23:48, Ted Lemon wrote:
> On Oct 20, 2020, at 7:24 PM, Fernando Gont <[email-masked] 
>> 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.
> 
> are expected to be an appropriate default for most networks. In some 
> networks, particularly where the operator has complete control of prefix 
> allocation and where hosts on the network may spend long periods 
> sleeping (e.g., sensors with limited battery), longer default values may 
> be appropriate.

Thanks a lot for the suggested text!

Unless folks argue otherwise, I will incorporate it into the next rev.

Thanks again!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 00:03:11 -0300

Thanks again!

Regards,