Subject: [6tsch] work item 2: centralized route and track computation with PCE

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 10:34:24 +0000

Hello Raghu and all:

About item 2 6TSCH Centralized Management:

Since we wrote the charter a few months ago we have been digging and it appears that we are probably not ready for going standard track right away with a 6TSCH document.
- In one hand, we understand better that the PCE is the component we need for both centralized route AND track computation.
- OTOH, we realized that PCEP only covers a limited portion of the required standard work and we realize that we need to dig deeper in what needs to be done, in particular to locate the PCE(s), export topology and metrics to the PCE, and then install routes and tracks from the PCE.  We also understand that some of that work belongs to the PCE working group though it is unclear exactly how much that is.

Right now the charter has this:

2. Produce "6TSCH centralized management" to define the mechanism by which an
external Path Computation Element can communicate with the 6top protocol layer
of the different nodes in the network (1) to modify their TSCH schedule and
(2) to gather link quality statistics and data flow requirements.  The WG will
initially look at PCEP and CoAP.
Depending on the applicability of PCEP, this document will be targeted to
proposed standard.

In the light of our studies, I'd suggest this:
2. Produce requirements and an overall architecture for  "6TSCH centralized routes and tracks management"
describing the mechanism by which an external Path Computation Element (PCE) can communicate with
devices in a 6TSCH network in order to maintain routing and forwarding states. In detail, the WG will
consider operations (1) by the device routing layer for (i) sending topological information and routing
metrics to the PCE, and (ii) getting on-demand routing information; and (2) by the device 6top sublayer
for exporting neighboring and link quality statistics to the PCE and (2) requesting to (re)compute and
install a track that meets explicit flow requirements.

What do you guys think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: lundi 22 juillet 2013 07:25
To: [email-masked]
Subject: [6tsch] slides for work items

All,
Attached are the slides for the work items. Please provide your comments.

Specifically, please provide feedback on whether we must have the security framework as a work item.

-raghuram

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 23 Jul 2013 03:43:06 -0700

Hi Pascal,

you narrowed the text so it is more focused now, however we have to be very
sure to do not skip any aspect. Besides, at the end of the new text:

Produce requirements and an overall architecture for  "6TSCH centralized
routes and tracks management" describing the mechanism by which an external
Path Computation Element (PCE) can communicate with devices in a 6TSCH
network in order to maintain routing and forwarding states. In detail, the
WG will consider operations (1) by the device routing layer for (i) sending
topological information and routing metrics to the PCE, and (ii) getting
on-demand routing information; and (2) by the device 6top sublayer for
exporting neighboring and link quality statistics to the PCE and (2)
requesting to (re)compute and install a track that meets explicit flow
requirements.

the second (2) confuses me.Is it referring to the previous (2) item?

"PCE and (2) requesting "

X

On Tue, Jul 23, 2013 at 3:34 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Raghu and all:****
>
> ** **
>
> About item 2 6TSCH Centralized Management:****
>
> ** **
>
> Since we wrote the charter a few months ago we have been digging and it
> appears that we are probably not ready for going standard track right away
> with a 6TSCH document.****
>
> - In one hand, we understand better that the PCE is the component we need
> for both centralized route AND track computation.****
>
> - OTOH, we realized that PCEP only covers a limited portion of the
> required standard work and we realize that we need to dig deeper in what
> needs to be done, in particular to locate the PCE(s), export topology and
> metrics to the PCE, and then install routes and tracks from the PCE.  We
> also understand that some of that work belongs to the PCE working group
> though it is unclear exactly how much that is.****
>
> ** **
>
> Right now the charter has this:****
>
> ** **
>
> 2. Produce "6TSCH centralized management" to define the mechanism by which
> an****
>
> external Path Computation Element can communicate with the 6top protocol
> layer****
>
> ****
> (2) to gather link quality statistics and data flow requirements.  The WG
> will****
>
> initially look at PCEP and CoAP.****
>
> Depending on the applicability of PCEP, this document will be targeted to*
> ***
>
> proposed standard.****
>
> ** **
>
> In the light of our studies, I’d suggest this:****
>
> 2. Produce requirements and an overall architecture for  "6TSCH
> centralized routes and tracks management" ****
>
> describing the mechanism by which an external Path Computation Element
> (PCE) can communicate with ****
>
> devices in a 6TSCH network in order to maintain routing and forwarding
> states. In detail, the WG will ****
>
> consider operations (1) by the device routing layer for (i) sending
> topological information and routing ****
>
> metrics to the PCE, and (ii) getting on-demand routing information; and
> (2) by the device 6top sublayer ****
>
> for exporting neighboring and link quality statistics to the PCE and (2)
> requesting to (re)compute and ****
>
> install a track that meets explicit flow requirements.****
>
> ** **
>
> What do you guys think?****
>
> ** **
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Raghuram Sudhaakar (rsudhaak)
> *Sent:* lundi 22 juillet 2013 07:25
> *To:* [email-masked]
> *Subject:* [6tsch] slides for work items****
>
> ** **
>
> All,****
>
> Attached are the slides for the work items. Please provide your comments.*
> ***
>
> ** **
>
> Specifically, please provide feedback on whether we must have the security
> framework as a work item.****
>
> ** **
>
> -raghuram****
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 12:21:51 +0000

