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 >> >>
- [RTG-DIR] RtgDir review: draft-ietf-6tisch-archit… Andrew G. Malis
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Andrew G. Malis
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Pascal Thubert (pthubert)
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Pascal Thubert (pthubert)
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Andrew G. Malis
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Pascal Thubert (pthubert)
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Andrew G. Malis
- Re: [RTG-DIR] RtgDir review: draft-ietf-6tisch-ar… Pascal Thubert (pthubert)