Early Review of draft-ietf-6tisch-architecture-19
review-ietf-6tisch-architecture-19-intdir-early-pignataro-2019-02-20-00

Request Review of draft-ietf-6tisch-architecture
Requested rev. no specific revision (document currently at 28)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2019-02-22
Requested 2019-02-06
Requested by Suresh Krishnan
Authors Pascal Thubert
Draft last updated 2019-02-20
Completed reviews Intdir Early review of -19 by Carlos Pignataro (diff)
Iotdir Early review of -19 by Eliot Lear (diff)
Rtgdir Last Call review of -21 by Andrew Malis (diff)
Tsvart Last Call review of -20 by Gorry Fairhurst (diff)
Genart Last Call review of -20 by Francis Dupont (diff)
Secdir Last Call review of -21 by David Mandelberg (diff)
Opsdir Last Call review of -22 by Qin Wu (diff)
Secdir Telechat review of -24 by David Mandelberg (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Review review-ietf-6tisch-architecture-19-intdir-early-pignataro-2019-02-20
Reviewed rev. 19 (document currently at 28)
Review result On the Right Track
Review completed: 2019-02-20

Review
review-ietf-6tisch-architecture-19-intdir-early-pignataro-2019-02-20

Reviewer: Carlos Pignataro
Review result: On the Right Track -- Has (Minor) Issues

I am an assigned INT directorate reviewer for <draft-ietf-6tisch-architecture-19>. 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 https://datatracker.ietf.org/group/intdir/about/


This is a fairly thick document to read and hard to digest.

The architectural descriptions are sensible, useful, and distilled to a meaningful and minimal set of building blocks. The fact that some blocks are scattered through various sources and his architecture acts as the confluence point adds in the difficulty in parsing.

This amounts, in my humble opinion, to an opportunity to improve the document in a couple of areas:
1. There are specific depictions that would immensely improve clarity.
2. THere is an opportunity to rearrange a bit the structure of the doc, slightly.

Specifically:

The Introduction is very useful. However, the first Figure in the document is a protocol stack -- instead, a reference topo, model, or architecture might help make it real.

The Terminology section is very fragmented. If terms are used within an architecture, does it matter where they come from in such a harshly demarcated way? Why many subsections of terminology?

An Architecture is more than a stack. However, Section 3 "HL Arch" starts with Section 3.1, "Stack". Before a protocol, a System view and block interaction can flow into a protocol spec -- but the other way around seems inverse.

Section 3.4 (and Section 3.3) specifically would greatly benefit from depictions of the different Forwarding + Routing models, with PCE, with RPL, etc. A view of the neighbor-to-neighbor versus a Cenrtalized model would help, in my visual-person opinion.

Section 3.7 onwards does not seem to belong in a "High Level Architecture" with detailed protocol flows and interactions.

4.7.  Distributed vs. Centralized Routing

This seems to be a High-Level architectural distinction. SHould be in Section 3.something?

4.7.3.  Differentiated Services Per-Hop-Behavior

Is there a need to include and explain ECN for Tunneling?

Appendix A.  Dependencies on Work In Progress

What is the plan for this Appendix, as it seems appropriate for an I-D but less so for a forever inmutable RFC.


Minor and Nits:

2.1.  BCP 14

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.


The document contains this boilerplate text and citations / references to RFC 2119 and RFC 8174. However, it does not use any RFC 2119 keywords. 

The non-use of RFC 2119 keywords is appropriate given the type of architectural document this is, and thus suggest removing Section 2.1 and included / associated References.


2.3.  References

   The draft uses domain-specific terminology defined or referenced in:


I would re-title Section 2.3. It is not "References". Something like "Terminology from other Documents".



Super Editorials for Consideration:

Abstract

   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

s/high speed/high-speed/


   TSCH:       A medium access mode of the IEEE Std 802.15.4
               [IEEE802154] standard which uses time synchronization to
               achieve ultra low-power operation, and channel hopping to

s/ultra low-power/ultra-low-power/


   An overview of the the initial steps of a device in a network can be
   found in Section 3.7; the security aspects of the join process are
   further detailed in Section 6.

s/the the/the/

   slotframes that repeat over and over.  Slotframes may collide and
   require a device to wake up at a same time, in which case a the
   slotframe with the highest priority is actually activated.


s/a the/the/

      [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to
      add, update and remove cells in its own, and its peers schedules

s/peers schedules/peers' schedules/


   Within that subnet, neighbor devices are discovered with extended
   6LoWPAN Neighbor Discovery [RFC8505] (6LoWPAN ND), whereas RPL
   [RFC6550] enables routing in the so called Route Over fashion, either

s/so called/so-called/

   wired or wireless.  The backbone can be a classical IPv6 network,
   with Neighbor Discovery operating as defined in [RFC4861] and
   [RFC4862].  This architecture requires work to standardize the the

s/the the/the/

   As detailed in Section 4.1 the 6LoWPAN ND 6LBR and the root of the
   RPL network need to share information about the devices that are
   learned through either protocol but not both.  One way af achieving

s/af achieving/of achieving/

   window of time is defined around the scheduled transmission where the
   medium must, as much as practcally feasible, be free of contending
   energy.

s/practcally/practically/

   whereby a RPL parent discovers a chunk that is not used in its
   interference domain (e.g lack of energy detected in reference cells

s/e\.g /e.g.,/

   With respect to Centralized routing and scheduling, it is envisionned
   that the related component of the 6TiSCH Architecture would be an

s/envisionned/envisioned/

   The architecture introduces the concept of a Track, which is a
   directed path from a source 6TiSCH node to oe or more destination(s)

s/to oe or/to one or/

   6TiSCH enables a mixed model of centralized routes and distributed
   routes.  Centralized routes can for example be computed by a entity

s/a entity/an entity/

   In the minimal setting defined in [I-D.ietf-6tisch-minimal-security],
   the authentication is requires a pre-shared key, based on which a

s/is requires/requires/

3.5.  A Non-Broadcast Multi-Access Radio Mesh Network

   A 6TiSCH network is an IPv6 [RFC8200] subnet which, in its basic
   configuration, is a single Low Power Lossy Network (LLN) operating
   over a synchronized TSCH-based mesh.

s/Low Power/Low-Power and/


Figure 10 does not have a Label/Title.

4.5.  On Tracks

What are "Tracks"?


4.6.1.3.  Tunnel Metadata

The term "Metadata" appears only 4 times in this long document, but it is really not adequatedly defined. 

   At the egress 6TiSCH router, the reverse operation occurs.  Based on
   metadata associated to the Track, the frame is passed to the
   appropriate Link-Layer with the destination MAC restored.

So there is a demux function using Metadata -- what kind?

Best,

Carlos Pignataro