Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 12 Feb 2015 13:06:15 +0000

Hello All,

We are down to the last week of this last call, and haven't received any comments/vote yet.
Please review and send in your comments / vote, this last call ends on 18th Feb.

Thanks,
Shwetha

From: Shwetha bhandari <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 28, 2015 7:05 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

As discussed at the interim meeting last week, we are continuing a series of last calls for the drafts that the group produced over the course of the last 2 years.

This call is for the architecture draft http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05. Since both chairs are co-authors, I will be shepherding this particular document.

The call will last for three weeks ending on 18-Feb-2015 and outcome of the last call will be discussed at the interim call on Friday 20-Feb-2015, 7AM pacific; please express support or concerns about the publication of this work, which is originally aimed at informational status.

Thanks,

Shwetha

---

From: Alfredo Grieco <[email-masked]>
Date: Mon, 16 Feb 2015 10:32:05 +0100

I agree with the publication of the architecture draft. cheers. Alfredo
Il giorno 12/feb/2015, alle ore 14:06, Shwetha Bhandari (shwethab) <[email-masked]> ha scritto:

> From: Shwetha bhandari <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
Luigi Alfredo Grieco, PhD 
Associate Professor
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 16 Feb 2015 06:54:51 -0300

I have read the architecture draft (-05) and I agree with the text
in this last version. Let the draft be published, then.
Regards,

                                 Diego Dujovne

2015-02-16 6:32 GMT-03:00 Alfredo Grieco <[email-masked]>:

> > As discussed at the interim meeting last week, we are continuing a
> series of last calls for the drafts that the group produced over the course
> of the last 2 years.
> > This call is for the architecture draft
> http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05. Since both
> chairs are co-authors, I will be shepherding this particular document.
> > The call will last for three weeks ending on 18-Feb-2015 and outcome of
> the last call will be discussed at the interim call on Friday 20-Feb-2015,
> 7AM pacific; please express support or concerns about the publication of
> this work, which is originally aimed at informational status.
> >
> > Thanks,
> > Shwetha

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 16 Feb 2015 11:57:06 +0100

Dear all,

I finished my review to the architecture draft. IMHO It covers in detail
the 6TiSCH vision and architecture and deserves to be published.

regards,
Xavi

---

From: Gennaro Boggia <[email-masked]>
Date: Mon, 16 Feb 2015 11:38:41 +0100

After the check of the architecture draft (v. 05), I agree for its publication

Regards

Gennaro Boggia

-- 
Gennaro Boggia, PhD
Associate Professor
DEI - Politecnico di Bari
v. Orabona 4
70125 Bari (Italy)
Tel. +39 080 5963913
Fax +39 080 5963410
Skype: g.boggia
e-mail: [email-masked]; [email-masked]
web: http://telematics.poliba.it/boggia

---

From: "S.V.R.Anand" <[email-masked]>
Date: Mon, 16 Feb 2015 19:29:47 +0530

Dear All,

I found that the architecture draft captured most of the general
requirements.

There is just one observation which I could not resist mentioning. It
has to do with
the coupling of real-time application demands with the rest of the
architecture. There could be
application specific "time critical and sudden" events that might call
for on-demand resource allocation.
While we can delegate such an event handling to NME and PCE, perhaps,
bringing in an application awareness
to the overall architecture might be useful so that we are not leaving
out this possible scenario.

Just a thought.

Regards
Anand

