Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-architecture-21.txt

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

Hello Andrew:

Many thanks for your in-depth review.

Please see below:



>  The primary editor of this draft is also active in the DetNet working group, and leverages the work being done there to support the work in this draft. The draft does reference some DetNet technologies that have not yet been completely specified to the point where they can be implemented such as PREOF (Packet Replication, Elimination and Ordering Functions), although such specifications are an expected deliverable in the DetNet WG. So a full implementation of this architecture may have to wait for the completion of the related DetNet specification work.

<PT> Very true. Note that 6TiSCH was not chartered to deliver specifications to implement the deterministic side of the architecture. We hope to form RAW to do that, and RAW would inherit from DetNet’s specifications that are on the works now. At the architecture level, the reference we need is the DetNet architecture that introduces PREOFs, not the specs. And as you know, the DetNet architecture will be RFC before this. So I guess we do not have an issue there but rather a clear order in which things will get done, do we?

> With respect to routing and forwarding, this draft builds upon the work already done in the 6lowpan WG, such as RPL for routing and 6lowpan header compression. It adds the necessary scheduling and time synchronization functions needed to support the TSCH aspects of IEEE 802.15.4, which is the point of this work. But other than these new aspects, routing and forwarding should continue to work to the extent that they work in the 6lowpan specifications. My one concern regarding IPv6 forwarding is the use of draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my major issues below for more on this concern.

<PT> That will be entirely removed, please see below.

Major issues:

--------------

I'm concerned with the number of references to individual drafts (even if informational) in a major architecture specification, since the rest of the work on this technology, including solution documents, will rest on the correctness and completeness of the architecture. If these references are essential, then I would recommend that publication of the architecture be delayed until it's more clear whether these individual drafts will be adopted by a WG, and any abandoned individual drafts be removed. Otherwise, how can a published architecture depend on unpublished, abandoned work? Speaking of which, I note that one of those referenced drafts, draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in over four years, and should either be removed or adopted by the 6tisch WG. Another, draft-thubert-bier-replication-elimination, hasn't been updated in over a year. Is it still alive? At least the remaining individual drafts have fairly recent updates.

<PT> Yes, the link to svshah-tsvwg-lln-diffserv-recommendations is not really used in the architecture, it’s more of a pointer to work that we thought years ago would happen at TSVWG and never did. DetNet never seemed to depend on it either. I should really have removed that link on my own in addition to the changes I did in reaction to Gorry’s review, it will be gone in -22. I’ll also remove what is section 4.8.3 in -21. Looking at the other non-WG doc references, I do not think that the same reasoning applies, but I’m happy to discuss that in more depth.

<PT> The other non-WG docs are given as an informational early sense of how things could be implemented. We have this “Architecture Components” (section 4) that goes deeper than the usual architecture docs (more like our section 3). This is because this architecture tracked the WG as it went (like a spiral design or an agile approach) as opposed to the traditional cascading design stages. So we had those references live as we went over the last 5 years, from which svshah-tsvwg-lln-diffserv-recommendations appears like a unfiltered leftover. Also, the architecture is really an IOT architecture, that positions work done in multiple IETF WGs and ensures the global consistency and completeness. We value the archiving of section 4 because it provides the missing link between the high level architecture and what the group actually worked on (e.g., 6P) or pushed to other WGs such as ROLL and 6lo to obtain that overall consistency that was really missing 5 years ago.

<PT> OTOH, the architecture does not depend on those informational references. e.g.,  selander-ace-cose-ecdhe : LAKE BoF is happening at IETF 105. The 6TiSCH zerotouch will depend on LAKE as indicated in the architecture, but the architecture itself does not. This is given as an indication of how zerotouch could be done. For all I know, Thread is working on their own zerotouch that must have an equivalent functionality and that may not be edhoc. Fine with me at the architecture level, the key is to describe the model and position it within the other components.

--------------

A related concern is that this draft specifically depends on work to be done elsewhere in and outside of the IETF that is currently unchartered (see section A.2). Many of the individual drafts discussed in the previous paragraph are referenced in this section. To the extent that 6tisch depends on this work for its own eventual success, the WG may wish to evaluate if there are alternative ways to have the necessary work completed, such as using an alternative solution or rechartering the WG to include necessary work that looks unlikely to happen elsewhere.

<PT> Agreed.

<PT>  6TiSCH as a WG is close to completion now, this is why we are publishing our blue print. We’ve produced the specs that we needed for IPv6 over TSCH as chartered. We’ve had interop tests during past IETFs, and then more formal plugtests under ETSI supervision. 6TiSCH as chartered does not depend on WIP for its success. But the IOT network that the 6TiSCH  architecture describes will need upcoming additions such as zerotouch and RAW for which we provided the architecture but not the implementation.

<PT> We looked at it and found that the work to be done inherits more from DetNet and CCAMP than it does from 6TiSCH. Also that the work should not be so specific to the TSCH MAC but could apply to .11ac/be or to URLLC. Bottom line

<PT> Note that the non-IETF ref (IEEE802.15.12) is not a dependency to get IPv6 over TSCH to work, since it already does. It is a note that the MAC may be evolving and that a 6TiSCH implementation could be impacted. In this case, the 6P protocol may be transferred to IEEE, which is a rare occasion we thought worth noting in appendix.

----------------------

Minor issue:

To the extent that this architecture makes use of centralized control mechanisms such as PCE, the security considerations should mention this dependency and perhaps have a short discussion of effects on the network if connectivity between the centralized controller and the network nodes is lost, either due to an outage or a deliberate attack, and how such effects could be mitigated.

<PT> Makes sense to me. The inheritance from DetNet applies to both the protection of the control path and of the time distribution, which I’m discussing with David in parallel.
Proposed text:
”
The operation of 6TiSCH Tracks inherits its high level operation from DetNet and is subject to the observations in section 5 of [ietf-detnet-architecture]. As discussed there, measures must be taken to protect the time synchronization, and for 6TiSCH this includes ensuring that the ASN, which is used for the computation of NONCE,  is not compromised. Also, the installation and maintenance of 6TiSCH Tracks depends in the availability of a controller with a PCE to compute and push them in the network. When that connectivity is lost, existing Tracks may continue to operate until the end of their lifetime, but cannot be removed or updated, and new Tracks cannot be installed. As with DetNet in general, the communication with the PCE must be secured and should be protected against DoS attacks, and the discussion on the security considerations defined for Abstraction and Control of Traffic Engineered Networks (ACTN) applies equally to 6TiSCH.
“

Again, many thanks for your time spent on helping us through. I hope it was worth the read!

Pascal