Hello Xavi:

Please let me know how you think the scope was narrowed. The (2) is a Oups, what about:

"
Produce requirements and an overall architecture for  "6TSCH centralized routes and tracks management" describing the mechanism by which an external Path Computation Element (PCE) can communicate with devices in a 6TSCH network in order to maintain routing and forwarding states. In detail, the WG will consider operations (1) by the device routing layer for (i) sending topological information and routing metrics to the PCE, and (ii) getting on-demand routing information; and (2) by the device 6top sublayer for (i) exporting neighboring and link quality statistics to the PCE and (ii) requesting to (re)compute and install a track that meets explicit flow requirements.
"
Cheers,

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: mardi 23 juillet 2013 12:43
To: Pascal Thubert (pthubert)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]; Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] work item 2: centralized route and track computation with PCE

Hi Pascal,
you narrowed the text so it is more focused now, however we have to be very sure to do not skip any aspect. Besides, at the end of the new text:

Produce requirements and an overall architecture for  "6TSCH centralized routes and tracks management" describing the mechanism by which an external Path Computation Element (PCE) can communicate with devices in a 6TSCH network in order to maintain routing and forwarding states. In detail, the WG will consider operations (1) by the device routing layer for (i) sending topological information and routing metrics to the PCE, and (ii) getting on-demand routing information; and (2) by the device 6top sublayer for exporting neighboring and link quality statistics to the PCE and (2) requesting to (re)compute and install a track that meets explicit flow requirements.

On Tue, Jul 23, 2013 at 3:34 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Raghu and all:

What do you guys think?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: lundi 22 juillet 2013 07:25
To: [email-masked]<mailto:[email-masked]>
Subject: [6tsch] slides for work items

All,

-raghuram

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 23 Jul 2013 12:22:11 +0000

Pascal,
The new definition is for sure more complete and shows better what we are planning to do with the 6TSCH centralized approach.
Here are my few comments:

-        I would add a reference to the schedule. Because the PCE will take care of it, and not only of routing and forwarding states.

-        Also in the last part, I would talk in term of schedule, instead of track.

It reads as following:

2. Produce requirements and an overall architecture for  "6TSCH centralized routes and tracks management"
describing the mechanism by which an external Path Computation Element (PCE) can communicate with
devices in a 6TSCH network in order to maintain the schedule, and  routing/forwarding states.

In detail, the WG will consider operations (1) from  the device routing layer to the PCE for (i) sending topological information and routing metrics, and (ii) getting on-demand routing information;
and (2) from the device 6top sublayer  to the PCE for (a) exporting neighboring and link quality statistics and (b) requesting a (new) schedule that meets explicit flow requirements.

Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 12:34 PM
To: Raghuram Sudhaakar (rsudhaak); Maria Rita PALATTELLA; Thomas Watteyne
Cc: [email-masked]
Subject: work item 2: centralized route and track computation with PCE

Hello Raghu and all:

What do you guys think?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: lundi 22 juillet 2013 07:25
To: [email-masked]<mailto:[email-masked]>
Subject: [6tsch] slides for work items

All,

-raghuram

---

From: Qin Wang <[email-masked]>
Date: Tue, 23 Jul 2013 20:33:58 +0800