On 02/16/2015 04:27 PM, Xavier Vilajosana wrote:
> Dear all, 
>
> I finished my review to the architecture draft. IMHO It covers in
> detail the 6TiSCH vision and architecture and deserves to be published.
>
> regards,
> Xavi
>
> 2015-02-16 10:54 GMT+01:00 Prof. Diego Dujovne
> <[email-masked] <mailto:[email-masked]>>:
>
>     2015-02-16 6:32 GMT-03:00 Alfredo Grieco <[email-masked]
>     <mailto:[email-masked]>>:
>
>         Il giorno 12/feb/2015, alle ore 14:06, Shwetha Bhandari
>         (shwethab) <[email-masked] <mailto:[email-masked]>> ha
>         scritto:
>
>         > Hello All,
>         >
>         > To: "[email-masked] <mailto:[email-masked]>"
>         <[email-masked] <mailto:[email-masked]>>
>         > As discussed at the interim meeting last week, we are
>         continuing a series of last calls for the drafts that the
>         group produced over the course of the last 2 years.
>         http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05.
>         Since both chairs are co-authors, I will be shepherding this
>         particular document.
>         > The call will last for three weeks ending on 18-Feb-2015 and
>         outcome of the last call will be discussed at the interim call
>         on Friday 20-Feb-2015, 7AM pacific; please express support or
>         concerns about the publication of this work, which is
>         originally aimed at informational status.
>         >
>         > Thanks,
>         > Shwetha
>         > [email-masked] <mailto:[email-masked]>
>         Phone: +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>         url: telematics.poliba.it <http://telematics.poliba.it>
>         mail: [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>     www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>     (56 2) 676 8125
>
>     [email-masked] <mailto:[email-masked]>
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: <[email-masked]>
Date: Mon, 16 Feb 2015 14:18:34 +0000

I have reviewed the document especially security part, and I confirm that the security part reflects what was discussed and agreed in the security ad-hoc team.

Best Regards,
Yoshihiro Ohba

From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Wednesday, January 28, 2015 10:36 PM
To: [email-masked]
Subject: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,

Shwetha

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Feb 2015 15:09:37 +0000

A great thought, Anand, 

which has to do external control of 6top, establishing on demand path (tracks) etc…

I think that the next round to charter will have some deterministic/PCE in it, that should address this scenario.

What’s interesting in your suggestion is that it is midway between OTF and classical tracks for control loops, being urgent and dynamic.

Do you have a documented use case?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of S.V.R.Anand
Sent: lundi 16 février 2015 15:00
To: [email-masked]
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Dear All,

I found that the architecture draft captured most of the general requirements. 

There is just one observation which I could not resist mentioning. It has to do with
the coupling of real-time application demands with the rest of the architecture. There could be
application specific "time critical and sudden" events that might call for on-demand resource allocation.
While we can delegate such an event handling to NME and PCE, perhaps, bringing in an application awareness
to the overall architecture might be useful so that we are not leaving out this possible scenario. 

Just a thought.

Regards
Anand

Dear all,  

I finished my review to the architecture draft. IMHO It covers in detail the 6TiSCH vision and architecture and deserves to be published.

regards,

Xavi

Regards,

                                 Diego Dujovne

-- 

DIEGO DUJOVNE

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 16 Feb 2015 15:52:50 +0000

Dear all,

I have finished my review of the architecture-05 draft, and I believe the document is ready to be published.

I have only few minor comments:
typos to be fixed:
pag 8 LLN odes -> LLN nodes
pag. 19 6TISCH -> 6TiSCH
pag 23 as started -> has started

Moreover,
pag 19 in the definition of CDU matrix, I would specify height and width, and after the timeslot duration (in the current version timeslot duration is in the middle, and it makes a bit hard to read and clearly understand the CDU matrix structure)
pag 7 are we sure we want to mention in the next round of the document we will have evaluated PANA applicability? we may need/want to publish the second part of the architecture before that, we don't know yet. So, we could skip that, if you agree.

Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 12, 2015 2:06 PM
To: [email-masked]
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

Hello All,

Thanks,

Shwetha

---

From: "Rouhollah Nabati(Google)" <[email-masked]>
Date: Mon, 16 Feb 2015 20:10:27 +0330

Hello All,

Page 7 first paragraph. LLN odes
Page 9 end of third paragraph. foster

On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> What’s interesting in your suggestion is that it is midway between OTF and
> classical tracks for control loops, being urgent and dynamic.
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *S.V.R.Anand
> *Sent:* lundi 16 février 2015 15:00
> *To:* [email-masked]
> *Subject:* Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05
>
>
>
> Dear All,
>
> 2015-02-16 10:54 GMT+01:00 Prof. Diego Dujovne <[email-masked]
> >:
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>
> *, and is believed to be clean. *
>
>
>
>
>
> *_______________________________________________*
>
> *6tisch mailing list*
>
> [email-masked] <[email-masked]>*
>
> *https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>*
>
>
>
>
> --

-- 
Best Regards,
Rouhollah

---

From: "S.V.R.Anand" <[email-masked]>
Date: Mon, 16 Feb 2015 23:51:46 +0530

Pascal,

Thanks for the positive feedback !

I wish I have a documented use case to share with. But we can anticipate
scenarios of the kind I am referring to. Let us say, under normal 
operational
conditions, an application works with a set of first level of sensors being
active and monitoring parameters at certain sampling rate. When that
application suddenly detects certain abnormality or detects an impending
catastrophic/crisis condition (eg., a gas leak in a chemical factory), 
it can
(i) start activating other sensors (eg., temperature) or second level of
sensors which might be the result of that event (ii) increase the 
sampling rate
of the sensors in the field to gather fine grain information and track the
progress of the event. For both actuation and the subsequent change in the
traffic profile, there is a need for quick resource allocation or
re-allocation.

I suppose those who are from the industry in this mailing list will have
similar use cases.

Anand

On Monday 16 February 2015 08:39 PM, Pascal Thubert (pthubert) wrote:
>
 > A great thought, Anand,
 >
 >
 >
 > which has to do external control of 6top, establishing on demand path 
(tracks) etc&
 >
 > I think that the next round to charter will have some 
deterministic/PCE in it, that should address this scenario.
 >
 > Whats interesting in your suggestion is that it is midway between 
OTF and classical tracks for control loops, being urgent and dynamic.
requirements.
has to do with
 > > As discussed at the interim meeting last week, we are continuing a 
series of last calls for the drafts that the group produced over the 
course of the last 2 years.
 > > The call will last for three weeks ending on 18-Feb-2015 and 
outcome of the last call will be discussed at the interim call on Friday 
20-Feb-2015, 7AM pacific; please express support or concerns about the 
publication of this work, which is originally aimed at informational status.

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Mon, 16 Feb 2015 19:14:39 +0000

I have reviewed and support the publication of draft-ietf-6tisch-architecture-05.

-raghuram

From: "Shwetha Bhandari (shwethab)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 12, 2015 at 5:06 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

Hello All,

Thanks,

Shwetha

---

From: Pat Kinney <[email-masked]>
Date: Mon, 16 Feb 2015 15:09:36 -0600

Upon reviewing he architecture draft http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05, I fully support its publication.

Thanks, Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

From: "Shwetha Bhandari (shwethab)" <[email-masked] <mailto:[email-masked]>>
Date: Thursday, February 12, 2015 at 5:06 AM
To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

From: Shwetha bhandari <[email-masked] <mailto:[email-masked]>>
Date: Wednesday, January 28, 2015 7:05 PM
To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
Subject: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

As discussed at the interim meeting last week, we are continuing a series of last calls for the drafts that the group produced over the course of the last 2 years.
This call is for the architecture draft http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05 <http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05>. Since both chairs are co-authors, I will be shepherding this particular document.
The call will last for three weeks ending on 18-Feb-2015 and outcome of the last call will be discussed at the interim call on Friday 20-Feb-2015, 7AM pacific; please express support or concerns about the publication of this work, which is originally aimed at informational status.

Thanks,
Shwetha

---

From: "Wang, Chonggang" <[email-masked]>
Date: Mon, 16 Feb 2015 22:28:37 +0000

Hi All,

I have reviewed the architecture draft (-05) and support to publish it.

A few minor comments I had are listed below.

·         pp. 3, 2nd paragraph, “…control operations such industrial automation…” ---> ““…control operations such as industrial automation…”

·         pp.3, 3rd paragraph, “…timeSlotted Channel  Hopping …” ---> “…Time Slotted Channel Hopping…”

·         pp.3, 4th paragraph, the fulling spelling of TSN was givning in the 2nd paragraph. Then, please put the acronym TSN in the 2nd paragraph

·         pp.3, both “deterministic” and “Deterministic” are used in a few places. Better use one form if they mean the same thing throughout the draft.

·         pp.4, 2nd paragraph “Route Computation may be achieved in a centralized fashion by a Path Computation Element (PCE), in a distributed fashion using the Routing Protocol for Low Power and Lossy Networks (RPL) [RFC6550], or in a mixed mode”,

o   Is RPL claim to be a distributed route computation? I believe in the non-storing mode, the root calculates the route and use source routing to route the packet to the destination.

·         pp.4, last two paragraphs from the bottom and a few other place in the draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”

·         pp. 5, section 3, 1st paragraph,  “Some aspects of this architecture derive from existing industrial standards for Process Control by its focus on Deterministic Networking, in particular with the use of the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized PCE.”

o   What are the “existing industrial standard”? WirelessHart? Certain references would help.

·         pp.6, the title of Figure could be more complete by saying something like “Figure 1, Basic Configuration of 6TiSCH Network”

·         pp. 6, the paragraph under Fig. 1, “neighbor Devices” ---> “neighbor devices”

·         pp.6, 2nd paragraph from the bottom, “LLN Border Router (LBR)” were mentioned twice in one sentence.

·         pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol Stack”

·         pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is correct but it could imply that only HC is used there – which is not true. Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g. adaptation, header compression)”

