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 <diego.dujovne@mail.udp.cl>
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 presentation.
> Regards,
>
>                                 Diego
>
> 2016-11-16 12:06 GMT-03:00 Thomas Watteyne <thomas.watteyne@inria.fr>:
>
> 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 <
> diego.dujovne@mail.udp.cl> wrote:
>
> Yasuyuki, Thomas,
>                              I suggest to keep the CLEAR command
> after reboot/failure.
> Regards,
>
>                                        Diego
>
> 2016-11-16 11:05 GMT-03:00 Thomas Watteyne <thomas.watteyne@inria.fr>:
>
> @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.tanaka@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 or restarting. On the other hand, a
> neighbor of them may have cells allocated for the node. To resolve
> such a possible inconsistency, the node issues CLEAR to each of its
> neighbors.
>
> Best,
> Yatch
>
> On 2016/11/02 15:29, Tengfei Chang wrote:
>
> 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 maximum number of TSCH link-layer retries, as
>    defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#ref-I-D.ietf-6tisch-6top-protocol>]
> TODO/
>    REMARK: The initial timeout is currently under discussion.
>
>
> A little suggestion is DO NOT issue a clear command to previous parent
> until the nodes has reserved new cells to its new parent. This is to avoid
> the swing if the reservation failed to its new parent and changed back to
> previous parent.
>
> What do you think?
>
> Tengfei
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> --
> _______________________________________
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> _______________________________________
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>