Hi Pascal,

What I read from the new paragraph is that the task will result in two sets
of operations, i.e. (1) and (2) in the paragraph, one should be implemented
in routing layer, and another should be implemented in 6top sublayer. I
think the operations needed are almost there. But, the problem is 6TSCH
only focus on 6top sublayer, and can not require specific function in
routing layer, correct?

So, can we just describe what operations will be investigated, and don't
specify which layer will be responsible for the operations. In fact, I
think , at end of result, 6top has to take care the operations needed,
otherwise, I'm afraid we will leave another gap in the protocol stack.

How do you think?

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 13:14:31 +0000

Hello Maria Rita.

In one hand, I agree that the device only receives a schedule information, though it is not all of the device schedule.
At the same time, a device A instructs the PCE to compute an end-to-end track between A and Z and once done, the PCE must come back with the individual schedules of all the nodes on the way. We are not clear yet as of how the individual schedules will be pushed to intermediate nodes but that must happen and may reuse PCEP.

"
2. Produce requirements and an overall architecture for  "6TSCH centralized routes and tracks management"
describing the mechanism by which an external Path Computation Element (PCE) can communicate with
devices in a 6TSCH network in order to maintain the routing, forwarding and scheduling states.

In detail, the WG will consider operations (1) from  the device routing layer to the PCE for
(i) sending topological information and routing metrics, and (ii) getting on-demand routing information;
and (2) from the device 6top sublayer  to the PCE for (a) exporting neighboring and link quality statistics
and (b) requesting to (re)install a schedule along a track that meets explicit flow requirements
between the track endpoints.
"

What do you think?

Pascal

From: Maria Rita PALATTELLA [mailto:[email-masked]]
Sent: mardi 23 juillet 2013 14:22
To: Pascal Thubert (pthubert); Raghuram Sudhaakar (rsudhaak); Thomas Watteyne
Cc: [email-masked]
Subject: RE: work item 2: centralized route and track computation with PCE

Pascal,

It reads as following:

Maria Rita

Cc: [email-masked]<mailto:[email-masked]>

Hello Raghu and all:

What do you guys think?

Pascal

All,

-raghuram

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 23 Jul 2013 13:39:41 +0000

Pascal,
Thanks for your explanation. I agree with you.
About the definition of the work item 2, I would keep the last part as it was before, i.e.,

In detail, the WG will consider operations (1) from  the device routing layer to the PCE for
(i) sending topological information and routing metrics, and (ii) getting on-demand routing information;
and (2) from the device 6top sublayer  to the PCE for (a) exporting neighboring and link quality statistics
and (b) requesting to (re)compute and install a track that meets explicit flow requirements."

Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 3:15 PM
To: Maria Rita PALATTELLA; Raghuram Sudhaakar (rsudhaak); Thomas Watteyne
Cc: [email-masked]
Subject: work item 2: centralized route and track computation with PCE

Hello Maria Rita.

"

What do you think?

Pascal

Pascal,

It reads as following:

Maria Rita

Hello Raghu and all:

What do you guys think?

Pascal

All,

-raghuram

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2013 09:58:06 -0400

It seems like you are trying to engineer the solution in the charter text.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 14:27:51 +0000

Maybe so Michael:

We might simplify by omitting:

"
In detail, the WG will consider operations:
(1) from  the device routing layer to the PCE for
	(i) sending topological information and routing metrics, and 
	(ii) getting on-demand routing information; and 
(2) from the device 6top sublayer to the PCE for 
	(a) exporting neighboring and link quality statistics and 
	(b) requesting to (re)compute and install a track that meets explicit flow requirements.
"
>From the charter though we all know that this work has to be done. 

The reason why it's there now is that while doing our homework we found that PCEP only covers a subset of that list.
At some point we will have to map individually all those steps and the standardization work that covers it all may take more than one RFC...

Cheers,

Pascal

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 23 Jul 2013 14:31:15 +0000

Pascal,
I agree with the overall intent in light of the issues with PCEP.

A couple of things -
1) In detail, the WG will consider operations (1) by the device routing layer for
In my understanding, this interaction will be between the PCE and the networking layer. Does this fall under the general 6top scope to even 'define' the requirements? I understand that it may be necessary for operational. IMO, it is better if it is defined by PCE. This part could be an informational document though.