·         pp.9, the 4th paragraph, “join process” was introduced all of a sudden. Wonder if it could read more smoothly by briefly mentioning these concepts (e.g. neighbor discovery, join process, track reservation, 6top, packet forwarding, etc.) together and their relationship from architectural perspective somewhere in Section 4 (e.g. at the beginning?).

·         pp.9, 3rd paragraph, “TEAS protocol will be required to expose the device capabilities and the network peerings to the PCE, and a protocol such as a lightweight PCEP or an adaptation of CCAMP G-MPLS formats and procedures will be used to publish the tracks, computed by the PCE, to the devices.”

·         Can you put the reference about “TEAS” and “CCAMP”?

·         pp.10, 2nd paragraph, “should be portable only other LLN link types”. It reads a little awkward and maybe some words missing around “only”

·         pp.10, 2nd paragraph, “A new version of the standard is expected in 2015”. What’s “the standard” refer to?

·         pp.10, 4th paragraph, do you want to add a reference for ISA100.20?

·         pp.16, 4th paragraph, “motes” was used. Can we change it to devices or nodes to make terms more consistent?

·         pp.17, 2nd paragraph, “but also allows an upper layer like RPL.” This sentence seems not finished

·         pp.18, 2nd paragraph, “that is is not capable of”. One “is” should be removed.

