Dear Pascal, > On Mar 1, 2019, at 1:29 PM, Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> wrote: > > Dear Carlos: > > Many thanks for your early review! Anytime, and with apologies for the delayed response! Please see inline, with an implicit Ack for the comments I skip. Many thanks for really considering the commends and provided actionable recommendations or appropriate push back! > > All the best, > > Pascal > >> -----Original Message----- >> From: Carlos Pignataro <cpignata@xxxxxxxxx> >> Sent: jeudi 21 février 2019 03:35 >> To: int-dir@xxxxxxxx >> Cc: 6tisch@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6tisch-architecture.all@xxxxxxxx >> Subject: Intdir early review of draft-ietf-6tisch-architecture-19 >> >> 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. > > Ack. This is one of the major products of the 6TISCH WG and covers 5+ years of existence. > This work reflects rounds of design, open source implementation and ETSI-backed plugtests. > The original intent was t ship it in phased volumes but we were discouraged to do so when we > tried. The bright side is an all-in-one documentation : ) :-) Ack > >> >> 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. > > Let's go! > >> >> 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. > > Hum... we could move sections 3.5 and 3.6 up; I'm afraid we are undoing a move I did for an early review (was that Ralph?) but I'm like you, I prefer the other way. > > The Toc Would look like this: > > 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12 > 3.1. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 12 > 3.2. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 13 > 3.3. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 15 > 3.4. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 15 > 3.5. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 17 > 3.6. Routing and Forwarding Over TSCH . . . . . . . . . . . . 19 > FWIW, I also much prefer this. > >> >> 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? >> > > Probably because: > - section 2 was mis named. I renamed to " Terms and References " > - we merged the full draft of 6TiSCH terminology in this to save IESG cycles. There are pros and cons obviously. > > After the rename, the result is as follows (after removing BCP 14 text as you an Eliot recommend). > > 2. Terms and References . . . . . . . . . . . . . . . . . . . . 4 > 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 > 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 11 Great! > >> 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. >> > > Yes this is now 3.4 > Thank you. >> 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 Centralized model would >> help, in my visual-person opinion. > > This depiction exists in section 4.5. Let me add a forward pointer. I concerned to repeat too much in a doc that is already thick. > >> >> Section 3.7 onwards does not seem to belong in a "High Level Architecture" >> with detailed protocol flows and interactions. > > Yes I'm moving this into section 4 as new section 4.2 > >> >> 4.7. Distributed vs. Centralized Routing >> >> This seems to be a High-Level architectural distinction. SHould be in Section >> 3.something? > > The influence of this is spread in all subsections of section 3. I moved text that was in section 4 up. > Also added text in the introduction to position that already once and for all, expanding existing text: > " > Centralized routing refers to a model where routes are computed and > resources are allocated from a central controller. This is > particularly helpful to schedule deterministic multi-hop > transmissions. Distributed is a concurrent model that relies in more > classical peer to peer protocols for TSCH resource allocation and > routing operations. > > The architecture defines mechanisms to establish and maintain routing > and scheduling in a centralized, distributed, or mixed fashion, for > use in multiple OT environments. It is applicable in particular to > highly scalable solutions such a Advance metering that leverage > distributed routing to address multipath over a large number of hops > and nodes. > “ Thank you again. >> >> 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. >> > > I understand, but then there are other places where we say 'at the time of this writing'. > Even if an RFC is immutable, it still holds a position on the flow of time and this appendix positions that. > I'm OK to remove it, It like to see what others say first. > > I follow your (collective) lead. > >> 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. >> > > Done. It may come back, there are id nits associated. > > >> 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. >> > > Done all of the above, many thanks!!! > >> 4.5. On Tracks >> >> What are "Tracks"? >> > > Yes the definition first. 4.6 is now: > > " > 4.6. On Tracks > > The architecture introduces the concept of a Track, which is a > directed path from a source 6TiSCH node to one or more destination(s) > 6TiSCH node(s) across a 6TiSCH LLN. > > A Track is the 6TiSCH instantiation of the concept of a Deterministic > Path as described in [I-D.ietf-detnet-architecture]. Constrained > resources such as memory buffers are reserved for that Track in > intermediate 6TiSCH nodes to avoid loss related to limited capacity. > A 6TiSCH node along a Track not only knows which bundles of cells it > should use to receive packets from a previous hop, but also knows > which bundle(s) it should use to send packets to its next hop along > the Track. > > 4.6.1. General Behavior of Tracks > > A Track is associated with Layer-2 bundles ... > " > > Super! > >> 4.6.1.3. Tunnel Metadata >> >> The term "Metadata" appears only 4 times in this long document, but it is >> really not adequatedly defined. > > Yes, I wonder why I used that term. Replaced with "tunneling information” That’s more descriptive. Thanks. >> >> 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? >> > > Added text, now looks like > > " > > At the egress 6TiSCH router, the reverse operation occurs. Based on > tunneling information of the Track, which may for instance indicate > that the tunneled datagram is an IP packet, the datagram is passed to > the appropriate Link-Layer with the destination MAC restored. > > 4.7.1.3. Tunneling Information > > Tunneling information coming with the Track configuration provides > the destination MAC address of the egress endpoint as well as the > tunnel mode and specific data depending on the mode, for instance a > service access point for frame delivery at egress. > > > " > > Many thanks Carlos! This was very dep and useful. Back at you. > > > I'm publishing a version 20 before cut off, I hope that it solves the issues that you raised to your satisfaction. > Please let me know… > Most definitely does. Best, — Carlos. > > Pascal > >
