In thread "Node Behavior at Boot in SF0" ( https://www.ietf.org/mail-archive/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/draft-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 _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
