Subject: [6tisch] #39 (architecture): Ralph's INT AREA review

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 26 Nov 2015 14:31:19 -0000

#39: Ralph's INT AREA review

 I am an assigned INT directorate reviewer for draft-ietf-6tisch-
 minimal-12.  These comments were written primarily for the benefit of the
 Internet Area Directors. Document editors and
 shepherd(s) should treat these comments just like they would treat
 comments from any other IETF contributors and resolve them along with any
 other Last Call comments that have been received. For more details on the
 INT Directorate, see http://www.ietf.org/iesg/directorate.html.

 Review submitted by Ralph Droms

 Summary: In my opinion, the WG needs to reconsider some of the fundamental
 aspects of this proposed specification, and the document needs significant
 restructuring and editing.  I will be happy to work with the WG to revise
 the document and review future revisions.

 There may be overlaps between my comments and those in other reviews
 because I avoided reading those reviews before writing up my review.

 Here are my comments on the document.  The first four comments apply to
 the document as a whole, while the remainder address more specific issues,
 roughly in the order of appearance in the document.

 1. Goals and requirements are unclear

 The requirements for this document are unclear to me.  Exactly what
 services would a "minimal mode of operation" provide?  The Abstract and
 most of the document talks about the operation of an IEEE 802.15.4 TSCH
 network, yet the title of the document is "Minimal 6TiSCH Configuration".
 Does a network that follows these rules provide an L2 IEEE 802.15.4
 service, an IPv6 6TiSCH service, ???

 Related to this question, does this document describe "a minimal set of
 rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of
 operation" (both text snippets from the Abstract).

 2. Requirement for RPL is ill-advised

 This document seems to be focused on IEEE 802.15.4 TSCH operational
 parameters.  Yet, it calls for the use of RPL, which seems to me to be a
 highly undesirable entangling of protocols at different layers of the
 protocol stack.  IEEE 802.15.4 TSCH is expected to be used in networks
 that don't use RPL.

 My understanding of the document is that RPL is assumed to be in use
 because it is required in a 6TiSCH network.  RPL is then used to generate
 the Join Priority through the DAGRank function as specified in section
 7.2.  The use of RPL implies to me the configuration and operation of a
 full IPv6 stack, which hardly seems like a minimal mode of operation for
 IEEE 802.15.4 TSCH.

 I have a question about this text from section 7.2:

   When a node joins the network,
   it MUST NOT send EBs before having acquired a RPL rank.  This avoids
   routing loops and matches RPL topology with underlying mesh topology.

 What is meant by "avoiding routing loops"?  My understanding is that IEEE
 802.15.4 TSCH simply provides for frame delivery between neighbors and
 does not provide frame forwarding.  How would routing loops arise from
 running IEEE 802.15.4 TSCH?

 Has the WG considered reorganizing the 6TiSCH protocol suite and documents
 to separate the minimal operation of IEEE 802.15.4 TSCH from
 IPv6/RPL/ND/etc?  For example, has the WG considered allowing a simpler,
 initial Join Priority scheme that would provide minimal IEEE
 802.15.4 TSCH operation until the full IPv6 suite is running, at which
 time RPL will provide optimal routing.

 3. Restatement of specifications in IEEE 802.15.4 documents

 I haven't read the most recent IEEE 802.15.4 docs and it has been a while
 since I took a close look at earlier revs.  With that disclaimer in mind,
 how much of the text in sections 3 through 9 is a restatement of the IEEE
 802.15.4 specification and how much is the specification of operational
 parameters for minimal operation of a IEEE 802.15.4 TSCH network?
 Restatement of specifications can be confusing and lead to a lack of
 interoperability.  As a small example, here is section 6:

  6.  Acknowledgment

     Link-layer acknowledgment frames are built according to [IEEE802154].
     Unicast frames sent to a unicast MAC destination address MUST request
     an acknowledgment.  The sender node MUST set the ACK requested bit in
     the MAC header.  The acknowledgment frame is of type ACK (frame type
     value 0b010).  Each acknowledgment contains the following IE:

         ACK/NACK Time Correction IE: The ACK/NACK time correction IE
         carries the measured de-synchronization between the sender and the
         receiver.  Refer to Section 11.3 for an example of the Header IE
         content.  The possible values for the Time Synchronization
         Information and ACK status are described in [IEEE802154].

 Out of that section, it seems to me that the first sentence is harmless,
 the second sentence is a specification for this document, the third and
 fourth sentences are a restatement of [IEEE802154] and the fifth sentence
 is an inferred specification for this document.  The description of the IE
 is a restatement of [IEEE802154].

 Section 6 could be rewritten as:

  6. Acknowledgement frames

     Unicast frames sent to a unicast MAC destination address MUST request
     an acknowledgment.  Each acknowledgment MUST contain an ACK/NACK
     Time Correction IE.

 4. Default behavior versus learned behavior

 Which of the configuration and operational specifications in this document
 must be pre-configured before a node joins the network, and which are
 learned through, e.g., EBs.  Are operational control and management
 questions out of scope for this document, such as:

  - when does a node switch from the "minimal 6TiSCH configuration" to
    some other configuration?
  - does a node use the configuration parameters it has received
    through EBs to generate its own EBs or does it use the "minimal
    6TiSCH configuration" parameters?

 5. In this text from the Introduction, does "synchronizes with the
 network" mean time synchronization or something else:

   [...] when a node synchronizes to the network.

 6. I don't think the last sentence of the Introduction is relevant to an
 Introduction.

 7. The document could use a section on the terminology used in the
 document, to provide definitive sources for definitions of the various
 terms and acronyms used in the document.  Most likely, the terminology
 section would simply point to relevant sections of [IEEE802154] and [I-D
 .ietf-6tisch-terminology].

 8. Section 11 should be an Appendix, rather than part of the body of the
 document, so as to avoid making those examples normative standards text.

 9. I think the contents of section 7.1 are entirely dependent on the
 specifics of an implementation and the section should be omitted.

 10. I think the information in section 8 would be more generally useful if
 not stated in terms of a queue-based implementation:

  A node must not transmit frames containing higher-layer packets  until
 the node has successfully joined a network.

  Frame types BEACON and ACK

  Frames generated by the IEEE 802.15.4 layer are transmitted before
 frames containing higher-layer packets.

 11. According to [I-D.ietf-6tisch-terminology], the correct term is
 "timeslot", so s/time slot/timeslot/ throughout the document.

 12. In the table at the top of page 4 (BTW, please number and add a title
 to all tables), are the listed properties the only properties that have
 numeric or short text string values?  If not, all of those properties
 should be gathered together into a single table.  As an editorial aside,
 this table is pretty much what I expected to be the bulk of this document.

 13. Even if the number of timeslots in a slotframe is variable for this
 minimal configuration, should there be a default?

 14. In the table at the top of page 5, what do the empty boxes represent?

 15. The last sentence of section 3.2 seems to be a low-level
 implementation detail that can be omitted.

 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll
 suggest that almost all of section 3.4 is a restatement of the IEEE
 802.15.4 spec.  The last sentence is important, and isn't entirely clear.
 It would be clearer to write:

   For the minimal configuration specified in this document, the use
   of CCA is OPTIONAL.

 17. End of section 3 - not clear when to use macTimeslotTemplate.

 18. The third paragraph of section 4 is completely unclear to me:

   A Node aiming to join the network by receving a properly formed
   BEACON shall enter in a scan phase and shall store the value of
   macPANId and then set it to 0xffff for the duration of the scan in
   order to meet the filtering rules in [IEEE802154].

 What are "macPANId" and "scan phase"?  I don't see those terms used
 anywhere else in this document; do the terms come from the IEEE
 802.15.4 specs?  Why would an implementation store the value of macPANId
 and then set it to 0xffff?

 19. Does "synchronization" in section 5 mean "time synchronization"?

 20. In section 5, is "EB_PERIOD" the same value as defined in the table in
 section 10.2.4 that defines "RPL-related variables"?  If so, I don't
 understand why "EB_PERIOD" is in that table, as it only appears once in
 the rest of the document in section 5.

 21. I see that section 10 includes the statement:

   Nodes in a multihop network MUST use the RPL routing protocol
   [RFC6550].

 This statement is certainly false if one takes a broad definition of the
 word "multihop".  Even if edited to "multilink subnet" or "mesh", I can't
 find any support in RFC 6550 for the statement "MUST use RPL routing
 protocol".  I think it would be much clearer and more correct to quote
 verbatim the text describing this requirement from RFC 6550 rather than
 paraphrasing it here.

 Similarly, this sentence in section 10.1 needs, at least, to be edited,
 and I think it should be replaced with quoted text from RFC 6552.

   Nodes in the multihop network MUST implement the RPL Objective
   Function Zero [RFC6552].

 While I haven't provided a detailed review of the remainder of section
 10 because I don't think it's necessary for the goals of this document, it
 appears to me that much of section 10 is a restatement of the RPL
 specification from RFC 6550 and should, therefore, be omitted (if RPL is
 retained as a part of this recommendation).

