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
