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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Dear Pascal,


> On Mar 1, 2019, at 1:29 PM, Pascal Thubert (pthubert) <[e-mail]> 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 <[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 : )

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