-- 
--------------------------------+--------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:  milestone1
Component:  architecture        |    Version:  1.0
 Severity:  Active WG Document  |   Keywords:
--------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/39>
6tisch <http://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 26 Nov 2015 14:35:33 -0000

Description changed by [email-masked]:

Old description:

> Summary: In my opinion, the WG needs to reconsider some of the
> fundamental aspects of this proposed specification, and the document
> needs significant restructuring and editing.  I will be happy to work
> with the WG to revise the document and review future revisions.
>
> the document as a whole, while the remainder address more specific
> issues, roughly in the order of appearance in the document.
>
> Has the WG considered reorganizing the 6TiSCH protocol suite and
> documents to separate the minimal operation of IEEE 802.15.4 TSCH from
> is an inferred specification for this document.  The description of the
> IE is a restatement of [IEEE802154].
>
> Which of the configuration and operational specifications in this
> document must be pre-configured before a node joins the network, and
> which are learned through, e.g., EBs.  Are operational control and
> management questions out of scope for this document, such as:
>
> 10. I think the information in section 8 would be more generally useful
> if not stated in terms of a queue-based implementation:
>

> 20. In section 5, is "EB_PERIOD" the same value as defined in the table
> in section 10.2.4 that defines "RPL-related variables"?  If so, I don't
> 10 because I don't think it's necessary for the goals of this document,
> it appears to me that much of section 10 is a restatement of the RPL

