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

2016-11-24 Thread S.V.R.Anand 

+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 > 
6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

2016-11-23 Thread Pascal Thubert (pthubert) 
+1 much needed


Regards,

Pascal

Le 23 nov. 2016 ? 22:11, Qin Wang 
> a ?crit :

+1

Qin


On Tuesday, November 22, 2016 2:17 AM, 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
___

___
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
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

2016-11-23 Thread Qin Wang 
+1
Qin 

On Tuesday, November 22, 2016 2:17 AM, 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, PhDResearch Scientist & Innovator, InriaSr Networking Design 
Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
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

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

2016-11-22 Thread Prof. Diego Dujovne 
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 :

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

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

2016-11-22 Thread Yasuyuki Tanaka 

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



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

2016-11-22 Thread Lijo Thomas 
+1 

 

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

 

 

Thanks & Regards,

Lijo Thomas 

 

 

From: 6tisch [mailto:6tisch-boun...@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 
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