I agree witb Yatch: On Step 1, keep the original CLEAR command at
boot time.
Step 2 is OK for me:
In fact, the only way SF0 would detect that the node is
no longer available or that RPL has decided a parent change
is that there will be no more effectively used cells towards
that neighbour, so only the OVERPROVISION number of
cells will be allocated (maybe plus SF0THRESH).
Given this condition, SF0 will generate a CLEAR command,
thus reducing the number of allocated cells to zero.
Regards,
Diego
step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by
possibly adding a 4.3.X section:
4.3.X. Disconnecting from a neighbor
If the SF realizes connection to a particular neighbor is no longer
needed (for example a change in parent by the routing protocol),
the SF MAY send a CLEAR request to that neighbor to speed up the
cleanup process of the cells allocated with that neighbor.
2016-11-22 15:50 GMT-03:00 Yasuyuki Tanaka <[email protected]>:
> Hi all,
>
> Here is my opinion:
>
> step 1: one suggestion to keep the original sentence explaining what
> to do in SF0 after the system booting-up or restart. That is,
> no change on draft-ietf-6tisch-6top-sf0-02#section-10.
>
> step 2: +1
>
> Thanks!
> Yatch
>
>
> On 2016/11/22 8:16, Thomas Watteyne wrote:
>
>> In thread "Node Behavior at Boot in SF0" (https://www.ietf.org/mail-arc
>> hive/web/6tisch/current/msg04883.html), we ended up discussing the
>> following paragraph
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:
>>
>> 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]. TODO/
>> REMARK: The initial timeout is currently under discussion.
>>
>> The suggestion on the table is to:
>>
>> step 1. Change https://tools.ietf.org/html/dr
>> aft-ietf-6tisch-6top-sf0-02#section-10 to:
>>
>> 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]. TODO/
>> REMARK: The initial timeout is currently under discussion.
>>
>> step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by
>> possibly adding a 4.3.X section:
>>
>> 4.3.X. Disconnecting from a neighbor
>>
>> If the SF realizes connection to a particular neighbor is no longer
>> needed (for example a change in parent by the routing protocol),
>> the SF MAY send a CLEAR request to that neighbor to speed up the
>> cleanup process of the cells allocated with that neighbor.
>>
>> I'm hereby opening a call for WG consensus. Please +1 or comment/suggest.
>> The chairs will summarize on Fridat 25 Nov.
>>
>> Thomas
>>
>> --
>> _______________________________________
>>
>> 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 <http://www.thomaswatteyne.com>
>> _______________________________________
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> 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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
