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

"Andrew G. Malis" <> Sat, 22 June 2019 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9687512003F; Sat, 22 Jun 2019 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pWjf-d7xyJu5; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E0A5120020; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
Received: by with SMTP id p15so10255750qtl.3; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EIEa31Iqzi838EfaOC/k/+BnTY42ewi5zNfawRzrpzU=; b=l5V57jwXJSYhvqVBEgnPcShSzEwPXel+x9a6zaAWcfXrVzhdo0ngoD5kT0MdUL5G7f WWgeDiEyssjEcBw61ss+a15+2CEsW4/o+SA18xK52ZxzQFLjclOAXfAIExbz7gLLSh/B j4NDV96IMbtrqNsEPuDRBxy9YL564xa15mZXSBsqozcjqX55q5qfB6UPbJ7GDLhQgGH4 /YU+KSTI7/CNrKKe9KZmxCX0WyBuLjbqohqMuQTDSz8KecaNdlmoQXN6dsZlNN+Xs1p9 VYG56NKnkcq2d05kQSlQzXwFN8REVcsJPn7pBuW1f7dFe6aAWLwGXJk9WTzuzT3Yr3Y7 xq5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EIEa31Iqzi838EfaOC/k/+BnTY42ewi5zNfawRzrpzU=; b=dYEjpWAjy+uGDuuMsA/qqrOuyvp9KWuf8ilsoCCDXvDFUQ7cnIo/oDixSvcAj3CmuT /P6NkPgakw0lbHVzHQSsJfNc+vQUxn00ugD6l43UAkMnXgpQZEawdnv9keDf28qaCgCV NbC0qZFKK4d26JnEfhuqir2dFc5DLrt8ABEkMMKNj9Far2Rww4OicnYVqoiINBX+GJqJ LeS4q55r5nCOZqmsHgdmBdk8o4ycWYHpbCWsvGURXVfcGeVP99UpxgtChJJgCe2NkXPU K/qU2/X0Gptg1GY6Kt5WVGduQ0k4igbZLfEFwhcp6pbufMC6aNoHzwKfldpxAeCtViek LGrQ==
X-Gm-Message-State: APjAAAWxAp7ugstKiXnllOL07vNiCnZVw4bD+zzfmoSz9ZWA9PBbu3Eo ndBglC0sSZDWJZmiKKvggkObbq6fw+SFRnZSlf4=
X-Google-Smtp-Source: APXvYqxKhvCZsWgv8faHhSWSdbJt9BUt5VY0vvh5YEhaWbDG49zQPP0rFUrd9db6i4E4NpF9S1EuBO1plIdJh7mW2rU=
X-Received: by 2002:ac8:3742:: with SMTP id p2mr113588497qtb.121.1561222614668; Sat, 22 Jun 2019 09:56:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: "Andrew G. Malis" <>
Date: Sat, 22 Jun 2019 12:56:43 -0400
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>
Cc: "<>" <>, "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000005cd9a9058bec77f3"
Archived-At: <>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-architecture-21.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Jun 2019 16:56:59 -0000


I did review 21.


On Sat, Jun 22, 2019 at 12:50 PM Pascal Thubert (pthubert) <> wrote:

> 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
> Le 22 juin 2019 à 18:17, Andrew G. Malis <> 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 <> 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
>> 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