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

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

Hello Andrew

Please see below

Le 24 juin 2019 à 14:40, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> a écrit :

Pascal,

On Mon, Jun 24, 2019 at 4:24 AM Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
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?

I wasn't aware that while deterministic delivery was in the architecture draft, it's not yet in the charter. Perhaps it should be made more explicit in the architecture. Right now, "deterministic" is everywhere in the draft, starting with the abstract.


Rightly so. The architecture was in the charter. We even had a data model chartered to configure tracks but we dropped the item. It was too early; even before DetNet formed. Instead some of us went in and helped form DetNet with a goal to inherit in a consistent way. Since we never rechartered for tracks. We feel that the RAW WG should do it.


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

Thanks.


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.

Of the other references, I'm most concerned about draft-thubert-bier-replication-elimination. It would be really good for both 6tisch and DetNet if you could work with the bier WG to get it active and adopted there.


Actually we are working on a RAW OAM spec and when published I could update the reference.


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

Very nice, thanks!


Good I’ll publish to make sure the next reviewers see those corrections. I also updated the data tracker status to informational.


Many thanks !

Pascal

Cheers,
Andy