Re: [6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka <[e-mail]>]

Thanks, Diego!

I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been defining a separate return
code from RC_ERR_SEQNUM.

> On Apr 24, 2019, at 12:47, Prof. Diego Dujovne <[e-mail]> wrote:
> 
> As far as I can remember, it is important to know that the peer has forgotten all the states and has lost his schedule, so all the allocated cells with that neighbour are currently not valid anymore and should be wiped from the local schedule.

Actually, a node having such a peer should remove outdated cells somehow
without having an explicit signaling.

This is not a job of 6P, though. The SF should take care of it. A peer
may move away from the node without sending a CLEAR request. Even if the
peer sends a CLEAR request before moving somewhere, the CLEAR request may
be lost in the air. 

RPL may do something for this case. If a node has some dedicated TX cells to
its parent, and the parent reboots, RPL on the node could notice there is
something wrong with the parent since measured link quality to the parent
is getting worse. Then, parent switch will be performed.

Or, a SF like MSF would try to relocate badly performed cells. Then, it 
receives RC_ERR_SEQNUM from the parent and take actions to resolve the schedule
inconsistency in the same manner as for other scheduling consistency cases.
The node can see whether the peer loses all the states nor not by having a following
COUNT transaction if the SF really wants to know. If the SF always issues a
CLEAR request to a peer which sent RC_ERR_SEQNUM, the SF doesn't care about
the power-cycle event. Another possibility is that the RELOCATE transaction
ends by 6P Timeout. Again, some actions will be taken by the SF.

Best,
Yatch