+1 On Tue, Nov 22, 2016 at 11:00 AM, Lijo Thomas <[email protected]> wrote:
> +1 > > > > The clear command will be useful at implementation point of view. > > > > > > *Thanks & Regards,* > > *Lijo Thomas * > > > > > > *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Thomas > Watteyne > *Sent:* 22 November 2016 12:47 > *To:* [email protected] > *Subject:* [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request > to old parents > > > > 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 *MailScanner has detected a possible fraud attempt from > "tools.ietf..org" claiming to be* https://tools.ietf.org/html/ > draft-ietf-6tisch-6top-sf0-02#section-10 > <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 > > _______________________________________ > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
