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

["Andrew G. Malis" <[e-mail]>]

Pascal,

On Mon, Jun 24, 2019 at 4:24 AM Pascal Thubert (pthubert) <
[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.


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


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

Cheers,
Andy