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

["Pascal Thubert (pthubert)" <[e-mail]>]

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:

 

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

 

-> done

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

 

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

 

·         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

 

 

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

 

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

 

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

 

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

 

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

 

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

 

-> sure, many occurrences fixed

 

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

 

-> OK, added

 

 

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

 

-> OK

 

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

 

-> OK

 

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

 

->reworded

 

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

 

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

 

·         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)”

 

-> added

 

·         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?).

 

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

 

·         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”?

 

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

 

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

 

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

 

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

 

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

      

 

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

 

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

 

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

 

-> moved to devices, but added the following

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

 

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

 

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

 

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

 

-> ack

 

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

-> ack

 

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

 

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

 

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

 

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

 

·         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”.

 

-> same, that is an internal construct

 

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

 

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

 

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

 

-> gone

 

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

 

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

 

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

 

-> done

 

·         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

 

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.

 

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

 

fixed

·         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

 

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
[e-mail]
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.

 

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

 

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 <[e-mail]>
Date: Wednesday, January 28, 2015 7:05 PM
To: "[e-mail]" <[e-mail]>
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