New description:

 Subject: [Int-dir] Internet Directorate review of draft-ietf-6tisch-
 architecture-08.txt
 Date: Wed, 17 Jun 2015 11:04:08 -0400
 From: Ralph Droms <[email-masked]>
 To: [email-masked], <[email-masked]> <[email-masked]>
 CC: [email-masked],
 [email-masked], [email-masked]

 I am an assigned INT directorate reviewer for <draft-ietf-6tisch-
 architecture-08.txt>.  These comments were written primarily for the
 benefit of the Internet Area Directors. Document editors and shepherd(s)
 should treat these comments just like they would treat comments from any
 other IETF contributors and resolve them along with any other Last Call
 comments that have been received. For more details on the INT Directorate,
 see http://www.ietf.org/iesg/directorate.html.

 Summary
 -------
 This document is not ready for publication.  It needs to address several
 technical and editorial issues before publication.  In my opinion, the
 document:

 * misses the intent of an "architecture" document
 * mixes high-level architecture with more complete design or specification
 content
 * misses some architecture components
 * is incomplete and/or has been submitted for publication prior to
 completion of the architecture design

 Substantive/technical issues
 -----------------------------

 This document seems to be a work in progress.  There are several
 references to "first volume of the 6TiSCH architecture".  In my opinion,
 it should be possible to write a description of the architecture in a
 single document.  If not, then there should be a plan for what aspects of
 the architecture will go into other volumes.  This document can't be
 assessed for completeness without some overview of the entire
 architecture.  It might be that the WG would be better served by
 publishing the key components of this document in a more dynamic way, such
 as in a wiki, and then publish the final architecture when the component
 rotocols and specifications are complete.

 In my opinion, this document contains aspects of an architecture document,
 a requirements document and a design specification.  However, it is
 missing some key aspect of each kind of document.  For example, section 8
 gives what I consider to be a description of the communication paradigms
 that are part of the architecture.  The communication paradigms are
 described (for the most part) in the abstract, without specifying the
 design of how those paradigms are implemented.  Section 6, on the other
 hand, gives specific design details that would be better expressed in a
 design or specification document.  Similarly, section 10 specifies the
 current, preliminary design for the join process, rather than an
 architecture for security that describes all of the required security
 functions and how they relate to each other.

 Several key pieces of the design and architecture are missing.  While I
 understand that this is the "first volume" of a suite of architecture
 documents, it seems to me that decisions about:

 * How do applications interact with the network to request deterministic
 behavior of a datagram, a flow, a bundle of flows?
 * How does the network report back to an application in the case where the
 deterministic behavior can't be met, or in the case where the network
 status has changed and an existing reservation can no longer be met?
 * How is centralized track computation performed?
 * How will the PCE/NME interact with other, autonomous functions such as
 the routing protocol?  Or, will the PCE/NME control all forwarding?

 need to be made before decisions about the following can be made:

 * using a hierarchical multi-link subnet architecture
 * management protocols
 * routing protocols
 * scheduling protocols
 * fragment forwarding

 What, precisely, are the requirements?  I see this text:

    traffic that is highly sensitive to jitter, quite
    sensitive to latency, and with a high degree of operational
    criticality so that loss should be minimized at all times.

 What are the time scales for jitter and latency - nanoseconds,
 microseconds, milliseconds?  What are acceptable loss rates?  What are the
 tradeoffs between loss and jitter/latency?

 What are the requirements for mobility?  Do those requirements mandate the
 hierarchical multi-link subnet architecture?

 I'm not a security person, but it seems to me that relying solely on L2
 security as described in section 10 is inadequate.  The details of the
 join procedure belong in another document.

 Editorial issues
 ----------------
 I think the abstract should read something like:

    This document describes a network architecture that provides
    low-latency, low-jitter and high-reliability packet delivery.  It
    combines a high speed powered backbone and subnetworks using IEEE
    802.15.4 time-slotted channel hopping (TSCH) to meet the
    requirements of industrial deterministic applications.

 In general, try to avoid time-dependent references.  For example:

    TSCH was introduced with the IEEE802.15.4e
    [IEEE802154e] amendment and will be wrapped up in the next revision
    of the IEEE802.15.4 standard.

 only makes sense at the time the document is published.  Also try to avoid
 "new"; for example, change:

    At the same time, a new breed of Time Sensitive Networks is being
    developed to enable traffic that is highly sensitive to jitter, quite
    sensitive to latency, and with a high degree of operational
    criticality so that loss should be minimized at all times.

 to:

    Time Sensitive Networks enable traffic that is highly sensitive to
    jitter, quite sensitive to latency, and with a high degree of
    operational criticality so that loss should be minimized at all
    times.

 What is the "different time scale" for TSN and TSCH?  The document gives
 no sense about the relative requirements and operational characteristics
 of TSN and TSCH.

 Explain in the Introduction (if I have this right) that the 6tisch
 architecture uses route computation to allocate and schedule cells to
 IPv6 packets.

 Rather than go into detail, for example, about using routing protocols to
 distribute ND registrations, explain that the multi-link subnet
 architecture requires extensions to NDP because not all hosts in a subnet
 can communicate with each other directly.

 I can't find the term "mote" anywhere else in the document, nor is it a
 widely used term, so the parenthetical "(also called motes)" is unneeded.

 I think the reference to 6tisch-terminology should come first in section
 2.  It took me a while to discover the importance of that document in
 understanding this architecture document.

 The citation of "Multi-link Subnet Support in IPv6"
 [I-D.ietf-ipv6-multilink-subnets] in the terminology section seems
 inappropriate, as the document expired 13 years ago and the concept was
 explicitly deprecated in RFC 4903.

 The overview in section 4 is helpful but provides some redundant details
 and leaves out some others.  In particular, what are the roles of the PCE
 and NME, and what communication is required among them and the various
 forwarding nodes to complete the schedule computation and distribute the
 schedules?  What are the architectural components of route computation and
 update?

 It would help the reader understand the motivation for the multi-volume
 architecture to move the first paragraph of section 5.1 to the
 Introduction.

 Can sections 3, 4 and 5 be merged?  They all appear to explain aspects of
 an overview of the architecture.

 - Ralph Droms
   [email-masked]

