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

From: Thomas Watteyne <[email-masked]>
Date: Tue, 22 Nov 2016 08:16:34 +0100

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
_______________________________________

---

From: "Lijo Thomas" <[email-masked]>
Date: Tue, 22 Nov 2016 15:30:29 +0530

+1 

The clear command will be useful at implementation point of view.

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 22 November 2016 12:47
To: [email-masked]
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 

step 1. Change 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:

step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by possibly adding a 4.3.X section:

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

Co-chair, IETF 6TiSCH

 <http://www.thomaswatteyne.com> 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.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 22 Nov 2016 11:05:55 +0100

+1

On Tue, Nov 22, 2016 at 11:00 AM, Lijo Thomas <[email-masked]> wrote:

> *Thanks & Regards,*
> *Lijo Thomas *
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 22 November 2016 12:47
> *To:* [email-masked]
> *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
>
>
>
> 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:
>
>
>
> ------------------------------------------------------------
> -------------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------------------------
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 22 Nov 2016 19:50:52 +0100

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:
> step 1. Change https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10 to:
>
> www.thomaswatteyne.com <http://www.thomaswatteyne.com>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 22 Nov 2016 15:59:44 -0300

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

2016-11-22 15:50 GMT-03:00 Yasuyuki Tanaka <[email-masked]>:

>> 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
>>
>> step 1. Change https://tools.ietf.org/html/dr
>> aft-ietf-6tisch-6top-sf0-02#section-10 to:
>>

-- 
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

---

From: Qin Wang <[email-masked]>
Date: Wed, 23 Nov 2016 21:11:27 +0000 (UTC)

+1
Qin 

    On Tuesday, November 22, 2016 2:17 AM, Thomas Watteyne <[email-masked]> wrote:

   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, PhDResearch Scientist & Innovator, InriaSr Networking Design Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
www.thomaswatteyne.com_______________________________________
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Nov 2016 06:30:28 +0000

+1 much needed

Regards,

Pascal

Le 23 nov. 2016 ? 22:11, Qin Wang <[email-masked]<mailto:[email-masked]>> a ?crit :

+1

Qin

On Tuesday, November 22, 2016 2:17 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com/>
_______________________________________

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 25 Nov 2016 12:18:54 +0530

+1

Just one comment. Since CLEAR may be  useful to several SFs which may be 
active, in future,
perhaps a generic or a wildcard CLEAR message that can address 
potentially multiple SF
listeners can help in avoiding separate messages going from individual SFs.

Anand

On Tuesday 22 November 2016 12:46 PM, Thomas Watteyne wrote:
> 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 > _______________________________________ > > 
-- > This message has been scanned for viruses and > dangerous content 
by MailScanner, and is > believed to be clean. > > 
_______________________________________________ > 6tisch mailing list > 
[email-masked] > https://www.ietf.org/mailman/listinfo/6tisch