Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yatch, Agreed. Let's me start a different thread where I summarize your suggestion and ask for WG consensus. Thomas On Mon, Nov 21, 2016 at 5:10 PM, Michael Richardson wrote: > > Yasuyuki Tanaka wrote: > >> Sending an explicit CLEAR

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yasuyuki Tanaka wrote: >> Sending an explicit CLEAR will speed things up, and avoid for the >> previous preferred parent to waste energy listening to those. A CLEAR >> wouldn't hurt, right? > This is right. But, I don't think it's a SF0 job. The

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Hi Thomas, Could we say something to the effect that, if SF0 realizes connection to a particular neighbor is no longer needed (for example a change in parent by the routing protocol) SF0 MAY send CLEAR requests to neighbor to speed up the cleanup process of the cells with that neighbors? I

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yatch, Hmm, good point. I'm with you that have SF0 be independent from higher layer stuff is the right design approach. But SF0 doesn't really offer any API for upper-layers (it would be against its "minimal" nature). Could we say something to the effect that, if SF0 realizes connection to a

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Hi Thomas, Sending an explicit CLEAR will speed things up, and avoid for the previous preferred parent to waste energy listening to those. A CLEAR wouldn't hurt, right? This is right. But, I don't think it's a SF0 job. The thing is that SF0 knows nothing about RPL. If SF0 provided an API to

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Hi Diego and Tengfei, diego> I suggest to keep the CLEAR command after reboot/failure. It's fine for me, too. tengfei> I am thinking another case that a node needs send a CLEAR tengfei> command to previous parent if it changed. I guess this is not tengfei> mentioned in the draft? No, it's not

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

That would be perfect, thanks! On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne wrote: > Thomas, > It is not on my slides, since the default > behavior (issue a CLEAR command) did not > change from -01 to -02. I can raise the issue > during the

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Thomas, It is not on my slides, since the default behavior (issue a CLEAR command) did not change from -01 to -02. I can raise the issue during the presentation. Regards, Diego 2016-11-16 12:06 GMT-03:00 Thomas Watteyne : >

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Diego, Fine for me. Could you bring it up during the WG meeting tomorrow? Thomas On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne wrote: > Yasuyuki, Thomas, > I suggest to keep the CLEAR command > after reboot/failure. > Regards, > >

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yasuyuki, Thomas, I suggest to keep the CLEAR command after reboot/failure. Regards, Diego 2016-11-16 11:05 GMT-03:00 Thomas Watteyne : > @Tengfei, > Does that suggestion work for you or should we

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

@Yatch, I see the point. I have no doubt now about the behaviors after the node boot. I am thinking another case that a node needs send a CLEAR command to previous parent if it changed. I guess this is not mentioned in the draft? @Thomas, maybe we can create an issue for that? Let me know if

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

@Tengfei, Does that suggestion work for you or should we create an issue on SF0? Thomas On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka < yasuyuki9.tan...@toshiba.co.jp> wrote: > Hi Tengfei, > > I think an assumption there is that a node has no state with its > neighbors just after booting up

[6tisch] [6TiSCH] Node Behavior at Boot in SF0

All, For the decision when a node is restarted, the SF0 says: In order to define a known state after the node is restarted, a CLEAR command is issued to each of the neighbor nodes to enable a new allocation process. The 6P Initial Timeout Value provided by SF0 should allow for the