·         pp.19, the last paragraph, “an higher layer” ---> “a higher layer”

·         pp.19, the last paragraph, “DSCP can therefore be used”. Suggest giving the full spelling and reference to DSCP or removing this sentence.

·         pp.19, 5th paragraph, “A 6TISCH Instance is associated to one slotFrame.”,

·         Wonder what is a 6TiSCH Instance? Why associate to only “one” Slotframe? In previous paragraph, it mentions “Multiple slotFrames can coexist in a node schedule”.

·         pp.21, section 9, both “Static Scheduling” and “Minimal Static Scheduling” are used. Are they the same?

·         pp.22, 1st paragraph, “This scheduled can be” ---> “This schedule can be”

·         pp.24, section 10.1, 1st paragraph, “A bundle of cells set to receive (RX-cells) is uniquely paired to a bundle of cells that are set to transmit (TX-cells), representing a layer-2 forwarding state that can be used regardless of the network layer protocol.”

·         Is a Track uni-directional or bi-directional? Is there any ACK for the transmission?

·         pp.27, Figure 6, suggest adding what is the value “set dmac to” and “restore dmac”

·         pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress point does not have a MAC address that matches the configuration, the Track installation fails.”,

·         Wonder if it is ingress point or egress point that installs the Track

·         pp.30, 1st paragraph, “Centralized routes can for example computed”. The word “be” was missing.

·         pp.30, section 11, it will be helpful if the difference between routing discussed in this section and forwarding discussed in section 10 could be clarified a little bit

Thanks,
Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 12, 2015 8:06 AM
To: [email-masked]
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

Hello All,

Thanks,

Shwetha

---

From: "Rouhollah Nabati(Google)" <[email-masked]>
Date: Tue, 17 Feb 2015 07:47:08 +0330

Dear All,

I finished reading the architecture draft (v. 05) and some questions:

1-Do registration phase may work properly when network builds up, if when
RPL tree  grows up and extends like a complete tree (I mean in distributed
manner). Maybe some additional controls needed later?

2-Do you think DICE(figure 3. page 7) should be defined in the Terminology
draft.

Typos:
Page 21. scheduled