(2) by the device 6top sublayer for exporting neighboring and link quality statistics to the PCE
We can drop the device. Instead - by the 6top sublayer for exporting neighboring and link quality statistics to the PCE. Same comment for (1). 'by the routing layer'

I second the addition of "scheduling states" to the text as discussed below.

-raghuram

From: Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 23, 2013 6:39 AM
To: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>, raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: work item 2: centralized route and track computation with PCE

Pascal,

In detail, the WG will consider operations (1) from  the device routing layer to the PCE for
(i) sending topological information and routing metrics, and (ii) getting on-demand routing information;
and (2) from the device 6top sublayer  to the PCE for (a) exporting neighboring and link quality statistics
and (b) requesting to (re)compute and install a track that meets explicit flow requirements.“

Maria Rita

Hello Maria Rita.

“

“

What do you think?

Pascal

Pascal,

It reads as following:

Maria Rita

Hello Raghu and all:

In the light of our studies, I’d suggest this:

What do you guys think?

Pascal

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: lundi 22 juillet 2013 07:25
To: [email-masked]<mailto:[email-masked]>
Subject: [6tsch] slides for work items

All,

-raghuram

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 14:51:01 +0000

Hello Raghu:

A couple of things -
1) In detail, the WG will consider operations (1) by the device routing layer for
In my understanding, this interaction will be between the PCE and the networking layer. Does this fall under the general 6top scope to even 'define' the requirements? I understand that it may be necessary for operational. IMO, it is better if it is defined by PCE. This part could be an informational document though.
[] This is why the text says "consider" instead of "define". Also the beginning of the sentence changed to say "requirements and an overall architecture".
Also it was lost in the discussions but the trailer of that section now says:
"The requirements and architecture documents would aim at Informational status and as a result standard track work may be triggered within this group or other groups such as the PCE WG."
I uploaded this to the repo but we can certainly still amend it.

(2) by the device 6top sublayer for exporting neighboring and link quality statistics to the PCE
We can drop the device. Instead - by the 6top sublayer for exporting neighboring and link quality statistics to the PCE. Same comment for (1). 'by the routing layer'
[] I do no mind either way. What do others think?

I second the addition of "scheduling states" to the text as discussed below.
[] Great; we are converging. Maybe we can move the discussion toward sthe adoption (or not) of the security as a work item? Since you are the one who introduced the question, maybe you can start the thread?

Cheers,

-raghuram

Pascal,

Maria Rita

Hello Maria Rita.

"

What do you think?

Pascal

Pascal,

It reads as following:

Maria Rita

Hello Raghu and all:

What do you guys think?

Pascal

All,

-raghuram

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 23 Jul 2013 17:31:39 +0200

Pascal, all,

I'm starting from the text currently in the repo (
https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt
):

2. Produce requirements and an overall architecture for "6TSCH centralized
routes and tracks management" describing the mechanism by which an external
Path Computation Element (PCE) can communicate with devices in a 6TSCH
network in order to maintain the routing, forwarding and scheduling states.
In detail, the WG will consider operations:
(1) from the device routing layer to the PCE for
        (i) sending topological information and routing metrics, and
        (ii) getting on-demand routing information; and
(2) from the device 6top sublayer to the PCE for
        (a) exporting neighboring and link quality statistics and
        (b) requesting to (re)compute and install a track that meets
explicit flow requirements.
The requirements and architecture documents would aim at informational
status and as a result standard track work may be triggered within this
group or other groups such as the PCE WG.

I believe we have a consensus on the green parts. The issue, as highlighted
by Michael, is that the blue parts may read like we are trying to solve the
problem in the charter.

We have 3 options:
1. leave as is (or minor rewording)
2. drop the blue part
3. simplify to 1-2 sentences

The charter is too long already, and work item 2 is now by far the largest
one. I would therefore vote for option 2 (dropping). IMO, the statement
"maintain the routing, forwarding and scheduling state" sums it up.

What is missing is the fact that the nodes need to inform the PCE of their
topological and traffic requirements. We could therefore change this work
item:

