Re: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request to old parents

+1

On Tue, Nov 22, 2016 at 11:00 AM, Lijo Thomas <lijo@cdac.in> wrote:

> +1
>
>
>
> The clear command will be useful at implementation point of view.
>
>
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 22 November 2016 12:47
> *To:* 6tisch@ietf.org
> *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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria