Subject: [6tisch] RtgDir review: draft-ietf-6tisch-architecture-21.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 21 Jun 2019 17:28:06 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-6tisch-architecture-21.txt
Reviewer: Andy Malis
Review Date: 21 June 2019
IETF LC End Date: 26 June 2019
Intended Status: Informational

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.

Overall comments:

For this review, I was asked to "Focus on the impact/implications of the
architecture on routing/forwarding." I will leave minor details such as
editorial nits to others.

This is a very long and detailed document, and I have no prior experience
with IEEE 802.15.4, 6lowpan, 6tisch, RPL, and related technologies. To
prepare for this review I did some basic background reading, such an online
introduction to IEEE 802.15.4 and RFC 7554. So in this review, I really
don't feel competent to comments on some of the more technical aspects
related to those technologies. However, I do feel competent to comment from
the viewpoint of a naive reader with a general background in routing. As a
naive reader, I appreciated the introduction to the technology in sections
1-3.

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.

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.

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.

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.

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.

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 22 Jun 2019 12:16:55 -0400

One quick follow-up to my review - I just noticed that while the draft's
intended status (in the draft) is Informational, the Datatracker lists it
as Proposed Standard. The Datatracker should be updated.

Thanks,
Andy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 22 Jun 2019 16:37:24 +0000

Hello Andrew:

This is another change with Gorry’s review.
The spec was intended to follow the path of the DetNet architecture as ses track but we’ll follow the A-Ds and the message was to shoot for informational. So we just changed for it.

Regards,

Pascal

Le 22 juin 2019 à 18:17, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> a écrit :

One quick follow-up to my review - I just noticed that while the draft's intended status (in the draft) is Informational, the Datatracker lists it as Proposed Standard. The Datatracker should be updated.

Thanks,
Andy

On Fri, Jun 21, 2019 at 5:28 PM Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Summary:

I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Overall comments:

For this review, I was asked to "Focus on the impact/implications of the architecture on routing/forwarding." I will leave minor details such as editorial nits to others.

This is a very long and detailed document, and I have no prior experience with IEEE 802.15.4, 6lowpan, 6tisch, RPL, and related technologies. To prepare for this review I did some basic background reading, such an online introduction to IEEE 802.15.4 and RFC 7554. So in this review, I really don't feel competent to comments on some of the more technical aspects related to those technologies. However, I do feel competent to comment from the viewpoint of a naive reader with a general background in routing. As a naive reader, I appreciated the introduction to the technology in sections 1-3.

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.

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.

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.

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.

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.

Thanks,
Andy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 22 Jun 2019 16:35:13 +0000

Hello Andrew

Many thanks for the huge investment of time you spent on our technology. I hope you found the context of interest.

Gory provided a similar feedback and I published 21 to address the specific point of references. Some were removed, some are now WG docs that were not, and the language was clarified to indicate some references are given as examples of how a particular feature could be achieved.

Would you please pick 21 and reassess your main comment below in the light of that update ?

All the best,

Pascal

Thanks,
Andy

Summary:

Overall comments:

Major issues:

Minor issue:

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 22 Jun 2019 12:56:43 -0400

Pascal,

I did review 21.

Cheers,
Andy

On Sat, Jun 22, 2019 at 12:50 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Gory provided a similar feedback and I published 21 to address the
> specific point of references. Some were removed, some are now WG docs that
> were not, and the language was clarified to indicate some references are
> given as examples of how a particular feature could be achieved.
>
> Le 22 juin 2019 à 18:17, Andrew G. Malis <[email-masked]> a écrit :
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jun 2019 08:24:14 +0000

Hello Andrew:

Many thanks for your in-depth review.

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

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

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

Major issues:

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

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

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

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

<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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 24 Jun 2019 08:40:01 -0400

Pascal,

On Mon, Jun 24, 2019 at 4:24 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

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

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

Thanks.

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

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

Cheers,
Andy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jun 2019 12:50:20 +0000

Hello Andrew

Please see below

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

Pascal,

On Mon, Jun 24, 2019 at 4:24 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Andrew:

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.

Thanks.

Major issues:

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

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:

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