2. Produce requirements and an overall architecture for "6TSCH centralized
routes and tracks management" describing the mechanism by which an external
Path Computation Element (PCE) can communicate with devices in a 6TSCH
network in order to retrieve topological information and traffic
requirements, and maintain the routing, forwarding and scheduling states.
The requirements and architecture documents would aim at informational
status and as a result standard track work may be triggered within this
group or other groups such as the PCE WG.

Thoughts?
Thomas

On Tue, Jul 23, 2013 at 4:51 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Raghu:****
>
> ** **
>
> A couple of things -****
>
> 1) In detail, the WG will consider operations (1) by the device routing
> layer for****
>
> In my understanding, this interaction will be between the PCE and the
> networking layer. Does this fall under the general 6top scope to even
> 'define' the requirements? I understand that it may be necessary for
> operational. IMO, it is better if it is defined by PCE. This part could be
> an informational document though. ****
>
> *[] *This is why the text says “consider” instead of “define”. Also the
> beginning of the sentence changed to say “requirements and an overall
> architecture”.****
>
> Also it was lost in the discussions but the trailer of that section now
> says:****
>
> “The requirements and architecture documents would aim at *Informational*status and as a result standard track work may be triggered within this
> group or other groups such as the PCE WG.”****
>
> I uploaded this to the repo but we can certainly still amend it.****
>
> ** **
>
> (2) by the device 6top sublayer for exporting neighboring and link
> quality statistics to the PCE ****
>
> We can drop the device. Instead - by the 6top sublayer for exporting
> neighboring and link quality statistics to the PCE. Same comment for (1).
> 'by the routing layer'****
>
> *[] *I do no mind either way. What do others think?****
>
> ** **
>
> I second the addition of "scheduling states" to the text as discussed
> below.****
>
> *[] *Great; we are converging. Maybe we can move the discussion toward
> sthe adoption (or not) of the security as a work item? Since you are the
> one who introduced the question, maybe you can start the thread?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> -raghuram****
>
> ** **
>
> *From: *Maria Rita PALATTELLA <[email-masked]>
> *Date: *Tuesday, July 23, 2013 6:39 AM
> *To: *"Pascal Thubert (pthubert)" <[email-masked]>, raghuram
> sudhaakar <[email-masked]>, Thomas Watteyne <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: work item 2: centralized route and track computation with
> PCE****
>
> ** **
>
> Pascal,****
>
> Thanks for your explanation. I agree with you.****
>
> About the definition of the work item 2, I would keep the last part as it
> was before, i.e.,****
>
>  ****
>
> devices in a 6TSCH network in order to maintain the routing, forwarding
> and scheduling states. ****
>
>  ****
>
> In detail, the WG will consider operations (1) from  the device routing
> layer to the PCE for****
>
> (i) sending topological information and routing metrics, and (ii) getting
> on-demand routing information; ****
>
> and (2) from the device 6top sublayer  to the PCE for (a) exporting
> neighboring and link quality statistics ****
>
> and (b) requesting to (re)compute and install a track that meets explicit
> flow requirements.“****
>
>  ****
>
>  ****
>
> Maria Rita****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* Pascal Thubert (pthubert) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, July 23, 2013 3:15 PM
> *To:* Maria Rita PALATTELLA; Raghuram Sudhaakar (rsudhaak); Thomas
> Watteyne
> *Cc:* [email-masked]
> *Subject:* work item 2: centralized route and track computation with PCE**
> **
>
>  ****
>
> Hello Maria Rita.****
>
>  ****
>
> In one hand, I agree that the device only receives a schedule information,
> though it is not all of the device schedule. ****
>
> At the same time, a device A instructs the PCE to compute an end-to-end
> track between A and Z and once done, the PCE must come back with the
> individual schedules of all the nodes on the way. We are not clear yet as
> of how the individual schedules will be pushed to intermediate nodes but
> that must happen and may reuse PCEP.****
>
>  ****
>
> “****
>
> devices in a 6TSCH network in order to maintain the routing, forwarding
> and scheduling states. ****
>
>  ****
>
> In detail, the WG will consider operations (1) from  the device routing
> layer to the PCE for****
>
> (i) sending topological information and routing metrics, and (ii) getting
> on-demand routing information; ****
>
> and (2) from the device 6top sublayer  to the PCE for (a) exporting
> neighboring and link quality statistics ****
>
> and (b) requesting to (re)install a schedule along a track that meets
> explicit flow requirements****
>
> between the track endpoints.****
>
> “****
>
>  ****
>
> What do you think?****
>
>  ****
>
>  ****
>
> Pascal****
>
>  ****
>
> *From:* Maria Rita PALATTELLA [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* mardi 23 juillet 2013 14:22
> *To:* Pascal Thubert (pthubert); Raghuram Sudhaakar (rsudhaak); Thomas
> Watteyne
> *Cc:* [email-masked]
> *Subject:* RE: work item 2: centralized route and track computation with
> PCE****
>
>  ****
>
> Pascal,****
>
> The new definition is for sure more complete and shows better what we are
> planning to do with the 6TSCH centralized approach.****
>
> Here are my few comments:****
>
> **-          **I would add a reference to the schedule. Because the PCE
> will take care of it, and not only of routing and forwarding states.****
>
> **-          **Also in the last part, I would talk in term of schedule,
> instead of track.****
>
>  ****
>
> It reads as following:****
>
>  ****
>
> devices in a 6TSCH network in order to maintain the schedule, and
>  routing/forwarding states. ****
>
>  ****
>
> In detail, the WG will consider operations (1) from  the device routing
> layer to the PCE for (i) sending topological information and routing
> metrics, and (ii) getting on-demand routing information; ****
>
> and (2) from the device 6top sublayer  to the PCE for (a) exporting
> neighboring and link quality statistics and (b) requesting a (new) schedule
> that meets explicit flow requirements.****
>
>  ****
>
> Maria Rita****
>
>  ****
>
> *From:* Pascal Thubert (pthubert) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, July 23, 2013 12:34 PM
> *To:* Raghuram Sudhaakar (rsudhaak); Maria Rita PALATTELLA; Thomas
> Watteyne
> *Cc:* [email-masked]
> *Subject:* work item 2: centralized route and track computation with PCE**
> **
>
>  ****
>
> Hello Raghu and all:****
>
>  ****
>
> *From:[email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Raghuram Sudhaakar (rsudhaak)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2013 12:10:49 -0400

> From the charter though we all know that this work has to be done.

I suggest that the charter says,

"Based upon intended operations between the device routing layer, and the
PCE, extensions to PCEP will be considered"

That's the only important thing: this WG is allowed to extend PCEP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 17:04:21 +0000

Actually Michael,

That was the original idea. But there is so much more to do than incremental PCEP that we fell back to requirements and architecture.
Also the PCEP changes may better be done within PCE WG if we have a clean req + archi to explain what we need.

What do you think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: mardi 23 juillet 2013 18:11
To: Pascal Thubert (pthubert)
Cc: [email-masked]; Thomas Watteyne
Subject: Re: [6tsch] work item 2: centralized route and track computation with PCE

"Based upon intended operations between the device routing layer, and the PCE, extensions to PCEP will be considered"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 17:05:32 +0000

My suggestion, Thomas,

is to keep that text till the BoF meeting to help explain what we have to do, and probably to remove it after that.

Because our charter will appear too thick...

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mardi 23 juillet 2013 17:32
To: [email-masked]
Subject: Re: [6tsch] work item 2: centralized route and track computation with PCE

Pascal, all,

I'm starting from the text currently in the repo (https://bitbucket.org/6tsch/charter-ietf-6tsch/src/master/charter-ietf-6tsch-00.txt):

2. Produce requirements and an overall architecture for "6TSCH centralized routes and tracks management" describing the mechanism by which an external Path Computation Element (PCE) can communicate with devices in a 6TSCH network in order to maintain the routing, forwarding and scheduling states.
In detail, the WG will consider operations:
(1) from the device routing layer to the PCE for
        (i) sending topological information and routing metrics, and
        (ii) getting on-demand routing information; and
(2) from the device 6top sublayer to the PCE for
        (a) exporting neighboring and link quality statistics and
        (b) requesting to (re)compute and install a track that meets explicit flow requirements.
The requirements and architecture documents would aim at informational status and as a result standard track work may be triggered within this group or other groups such as the PCE WG.

I believe we have a consensus on the green parts. The issue, as highlighted by Michael, is that the blue parts may read like we are trying to solve the problem in the charter.

We have 3 options:

The charter is too long already, and work item 2 is now by far the largest one. I would therefore vote for option 2 (dropping). IMO, the statement "maintain the routing, forwarding and scheduling state" sums it up.

What is missing is the fact that the nodes need to inform the PCE of their topological and traffic requirements. We could therefore change this work item:

2. Produce requirements and an overall architecture for "6TSCH centralized routes and tracks management" describing the mechanism by which an external Path Computation Element (PCE) can communicate with devices in a 6TSCH network in order to retrieve topological information and traffic requirements, and maintain the routing, forwarding and scheduling states.
The requirements and architecture documents would aim at informational status and as a result standard track work may be triggered within this group or other groups such as the PCE WG.

Thoughts?
Thomas

On Tue, Jul 23, 2013 at 4:51 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Raghu:

A couple of things -

Cheers,

-raghuram

Pascal,

Maria Rita

Hello Maria Rita.

"

What do you think?

Pascal

Pascal,

It reads as following:

Maria Rita

Hello Raghu and all:

What do you guys think?

Pascal

All,

-raghuram

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 23 Jul 2013 19:32:13 +0200

I would still suggest to update the text as follows (uniform numbering and
width).
Agreed?

2. Produce requirements and an overall architecture for "6TSCH centralized
routes and tracks management" describing the mechanism by which an external
Path Computation Element (PCE) can communicate with devices in a 6TSCH
network
in order to maintain the routing, forwarding and scheduling states.
In detail, the WG will consider operations:
(1) from the routing layer to the PCE for
    (a) sending topological information and routing metrics, and
    (b) getting on-demand routing information; and
(2) from the 6top sublayer to the PCE for
    (a) exporting neighboring and link quality statistics and
    (b) requesting to (re)compute and install a track that meets explicit
flow
        requirements.
The requirements and architecture documents would aim at Informational
status
and as a result standard track work may be triggered within this group or
other
groups such as the PCE WG.

On Tue, Jul 23, 2013 at 7:05 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  My suggestion, Thomas,****
>
> ** **
>
> is to keep that text till the BoF meeting to help explain what we have to
> do, and probably to remove it after that. ****
>
> ** **
>
> Because our charter will appear too thick…****
>
> ** **
>
> Pascal****
>
> ** **
>
> Of *Thomas Watteyne
> *Sent:* mardi 23 juillet 2013 17:32
> *To:* [email-masked]
> *Subject:* Re: [6tsch] work item 2: centralized route and track
> computation with PCE****
>
> ** **
>
> Pascal, all,****
>
> ** **
>
> ):****
> In detail, the WG will consider operations:****
>
> (1) from the device routing layer to the PCE for****
>
>         (i) sending topological information and routing metrics, and ****
>
>         (ii) getting on-demand routing information; and ****
>
> (2) from the device 6top sublayer to the PCE for ****
>
>         (a) exporting neighboring and link quality statistics and ****
>
> explicit flow requirements.****
>
> group or other groups such as the PCE WG.****
>
> ** **
>
> I believe we have a consensus on the green parts. The issue, as
> highlighted by Michael, is that the blue parts may read like we are
> trying to solve the problem in the charter.****
>
> ** **
>
> We have 3 options:****
>
> 1. leave as is (or minor rewording)****
>
> 2. drop the blue part****
>
> 3. simplify to 1-2 sentences****
>
> ** **
>
> "maintain the routing, forwarding and scheduling state" sums it up.****
>
> ** **
>
> item:****
> requirements, and maintain the routing, forwarding and scheduling states.*
> ***
>
> group or other groups such as the PCE WG.****
>
> ** **
>
> Thoughts?****
>
> Thomas****
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> Hello Raghu:****
>
>  ****
>
> A couple of things -****
>
> -          I would add a reference to the schedule. Because the PCE will
> take care of it, and not only of routing and forwarding states.****
>
> -          Also in the last part, I would talk in term of schedule,
> instead of track.****
>
>  ****
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jul 2013 18:07:28 +0000

+1

Pascal

Le 23 juil. 2013 à 19:32, "Thomas Watteyne" <[email-masked]<mailto:[email-masked]>> a écrit :

I would still suggest to update the text as follows (uniform numbering and width).
Agreed?

2. Produce requirements and an overall architecture for "6TSCH centralized
routes and tracks management" describing the mechanism by which an external
Path Computation Element (PCE) can communicate with devices in a 6TSCH network
in order to maintain the routing, forwarding and scheduling states.
In detail, the WG will consider operations:
(1) from the routing layer to the PCE for
    (a) sending topological information and routing metrics, and
    (b) getting on-demand routing information; and
(2) from the 6top sublayer to the PCE for
    (a) exporting neighboring and link quality statistics and
    (b) requesting to (re)compute and install a track that meets explicit flow
        requirements.
The requirements and architecture documents would aim at Informational status
and as a result standard track work may be triggered within this group or other
groups such as the PCE WG.

On Tue, Jul 23, 2013 at 7:05 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
My suggestion, Thomas,

Because our charter will appear too thick…

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: mardi 23 juillet 2013 17:32
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] work item 2: centralized route and track computation with PCE