On Mon, Feb 16, 2015 at 8:10 PM, Rouhollah Nabati(Google) <[email-masked]
<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
>> A great thought, Anand,
>>
>>
>>
>> (tracks) etc…
>> I think that the next round to charter will have some deterministic/PCE
>> in it, that should address this scenario.
>>
>> What’s interesting in your suggestion is that it is midway between OTF
>> and classical tracks for control loops, being urgent and dynamic.
>>
>> *From:* 6tisch [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of
>> *S.V.R.Anand
>> *To:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>>
>>
>>
>> Il giorno 12/feb/2015, alle ore 14:06, Shwetha Bhandari (shwethab) <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> ha scritto:
>>
>>
>> > Hello All,
>> >
>> > From: Shwetha bhandari <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> > To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>"
>> <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>*
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Best Regards,
Rouhollah

-- 
Best Regards,
Rouhollah

---

From: <[email-masked]>
Date: Tue, 17 Feb 2015 08:32:43 +0000

Dear All,

I vote YES on the architecture draft http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05.

Kind regards,

Pouria

________________________________
From: 6tisch <[email-masked]> on behalf of Shwetha Bhandari (shwethab) <[email-masked]>
Sent: Thursday, February 12, 2015 2:06 PM
To: [email-masked]
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

Hello All,

Thanks,

Shwetha

---

From: Giuseppe Piro <[email-masked]>
Date: Tue, 17 Feb 2015 10:54:03 +0100

Hi all,

I agree with the publication of draft-ietf-6tisch-architecture-05. The
whole document is ok. Section 13 reflects what discussed within the
security team.

Thanks and regards,
Giuseppe

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: g <http://telematics.poliba.it/piro>iuseppepiro.com

---

From: Guillaume Gaillard <[email-masked]>
Date: Tue, 17 Feb 2015 17:06:28 +0100

Hello all,

I agree and fully support the publication of the architecture draft 05.

Indeed, it clearly defines the required architecture including the work
done until now, and lets the door open to further contributions,
particularly concerning the relationships between COMI, CoAP, and 6top
sublayer, in order to manage 6tisch resource (page 9).

In my opinion, the draft allows to maintain end-to-end performance over a
LLN.

A few minor comments :

1) The term reallocation/relocation of cells :
8.1 p16 a cell reallocation
differs from
9.2 p22 the relocation of a soft cell / relocation is done
=> I am not sure if there has been a discussion on this term, but I vote
for reallocation.

2) 8.2 p16 a set of quality metrics (RSSI, LQI)
I think you cannot be specific to just two metrics (RSSI, LQI).
The words "a set of" allows to define more metrics. And I think it is fine.
=> what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.)
" ?

3) 8.2 p16 and used to compute a Rank Increment
The statistics of 6top may have other usages than incrementing the ranks,
for upper layers, and for resource management.
 => what about : "and used for instance to compute" ?

4) 10.2 p28 : a degree of flow control base on => I think it should be
"based on".

5) (Already pointed out) 11 p 30 Centralized routes con for example
computed => be computed

Thanks,

Guillaume

---

From: "Wang, Chonggang" <[email-masked]>
Date: Tue, 17 Feb 2015 16:43:26 +0000

Just wanted to clarify that most of my comments below are about typos and editorial thing, which can be easily fixed.

I support the publication of 6TiSCH architecture draft.

Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Wang, Chonggang
Sent: Monday, February 16, 2015 5:29 PM
To: [email-masked]'
Cc: 'Pascal Thubert (pthubert) ([email-masked])'; [email-masked]'
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hi All,

Thanks,
Chonggang

From: 6tisch [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 12, 2015 8:06 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello All,

Thanks,
Shwetha

Hello All,

Thanks,

Shwetha

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 17 Feb 2015 10:49:49 -0800

My 2¢ feedback on the security section:

13 - Sending link-layer frames in the clear in the initial stage of joining is not providing any benefit. We should always use authentication, even if the key is not secret, as it provides the ability to reject similar frames from other 802.15.4-based protocols.  It also isn’t necessary to discuss such a detail here.

13.1  - 
* "Triage" - So the JCE decides which nodes are more important and assigns resources to them first? How?  Note this term is not used in draft-richardson-6tisch-security-architecture-02.
* "arbitrage" should be “arbitrate”

Other than that, it seem to be capturing the overall spirit of the security architecture and highlights the open areas of security discussion, e.g. that PANA is an open issue. 

Couple minor points:

1) Introduction and 3) Application and Goals sections need review. They kind of wander all over the place.

5.1) What does "volume" mean in this context? Is this referring to other as yet defined documents, or later revisions of this document?

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. 

On Feb 12, 2015, at 5:06 AM, Shwetha Bhandari (shwethab) <[email-masked]> wrote:

> http://cp.mcafee.com/d/1jWVIp4wUq43qb2r8VxNAQsECXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVIs-_JA67-LP5XCzBBzHTbFIIzK7nppjpVqWtAkRkknel3PWApmU6CQjq9K_8I9LfzAm4PhOrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4PrAVkIjbAaJMJZ0lbVKY01dEToKUr1vF6y0QJKjBiNcQKCy0aXipEwJFVVEwtH4Qg8hRSpunPtbKjBiNcLIr4Vj-QSU-nK-rsKrcD2a

---

From: Géraldine TEXIER <[email-masked]>
Date: Wed, 18 Feb 2015 17:49:32 +0100

Dear All,

I have reviewed the draft draft-ietf-6tisch-architecture-05 and I support its publication
Best Regards
Geraldine

-- 
Geraldine TEXIER

