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

[Thomas Watteyne <[e-mail]>]

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) <
[e-mail]> 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****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* mardi 23 juillet 2013 17:32
> *To:* [e-mail]
> *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:****
>
> 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) <
> [e-mail]> 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 <[e-mail]>
> *Date: *Tuesday, July 23, 2013 6:39 AM
> *To: *"Pascal Thubert (pthubert)" <[e-mail]>om>, raghuram
> sudhaakar <[e-mail]>om>, Thomas Watteyne <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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.,****
>
>  ****
>
> 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.“****
>
>  ****
>
>  ****
>
> Maria Rita****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* Pascal Thubert (pthubert) [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Tuesday, July 23, 2013 3:15 PM
> *To:* Maria Rita PALATTELLA; Raghuram Sudhaakar (rsudhaak); Thomas
> Watteyne
> *Cc:* [e-mail]
> *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.****
>
>  ****
>
> “****
>
> 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:[e-mail]<[e-mail]>]
>
> *Sent:* mardi 23 juillet 2013 14:22
> *To:* Pascal Thubert (pthubert); Raghuram Sudhaakar (rsudhaak); Thomas
> Watteyne
> *Cc:* [e-mail]
> *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:****
>
>  ****
>
> 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:[e-mail]<[e-mail]>]
>
> *Sent:* Tuesday, July 23, 2013 12:34 PM
> *To:* Raghuram Sudhaakar (rsudhaak); Maria Rita PALATTELLA; Thomas
> Watteyne
> *Cc:* [e-mail]
> *Subject:* work item 2: centralized route and track computation with PCE**
> **
>
>  ****
>
> 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:*[e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *Raghuram Sudhaakar (rsudhaak)
> *Sent:* lundi 22 juillet 2013 07:25
> *To:* [e-mail]
> *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****
>
> ** **
>