Pascal, all,

We have 3 options:

Thoughts?
Thomas

A couple of things -
1) In detail, the WG will consider operations (1) by the device routing layer for
In my understanding, this interaction will be between the PCE and the networking layer. Does this fall under the general 6top scope to even 'define' the requirements? I understand that it may be necessary for operational. IMO, it is better if it is defined by PCE. This part could be an informational document though.
[] This is why the text says “consider” instead of “define”. Also the beginning of the sentence changed to say “requirements and an overall architecture”.
Also it was lost in the discussions but the trailer of that section now says:
“The requirements and architecture documents would aim at Informational status and as a result standard track work may be triggered within this group or other groups such as the PCE WG.”
I uploaded this to the repo but we can certainly still amend it.

Cheers,

-raghuram

Pascal,

Maria Rita

Hello Maria Rita.

“

What do you think?

Pascal

Pascal,

It reads as following:

Maria Rita

Hello Raghu and all:

What do you guys think?

Pascal

All,

-raghuram

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2013 14:12:40 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:

    > That was the original idea. But there is so much more to do than
    > incremental PCEP that we fell back to requirements and architecture.

What's important is that the charter explain that PCEP is in context, and
that extensions to it are.  If there are more things that need to be done
that do not overlap any other WG, then the need to do them will become
obvious from the requirements.

    > Also the PCEP changes may better be done within PCE WG if we have a
    > clean req + archi to explain what we need.