Associate Professor
IRISA/ Reop Team
Institut Mines-Télécom ; TELECOM Bretagne  ;
RSM Department
2 rue de la Châtaigneraie - CS 17607
35576 Cesson Sevigné Cedex- France
Tel: +33 299 127 038 - Fax: +33 299 127 030

> From: "Shwetha Bhandari (shwethab)" <[email-masked]>

---

From: Rene Struik <[email-masked]>
Date: Wed, 18 Feb 2015 23:39:05 -0500

Dear colleagues:

I think the draft document draft-ietf-6tisch-architecture-05 is in 
relatively good shape.

One note: the second para of Clause 13 seems out of place and should be 
removed.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Feb 2015 14:58:41 +0000

Dear all:

I agree with all Guillaume’s suggested edit. If there is any objection, please say it so now, else you’ll find them in 06.

Thanks Guillaume !

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Guillaume Gaillard
Sent: mardi 17 février 2015 17:06
To: Giuseppe Piro
Cc: [email-masked]
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Hello all,

Indeed, it clearly defines the required architecture including the work done until now, and lets the door open to further contributions, particularly concerning the relationships between COMI, CoAP, and 6top sublayer, in order to manage 6tisch resource (page 9). 

In my opinion, the draft allows to maintain end-to-end performance over a LLN.

A few minor comments :

differs from 

=> I am not sure if there has been a discussion on this term, but I vote for reallocation.

=> what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.) " ?

The statistics of 6top may have other usages than incrementing the ranks, for upper layers, and for resource management.

4) 10.2 p28 : a degree of flow control base on => I think it should be "based on".

5) (Already pointed out) 11 p 30 Centralized routes con for example computed => be computed

Thanks,

Guillaume

Hi all, 

I agree with the publication of draft-ietf-6tisch-architecture-05. The whole document is ok. Section 13 reflects what discussed within the security team. 

Thanks and regards, 

Giuseppe 

On Thu, Feb 12, 2015 at 2:06 PM, Shwetha Bhandari (shwethab) <[email-masked]> wrote:

Hello All,

Thanks,

Shwetha

Hello All,

This call is for the architecture draft  <http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05> http://tools.ietf.org/html/draft-ietf-6tisch-architecture-05. Since both chairs are co-authors, I will be shepherding this particular document.

Thanks,

Shwetha

 

-- 

Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di Bari

phone: +39 080 5963301 <tel:%2B39%20080%205963301> 
web: g <http://telematics.poliba.it/piro> iuseppepiro.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Feb 2015 15:23:06 +0000

Thanks Rouhollah!

I agree with most proposed changes, though I do not know what to do with your item 1, more below.

All: please let us know if you disagree with the edits discussed below

All: you can see the individual edits for each review here

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/all 

To see what changed, please click on the commit number and then select the XML file.

For this one you’ll get https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/cca78350db5d5ad3a8b031944e44ce15972453ae#chg-draft-ietf-6tisch-architecture-06.xml 

Cheers,

Pascal

1-Do registration phase may work properly when network builds up, if when RPL tree  grows up and extends like a complete tree (I mean in distributed manner). Maybe some additional controls needed later?

> Unsure what you really mean here. There can be issues with security and the join process work is looking at that. Then there’s RPL use of slotted aloha slots. Then there’s the resource allocation problem (chunks between parents and cells in a parent’s chunk between children). We’ll recharter for all these things but the first volume of the architecture does not cover that.

2-Do you think DICE(figure 3. page 7) should be defined in the Terminology draft.

Well, that’s a WG now, unsure what the standard name will be. I can add the following text:

“        DTLS In Constrained Environments (DICE) is at the time of this

         writing the probable way LLN nodes will provide end-to-end security for

         UDP/CoAP packets.”

Typos:

Page 21. scheduled 

Ack

On Mon, Feb 16, 2015 at 8:10 PM, Rouhollah Nabati(Google) <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> > wrote:

Hello All,

ack

I missed the issue there?

On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> > wrote:

A great thought, Anand, 

Pascal

