Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

[Erik Kline <[e-mail]>]

A question comes to mind: what might the operational guidance be for
setting the refresh timer value in the RA?

Observation: it almost certainly shouldn't be /longer/ than the router
lifetime, even if the prefix lifetimes are infinite.

Reasonable stab in the dark: refresh timer value in the RA should be
in the neighborhood of some fraction (1/2, 2/3) * min(router lifetime,
prefix lifetimes...).

If that turns out to be the case, then the host can compute this timer
value for itself, sleep on its own schedule, and wake up whenever it
wants and send a unicast RS.  At that point this isn't a protocol
change but rather an operational document.  [1]

At the very least, this is a simple enough experiment to perform for
people writing the code on the affected devices (doesn't require
router vendor code changes).  Has anybody done this and measured the
outcome?

-Erik the Lesser


[1]  Note that the node MUST to be ready to basically re-attach from
scratch in the event that the router has gone (I swapped my IoT device
access point for a new model, and it got a new prefix too, while
everyone listening was asleep, for example).  So guessing a wrong
timer value must be non-fatal for the node.  At worst it won't be
"optimal" but i'm curious to know what the impact of deviation from
"optimal" would really be in these networks, given that nodes are all
going to go for the longest possible timer value.