Don't preclude the decision by the IESG.

There is no doubt that the PCE WG will be asked to review, but if they are
about to be closed, or are busy doing other things, or have little common
people with IoT, then it makes no sense.  The IESG might find an PCE expert
to review, or even to co-chair.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jul 2013 09:16:18 +0000

Makes sense Michael.

We also had an agreement to consider CoAP.  We had this text in the previous iteration our the draft charter:

"The WG will initially look at PCEP and CoAP. Depending on the applicability of PCEP, 
this document will be targeted to proposed standard."

The new text lost forgets the references to PCEP and CoAP.

"The requirements and architecture documents would aim at Informational status and as a result
standard track work may be triggered within this group or other groups such as the PCE WG."

What about
"The requirements and architecture documents would aim at Informational status.
The WG will initially look at PCEP and CoAP for applicability and standard track work 
may be triggered within this group or other groups such as the PCE WG."

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: mardi 23 juillet 2013 20:13
To: Pascal Thubert (pthubert)
Cc: [email-masked]; Thomas Watteyne
Subject: Re: [6tsch] work item 2: centralized route and track computation with PCE

    > incremental PCEP that we fell back to requirements and architecture.

What's important is that the charter explain that PCEP is in context, and that extensions to it are.  If there are more things that need to be done that do not overlap any other WG, then the need to do them will become obvious from the requirements.

There is no doubt that the PCE WG will be asked to review, but if they are about to be closed, or are busy doing other things, or have little common people with IoT, then it makes no sense.  The IESG might find an PCE expert to review, or even to co-chair.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2013 10:56:32 -0400

> may be triggered within this group or other groups such as the PCE WG."

okay.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 24 Jul 2013 17:00:56 +0200

Wonderful. The charter now contains this wording.
Thomas