From: 6tisch [mailto:[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> ] On Behalf Of S.V.R.Anand
Sent: lundi 16 février 2015 15:00
To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> 
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Dear All,

Just a thought.

Regards
Anand

Dear all,  

regards,

Xavi

2015-02-16 10:54 GMT+01:00 Prof. Diego Dujovne <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> >:

Regards,

                                 Diego Dujovne

2015-02-16 6:32 GMT-03:00 Alfredo Grieco <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> >: 

I agree with the publication of the architecture draft. cheers. Alfredo
Il giorno 12/feb/2015, alle ore 14:06, Shwetha Bhandari (shwethab) <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> > ha scritto:

> From: Shwetha bhandari <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> >
> To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> " <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> >

mail: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> 

-- 

DIEGO DUJOVNE

 

 

-- 

Best Regards,

Rouhollah

-- 

Best Regards,

Rouhollah

-- 

Best Regards,

Rouhollah

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Feb 2015 10:40:56 +0000

Thanks a bunch for the detailed review Chonggang!

The proposed diffs for your review is quite extensive: 

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/1a72a0f578371be194832d6525c1e502e0055b92#chg-draft-ietf-6tisch-architecture-06.xml 

Please see below for details:

-> done

-> Actually I think the group settled for TimeSlotted, I migrated all to that

 

-> It was but I changed the format to be more classical

-> Done, I used the uppercase because our Deterministic is not the one from math

-> I see what you are saying. I agree that storing mode centralized the computation of routes down but that’s based on a parent selection that is still distributed. I do not think that being very specific like “RPL is mostly distributed but then there can be a bit of centralized computation” will help a lot the understanding of the section. I’d rather leave it at that.

-> sure, many occurrences fixed

-> OK, added

-> OK

-> OK

->reworded

-> Yes, I added envisioned since all is not fully cast in stone

-> added

-> will be hard without duplicating a lot; let me think of that one. In any fashion, I can clarify join there. I propose 

         Security is often handled at Layer-2 and Layer 4. Authentication

         during the process on joining or re-joining the network

         is discussed in <xref target="sec"/> and the

         applicability of existing protocols such as

         the <xref target="RFC5191">

         Protocol for Carrying Authentication for Network access (PANA)</xref>

          will be studied in a next volume of this document.

-> added, text looks like this now:

         The work on centralized track computation is deferred to a subsequent volume 

         of the architecture. The Path Computation Element (PCE) is certainly

         the core component of that architecture. Around the PCE, a protocol 

         such as an extension to a TEAS <xref target="TEAS"/> protocol 

         (maybe running over CoAP as illustrated) will be required to expose the 

         device capabilities and the network peers to the PCE, and a protocol

         such as a lightweight PCEP or an adaptation of CCAMP <xref target="CCAMP"/>

         G-MPLS formats and procedures will be used to publish the tracks, 

         computed by the PCE, to the devices (maybe in a fashion similar to RSVP-TE).      

->sure! The text now reads

      The current charter positions 6TiSCH on IEEE802.15.4 only.

      Though most of the design should be portable on other link types,

        6TiSCH has a strong dependency on 802.15.4 and its evolution.

-> clarified as follows

      The current charter positions 6TiSCH on IEEE802.15.4 only.

      Though most of the design should be portable on other link types,

      6TiSCH has a strong dependency on IEEE802.15.4 and its evolution. 

      A new version of the IEEE802.15.4 standard is expected in 2015. 

-> there’s no good link. I added a link to ISA100, and explained what CNM is.

      ISA100 <xref target="ISA100"/> Common Network Management (CNM) is another 

      external work of interest for 6TiSCH. The group, referred to as ISA100.20,

      defines a Common Network Management framework that should enable the

      management of resources that are controlled by heterogeneous protocols

      such as ISA100.11a <xref target="ISA100.11a"/>, WirelessHART 

      <xref target="WirelessHART"/>, and 6TiSCH. Interestingly, the

      establishment of 6TiSCH Deterministic paths, called tracks,

      are also in scope, and ISA100.20 is working on requirements for DetNet.

-> moved to devices, but added the following

on behalf of the wireless devices (also called motes),

-> OK, the sentence now looks like

           The receiver of the Enhanced Beacon MAY

            be listening at the cell to get the Enhanced Beacon ([IEEE802154e]).

            6top takes this way to establish broadcast channel, which not only

            allows TSCH to broadcast Enhanced Beacons, but also allows protocol

             exchanges by an upper layer such as RPL.

-> ack

-> ack

-> I used ‘Differentiated Services [RFC2474]’ instead 

-> that’s really a 6top internal. Much too detailed, I removed the sentence.

-> same, that is an internal construct

-> removed minimal. Intention was to say that this is the minimal support

-> gone

-> I added

            A Track is a unidirectional path between a source and a destination.

            In a Track cell, the normal operation of IEEE802.15.4e

            Automatic Repeat-reQuest (ARQ) usually happens, though the 

            acknowledgment may be omitted in some cases, for instance if there 

            is no scheduled cell for a retry.

-> done

I think the text is correct. The configuration of the tunnel is yet TBD by this group (RSVP-TE?), but the egress must be able to deliver a packet to the MAC address that is at the end of the tunnel.

fixed

Added

        By forwarding, this specification means the per-packet operation that 

         allows to deliver a packet to a next hop or an upper layer in this node.

         Forwarding is based on pre-existing state that was installed as a 

          result of a routing computation.

Fantastic review Chonggang!

Thanks you so much.

Pascal

Chonggang Wang
Member Technical Staff
InterDigital Communications, Inc.
781 Third Ave
King of Prussia, PA 19406
T: +1 610.878.5731
[email-masked]
www.InterDigital.com

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

Hello All,

Thanks,

Shwetha

Hello All,

Thanks,

Shwetha

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Feb 2015 11:03:34 +0000

Hello René:

I removed that section, and added an appendix that lists the 6TiSCH personal
submissions that may impact the next volumes.

The new text reads as follows

Appendix A.  Personal submissions relevant to the next volumes  

   This volume only covers a portion of the total work that is needed to  

   cover the full 6TiSCH architecture.  Missing portions include  

   Deterministic Networking with Track Forwarding, Dynamic Scheduling,  

   and Security.  

   [I-D.richardson-6tisch-security-architecture] elaborates on the  

   potential use of 802.1AR certificates, and some options for the join  

   process are presented in more details.  

   [I-D.dujovne-6tisch-on-the-fly] discusses the use of the 6top  

   sublayer [I-D.wang-6tisch-6top-sublayer] to adapt dynamically the  

   number of cells between a RPL parent and a child to the needs of the  

   actual traffic.  

The diffs are here:

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/0e07e721
ce096cbd02f93c5cfbf9e58e576ac124?at=master#chg-draft-ietf-6tisch-architectur
e-06.xml 

Cheers,

Pascal

From: Rene Struik [mailto:[email-masked]] 
Sent: jeudi 19 février 2015 05:39
To: Géraldine TEXIER; Shwetha Bhandari (shwethab)
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05

Dear colleagues:

Best regards, Rene

Dear All, 

I have reviewed the draft draft-ietf-6tisch-architecture-05 and I support
its publication

Best Regards

Geraldine

-- 

Geraldine TEXIER

Associate Professor
IRISA/ Reop Team

Hello All,

We are down to the last week of this last call, and haven't received any
comments/vote yet. 

Please review and send in your comments / vote, this last call ends on 18th
Feb.

Thanks,

Shwetha

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Feb 2015 12:31:04 +0000

Thanks for you review Maria-Rita!

The link to the proposed diffs is here

https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/commits/28c63162
89ff06e21adc340c962acca94277de22#chg-draft-ietf-6tisch-architecture-06.xml

More details below:

I have finished my review of the architecture-05 draft, and I believe the
document is ready to be published.

typos to be fixed:  

pag. 19 6TISCH -> 6TiSCH

-> all fixed

Moreover,

pag 19 in the definition of CDU matrix, I would specify height and width,
and after the timeslot duration (in the current version timeslot duration is
in the middle, and it makes a bit hard to read and clearly understand the
CDU matrix structure)

-> text now reads:

         In order to describe that formatting of time and frequencies, the 

         6TiSCH architecture defines a global concept that is called a
Channel 

         Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 

         cells with an height equal to the number of available channels 

         (indexed by ChannelOffsets) and a width (in timeSlots) that is the 

         period of the network scheduling operation (indexed by slotOffsets)
for

         that CDU matrix. The size of a cell is a timeSlot duration, and 

         values  of 10 to 15 milliseconds are typical in 802.15.4e TSCH to 

         accommodate for the transmission of a frame and an ack, including
the 

         security validation on the receive side which may take up to a few 

           milliseconds on some device architecture.

pag 7 are we sure we want to mention in the next round of the document we
will have evaluated PANA applicability? we may need/want to publish the
second part of the architecture before that, we don't know yet. So, we could
skip that, if you agree.

-> I'd like to leave things open. What about:

      Future work on 6TiSCH security and will examine in deeper detail how
SACM,

      ACE, DICE, IEEE802.15.9 and eventually PANA and 802.1x may apply to
6TiSCH 

      networks to perform Authentication and Authorization, to secure
transactions 

      end-to-end, and to maintain the  security posture of a device over its
lifetime. 

      The result of that work will be described in a subsequent volume of
this

       architecture.

Cheers

Pascal