Re: [6tisch] Intdir early review of draft-ietf-6tisch-architecture-19

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Carlos:

Many thanks for your early review!

All the best,

Pascal

>   -----Original Message-----
>   From: Carlos Pignataro <[e-mail]>
>   Sent: jeudi 21 février 2019 03:35
>   To: [e-mail]
>   Cc: [e-mail]; [e-mail]; [e-mail]
>   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 : )

>   
>   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


>   
>   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

>   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

>   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.
"
>   
>   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.



>   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 ...
"



>   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"
>   
>      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.


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...


Pascal