[Int-dir] Intdir early review of draft-ietf-6tisch-architecture-19

[Carlos Pignataro <[e-mail]>]

Reviewer: Carlos Pignataro
Review result: On the Right Track

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