Hello, Ted,
On 20/10/20 19:23, Ted Lemon wrote:
On Oct 20, 2020, at 3:51 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx
<mailto:fgont@xxxxxxxxxxxxxxx>> 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: 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
