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 <yasuyuki9.tan...@toshiba.co.jp>: > 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 >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > _______________________________________________ > 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
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch