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

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

Return-Path: <agmalis@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9687512003F; Sat, 22 Jun 2019 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWjf-d7xyJu5; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0A5120020; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id p15so10255750qtl.3; Sat, 22 Jun 2019 09:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAA=duU12f2eqQZsOAkm_LVR63Y1AXgruokm=eH9MVz-+mPZ_jA@mail.gmail.com> <CAA=duU16Vz58oMerho4fSF+S=zfqu8W0qPG9e02psy7+a+T=ag@mail.gmail.com> <B4ADD6E2-5B52-43A1-952B-8BA6F4C8103E@cisco.com>
In-Reply-To: <B4ADD6E2-5B52-43A1-952B-8BA6F4C8103E@cisco.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Sat, 22 Jun 2019 12:56:43 -0400
Message-ID: <CAA=duU1aYPv2G3qOo_-RaJDtdLf7ZuQyRnBoOn2z1RchHkfp2w@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005cd9a9058bec77f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/B9xuLSuKBDQCUud2W-cyC4QFAsA>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-architecture-21.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jun 2019 16:56:59 -0000

Pascal,

I did review 21.

Cheers,
Andy


On Sat, Jun 22, 2019 at 12:50 PM Pascal Thubert (pthubert) <
pthubert@cisco.com> 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 <agmalis@gmail.com> 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 <agmalis@gmail.com> 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.
>>
>> 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
>>
>>