--

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:  milestone1
Component:  architecture        |     Version:  1.0
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/39#comment:1>
6tisch <http://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 26 Nov 2015 16:47:09 -0000

Changes (by [email-masked]):

 * status:  new => assigned

Comment:

 Dear all:

 I created issue 39 to address Ralph’s comments; The changes are quite
 extensive, but I tried to maintain the content to the level of 08.
 The result is already visible in https://bitbucket.org/6tisch/draft-ietf-
 6tisch-architecture/src/063a04bd273af1cc7e1ae67d0e26e8f9ef28b24c/draft-
 ietf-6tisch-architecture-09.txt?at=master
 And will be discussed tomorrow at the interim call per the published
 agenda.

 The proposed new structure looks like as; per Ralph’s suggestion I grouped
 sections 3, 4 and 5 into a high level architecture and actually made
 smaller more specific subsections:

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  High Level Architecture  . . . . . . . . . . . . . . . . . . .  4
      3.1.  6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . .  4
      3.2.  TSCH: A Deterministic MAC Layer  . . . . . . . . . . . . .  5
      3.3.  Scheduling TSCH  . . . . . . . . . . . . . . . . . . . . .  6
      3.4.  Routing and Forwarding Over TSCH . . . . . . . . . . . . .  8
      3.5.  A Non-Broadcast Multi-Access Radio Mesh Network  . . . . .  9
      3.6.  A Multi-Link Subnet Model  . . . . . . . . . . . . . . . . 11
      3.7.  Join Process and Registration  . . . . . . . . . . . . . . 12
     3.8.  Dependencies on Work In Progress . . . . . . . . . . . . . 12
    4.  Deeper Dive  . . . . . . . . . . . . . . . . . . . . . . . . . 14
      4.1.  6LoWPAN (and RPL)  . . . . . . . . . . . . . . . . . . . . 14
        4.1.1.  RPL Leaf Support in 6LoWPAN ND . . . . . . . . . . . . 14
        4.1.2.  RPL Root And 6LBR  . . . . . . . . . . . . . . . . . . 15
      4.2.  TSCH and 6top  . . . . . . . . . . . . . . . . . . . . . . 15
        4.2.1.  6top . . . . . . . . . . . . . . . . . . . . . . . . . 15
          4.2.1.1.  Hard Cells . . . . . . . . . . . . . . . . . . . . 16
          4.2.1.2.  Soft Cells . . . . . . . . . . . . . . . . . . . . 16
        4.2.2.  6top and RPL Objective Function operations . . . . . . 16
        4.2.3.  Network Synchronization  . . . . . . . . . . . . . . . 17
        4.2.4.  SlotFrames and Priorities  . . . . . . . . . . . . . . 18
        4.2.5.  Distributing the reservation of cells  . . . . . . . . 19
      4.3.  Communication Paradigms and Interaction Models . . . . . . 21
      4.4.  Schedule Management Mechanisms . . . . . . . . . . . . . . 22
        4.4.1.  Static Scheduling  . . . . . . . . . . . . . . . . . . 22
        4.4.2.  Neighbor-to-neighbor Scheduling  . . . . . . . . . . . 22
        4.4.3.  Remote Monitoring and Schedule Management  . . . . . . 23
        4.4.4.  Hop-by-hop Scheduling  . . . . . . . . . . . . . . . . 26
      4.5.  Forwarding Models  . . . . . . . . . . . . . . . . . . . . 26
        4.5.1.  Track Forwarding . . . . . . . . . . . . . . . . . . . 26
         4.5.1.1.  Transport Mode . . . . . . . . . . . . . . . . . . 28
          4.5.1.2.  Tunnel Mode  . . . . . . . . . . . . . . . . . . . 29
          4.5.1.3.  Tunnel Metadata  . . . . . . . . . . . . . . . . . 29
        4.5.2.  Fragment Forwarding  . . . . . . . . . . . . . . . . . 30
        4.5.3.  IPv6 Forwarding  . . . . . . . . . . . . . . . . . . . 31
      4.6.  Centralized vs. Distributed Routing  . . . . . . . . . . . 32
        4.6.1.  Packet Marking and Handling  . . . . . . . . . . . . . 32
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
      6.1.  Join Process Highlights  . . . . . . . . . . . . . . . . . 33
    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
      7.1.  Contributors . . . . . . . . . . . . . . . . . . . . . . . 35
      7.2.  Special Thanks . . . . . . . . . . . . . . . . . . . . . . 36
      7.3.  And Do not Forget  . . . . . . . . . . . . . . . . . . . . 36
    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 36

 More below:
 Summary
 -------

 > I read that the actionable is the below, for which the above is an
 introduction

 > I separated them now as section 3 and 4 and moved some text to adapt.

 > There is now a clearer section “3.8.  Dependencies on Work In Progress”.
 Text was added on the deterministic work.

 > I removed all references to volumes. The WG will withhold the document
 till is is complete or the WG aborts, whichever comes first.

 protocols and specifications are complete.
 > We are now following your recommendation, sections 3.3 and 3.4

 design of how those paradigms are implemented.
 > That text was expanded

 > The following table was added to clarify what works with what that was
 also a comment by Kris about the apparent combinatory expansion which is
 fact is not there):

 +---------------------+------------+-----------------------------------+
 |   Forwarding Model  |  Routing   |          Scheduling               |
 +=====================+============+===================================+
 |G-MPLS Track Fwrding |     PCE    |Remote Monitoring and Schedule Mgt |
 +---------------------+------------+-----------------------------------+
 |                     |            |   Static (Minimal Configuration)  |
 +  classical IPv6     +     RPL    +-----------------------------------+
 |         /           |            |   Neighbor-to-Neighbor (SF0)      |
 + 6LoWPAN Fragment F. +------------+-----------------------------------+
 |                     |Reactive P2P|        Hop-by-Hop (TBD)           |
 +---------------------+------------+-----------------------------------+

 Section 6, on the other hand, gives specific design details that would be
 better expressed in a design or specification document.
 > I removed the text that looked like requirement or design (regarding 6lo
 which is now handling it) and pointed at the 6BBR draft that is pending
 adoption.

 Similarly, section 10 specifies the current, preliminary design for the
 join process, rather than an architecture for security that describes all
 of the required security functions and how they relate to each other.
 > That we still have to work out as a WG but we are chartering for it.

 > Clarified relation with the detnet work and provided details in “4.4.3.
 Remote Monitoring and Schedule Management”. Note that there are
 indeterminations so I can only state expectations or goals.
   With respect to Centralized routing and scheduling, the 6TiSCH
   Architecture is (expected to be) be an extension of the detnet work
    Deterministic Networking Architecture [I-D.finn-detnet-architecture],
 > Also added a general architecture picture inherited from RFC 7426

 > these are agreements that the group made over the last 2 years, and the
 architecture tracked. Mostly cast in stone by now, but for the fragment
 thing that is still an open issue with 6lo.

 > I agree that text about that would be informative. Typical control loops
 are in the order of a second, but a tight schedule could run down to a few
 Hundredths of seconds if energy is not an issue. Actual numbers for the
 process control industry are given in section 2.1 of
 https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-
 applicability-02 which is referenced. Should we have more in this
 particular document?

 > I agree that text about that would be informative there too. There is
 usually no physical mobility in the classical sense, at least when
 deterministic scheduling is involved. But the radio conditions may make it
 so that a device reparents elsewhere, ending up attached to a different
 backbone router. There’s also the case of a fully machine that is moved
 elsewhere and reconnects. So the answer is yes. But note that the RPL mesh
 is NBMA so already a multilink subnet though homogeneous.

 >We’ll be working on it with the new charter but I cannot contribute text
 at this point. We have great discussion on the ML though.

 Editorial issues
 ----------------

 > OK but for “industrial” which is not the scope for 6TiSCH. What about
 “   requirements of LowPower wireless deterministic applications.” ?

 only makes sense at the time the document is published.
 > OK the sentence now reads

                                                   TSCH was initially
 introduced with the
 IEEE802.15.4e amendment [IEEE802154e]of the IEEE802.15.4 standard
 and constituted a part of the standard from that day

 Also try to avoid "new"; for example, change:
 > removed all irrelevant occurences of “new”

 to:

 > adopted as is

 > added “several orders of magnitude”. 6TiSCH subdivises the line rate
 that is originally at 128kbps so we can end up with an effective rate in
 kbps, compared to the Ethernet that is typically deployed at 100Mbps but
 could run faster. Control loops are operated 2 to 3 orders of magnitude
 faster on Ethernet. These are really different worlds and different
 applications, but a determiitsic Ethernet backbone may be use to federate
 a 6TiSCH network.

 Explain in the Introduction (if I have this right) that the 6tisch
 architecture uses route computation to allocate and schedule cells to IPv6
 packets.
 > Unsure of the expected wording. We have routing and sceduling. In the
 Neighbor-to-Neighbor scheduling case, (SF0) Routing will cause traffic to
 follow certain routes, and dynamic scheduling will adapt the number of
 time slots. In the Remote Monitoring and Schedule Management case, the PCE
 is aware of a flows and creates a Track with timeslots that can serve
 those flows.

 > added:
          6TiSCH nodes are not necessarily reachable from one another at
 Layer-2
          and an LLN may span over multiple links. This effectively forms
 an
          homogeneous non-broadcast multi-access (NBMA) subnet, which is
 beyond
          the scope of existing IPv6 ND methods. Extensions to IPv6 ND have
 to be
          introduced.

 > no more mote

 > done

 The citation of "Multi-link Subnet Support in IPv6" [I-D.ietf-ipv6
 -multilink-subnets] in the terminology section seems inappropriate, as the
 document expired 13 years ago and the concept was explicitly deprecated in
 RFC 4903.
 > removed that reference; that was a kudos to the original work which may
 not work in general but can still find applicability such as here.

 > This is being refined. The abstract components are not preented in more
 details in section “4.4.3.  Remote Monitoring and Schedule Management”

 > Abandonned the multi volume approach

 > done

 Thanks a lot Ralph!

 Pascal

     Type:  defect              |      Status:  assigned

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/39#comment:2>
6tisch <http://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e