Re: [6tisch] Intdir early review of draft-ietf-6tisch-architecture-19

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 26 March 2019 19:56 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E7120A51; Tue, 26 Mar 2019 12:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cKMY_BRe9Dyp; Tue, 26 Mar 2019 12:56:12 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D02D120846; Tue, 26 Mar 2019 12:56:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19394; q=dns/txt; s=iport; t=1553630172; x=1554839772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6YGHgValcgLw9hxtNliP/vjwzjuTBCDw3HejcxqOJC4=; b=QDnBTqcDi6qSyn3T5XRq8ZaYGS6MgV9Iwz6SY/VMko3MbNJ+cog2qunh pK8PoLmv/LITtQPffx6FKiflBqDkKRV84KBqN5qjELPp1CYNMzH2Xn6en nDrD4eaxI5GAmlmlVndXr0uW6aLEmenosJygBvtb3zaD7VQmYtuhW5bC/ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAB6g5pc/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgWYqaIEDFBMKhASVUH6XUYFnDQEBI4R?= =?us-ascii?q?JAheFCyI3Bg0BAQMBAQkBAwJtHAyFSgEBAQMBIxE8CQUHBAIBCBEBAwEBAQI?= =?us-ascii?q?CJgICAjAVAgYIAgQOBRuDBwGBbQgPrGSBL4oqBYELJAGLMReBQD+BEScfgU5?= =?us-ascii?q?JNT6CYQEBA4EmEQsbAYMKMYImA4oYEjKCFItoi2FgCQKHYYtYGYIChX2DTIg?= =?us-ascii?q?3jDSEb4o6gnICERWBLjUigVZwFRpLAYINATM+gVgXgQABB4dXhT9BMY11gS6?= =?us-ascii?q?BHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,274,1549929600"; d="scan'208";a="249640519"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 19:56:10 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QJuAfH016404 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 19:56:10 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 15:56:09 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 15:56:09 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: "int-dir@ietf.org" <int-dir@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>
Thread-Topic: Intdir early review of draft-ietf-6tisch-architecture-19
Thread-Index: AQHUyY4LRBL+Ij1ct0679Sdfs7u3I6X1SqnQgCmBMoA=
Date: Tue, 26 Mar 2019 19:56:09 +0000
Message-ID: <7F9A7A98-78F0-40D2-991A-3DD86F152822@cisco.com>
References: <155071649357.20269.3113753571607539612@ietfa.amsl.com> <BYAPR11MB3558777FC286CC869FF120A6D8760@BYAPR11MB3558.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3558777FC286CC869FF120A6D8760@BYAPR11MB3558.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.102.3)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8745AFBC9BE97346961D2B7B625EF89C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.156, xch-rtp-016.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/sh3QfBhcfmBM5tZuZUauJnKsXck>
Subject: Re: [6tisch] Intdir early review of draft-ietf-6tisch-architecture-19
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 19:56:16 -0000

Dear Pascal,


> On Mar 1, 2019, at 1:29 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Dear Carlos:
> 
> Many thanks for your early review!

Anytime, and with apologies for the delayed response!

Please see inline, with an implicit Ack for the comments I skip. Many thanks for really considering the commends and provided actionable recommendations or appropriate push back!

> 
> All the best,
> 
> Pascal
> 
>>  -----Original Message-----
>>  From: Carlos Pignataro <cpignata@cisco.com>
>>  Sent: jeudi 21 février 2019 03:35
>>  To: int-dir@ietf.org
>>  Cc: 6tisch@ietf.org; ietf@ietf.org; draft-ietf-6tisch-architecture.all@ietf.org
>>  Subject: Intdir early review of draft-ietf-6tisch-architecture-19
>> 
>>  Reviewer: Carlos Pignataro
>>  Review result: On the Right Track
>> 
>>  Reviewer: Carlos Pignataro
>>  Review result: On the Right Track -- Has (Minor) Issues
>> 
>>  I am an assigned INT directorate reviewer for <draft-ietf-6tisch-architecture-
>>  19>. These comments were written primarily for the benefit of the Internet
>>  Area Directors. Document editors and shepherd(s) should treat these
>>  comments just like they would treat comments from any other IETF
>>  contributors and resolve them along with any other Last Call comments that
>>  have been received. For more details on the INT Directorate, see
>>  https://datatracker.ietf.org/group/intdir/about/
>> 
>>  This is a fairly thick document to read and hard to digest.
> 
> Ack. This is one of the major products of the 6TISCH WG and covers 5+ years of existence.
> This work reflects rounds of design, open source implementation and ETSI-backed plugtests.
> The original intent was t ship it in phased volumes but we were discouraged to do so when we
> tried.  The bright side is an all-in-one documentation : )

:-) Ack 

> 
>> 
>>  The architectural descriptions are sensible, useful, and distilled to a
>>  meaningful and minimal set of building blocks. The fact that some blocks are
>>  scattered through various sources and his architecture acts as the confluence
>>  point adds in the difficulty in parsing.
>> 
>>  This amounts, in my humble opinion, to an opportunity to improve the
>>  document in a couple of areas: 1. There are specific depictions that would
>>  immensely improve clarity. 2. THere is an opportunity to rearrange a bit the
>>  structure of the doc, slightly.
> 
> Let's go!
> 
>> 
>>  Specifically:
>> 
>>  The Introduction is very useful. However, the first Figure in the document is a
>>  protocol stack -- instead, a reference topo, model, or architecture might help
>>  make it real.
> 
> Hum... we could move sections 3.5 and 3.6 up; I'm afraid we are undoing a move I did for an early review (was that Ralph?) but I'm like you, I prefer the other way.
> 
> The Toc Would look like this:
> 
> 3.  High Level Architecture . . . . . . . . . . . . . . . . . . .  12
>     3.1.  A Non-Broadcast Multi-Access Radio Mesh Network . . . . .  12
>     3.2.  A Multi-Link Subnet Model . . . . . . . . . . . . . . . .  13
>     3.3.  TSCH: A Deterministic MAC Layer . . . . . . . . . . . . .  15
>     3.4.  6TiSCH Stack  . . . . . . . . . . . . . . . . . . . . . .  15
>     3.5.  Scheduling TSCH . . . . . . . . . . . . . . . . . . . . .  17
>     3.6.  Routing and Forwarding Over TSCH  . . . . . . . . . . . .  19
> 

FWIW, I also much prefer this.

> 
>> 
>>  The Terminology section is very fragmented. If terms are used within an
>>  architecture, does it matter where they come from in such a harshly
>>  demarcated way? Why many subsections of terminology?
>> 
> 
> Probably because:
> - section 2 was mis named. I renamed to " Terms and References  "
> - we merged the full draft of 6TiSCH terminology in this to save IESG cycles. There are pros and cons obviously.
> 
> After the rename, the result is as follows (after removing BCP 14 text as you an Eliot recommend).
> 
> 2.  Terms and References  . . . . . . . . . . . . . . . . . . . .   4
>     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
>     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .  10
>     2.3.  References  . . . . . . . . . . . . . . . . . . . . . . .  11

Great!

> 
>>  An Architecture is more than a stack. However, Section 3 "HL Arch" starts
>>  with Section 3.1, "Stack". Before a protocol, a System view and block
>>  interaction can flow into a protocol spec -- but the other way around seems
>>  inverse.
>> 
> 
> Yes this is now 3.4
> 

Thank you.

>>  Section 3.4 (and Section 3.3) specifically would greatly benefit from
>>  depictions of the different Forwarding + Routing models, with PCE, with RPL,
>>  etc. A view of the neighbor-to-neighbor versus a Centralized model would
>>  help, in my visual-person opinion.
> 
> This depiction exists in section 4.5. Let me add a forward pointer. I concerned to repeat too much in a doc that is already thick.
> 
>> 
>>  Section 3.7 onwards does not seem to belong in a "High Level Architecture"
>>  with detailed protocol flows and interactions.
> 
> Yes I'm moving this into section 4 as new section 4.2
> 
>> 
>>  4.7.  Distributed vs. Centralized Routing
>> 
>>  This seems to be a High-Level architectural distinction. SHould be in Section
>>  3.something?
> 
> The influence of this is spread in all subsections of section 3. I moved text that was in section 4 up.
> Also added text in the introduction to position that already once and for all, expanding existing text:
> "
>   Centralized routing refers to a model where routes are computed and
>   resources are allocated from a central controller.  This is
>   particularly helpful to schedule deterministic multi-hop
>   transmissions.  Distributed is a concurrent model that relies in more
>   classical peer to peer protocols for TSCH resource allocation and
>   routing operations.
> 
>   The architecture defines mechanisms to establish and maintain routing
>   and scheduling in a centralized, distributed, or mixed fashion, for
>   use in multiple OT environments.  It is applicable in particular to
>   highly scalable solutions such a Advance metering that leverage
>   distributed routing to address multipath over a large number of hops
>   and nodes.
> “

Thank you again.

>> 
>>  4.7.3.  Differentiated Services Per-Hop-Behavior
>> 
>>  Is there a need to include and explain ECN for Tunneling?
>> 
>>  Appendix A.  Dependencies on Work In Progress
>> 
>>  What is the plan for this Appendix, as it seems appropriate for an I-D but less
>>  so for a forever inmutable RFC.
>> 
> 
> I understand, but then there are other places where we say 'at the time of this writing'.
> Even if an RFC is immutable, it still holds a position on the flow of time and this appendix positions that.
> I'm OK to remove it, It like to see what others say first.
> 
> 

I follow your (collective) lead.

> 
>>  Minor and Nits:
>> 
>>  2.1.  BCP 14
>> 
>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>  "MAY", and
>>     "OPTIONAL" in this document are to be interpreted as described in BCP
>>     14 [RFC2119][RFC8174] when, and only when, they appear in all
>>     capitals, as shown here.
>> 
>>  The document contains this boilerplate text and citations / references to RFC
>>  2119 and RFC 8174. However, it does not use any RFC 2119 keywords.
>> 
>>  The non-use of RFC 2119 keywords is appropriate given the type of
>>  architectural document this is, and thus suggest removing Section 2.1 and
>>  included / associated References.
>> 
> 
> Done. It may come back, there are id nits associated.
> 
> 
>>  2.3.  References
>> 
>>     The draft uses domain-specific terminology defined or referenced in:
>> 
>>  I would re-title Section 2.3. It is not "References". Something like
>>  "Terminology from other Documents".
>> 
>>  Super Editorials for Consideration:
>> 
>>  Abstract
>> 
>>     This document describes a network architecture that provides low-
>>     latency, low-jitter and high-reliability packet delivery.  It
>>     combines a high speed powered backbone and subnetworks using IEEE
>> 
>>  s/high speed/high-speed/
>> 
>>     TSCH:       A medium access mode of the IEEE Std 802.15.4
>>                 [IEEE802154] standard which uses time synchronization to
>>                 achieve ultra low-power operation, and channel hopping to
>> 
>>  s/ultra low-power/ultra-low-power/
>> 
>>     An overview of the the initial steps of a device in a network can be
>>     found in Section 3.7; the security aspects of the join process are
>>     further detailed in Section 6.
>> 
>>  s/the the/the/
>> 
>>     slotframes that repeat over and over.  Slotframes may collide and
>>     require a device to wake up at a same time, in which case a the
>>     slotframe with the highest priority is actually activated.
>> 
>>  s/a the/the/
>> 
>>        [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to
>>        add, update and remove cells in its own, and its peers schedules
>> 
>>  s/peers schedules/peers' schedules/
>> 
>>     Within that subnet, neighbor devices are discovered with extended
>>     6LoWPAN Neighbor Discovery [RFC8505] (6LoWPAN ND), whereas RPL
>>     [RFC6550] enables routing in the so called Route Over fashion, either
>> 
>>  s/so called/so-called/
>> 
>>     wired or wireless.  The backbone can be a classical IPv6 network,
>>     with Neighbor Discovery operating as defined in [RFC4861] and
>>     [RFC4862].  This architecture requires work to standardize the the
>> 
>>  s/the the/the/
>> 
>>     As detailed in Section 4.1 the 6LoWPAN ND 6LBR and the root of the
>>     RPL network need to share information about the devices that are
>>     learned through either protocol but not both.  One way af achieving
>> 
>>  s/af achieving/of achieving/
>> 
>>     window of time is defined around the scheduled transmission where the
>>     medium must, as much as practcally feasible, be free of contending
>>     energy.
>> 
>>  s/practcally/practically/
>> 
>>     whereby a RPL parent discovers a chunk that is not used in its
>>     interference domain (e.g lack of energy detected in reference cells
>> 
>>  s/e\.g /e.g.,/
>> 
>>     With respect to Centralized routing and scheduling, it is envisionned
>>     that the related component of the 6TiSCH Architecture would be an
>> 
>>  s/envisionned/envisioned/
>> 
>>     The architecture introduces the concept of a Track, which is a
>>     directed path from a source 6TiSCH node to oe or more destination(s)
>> 
>>  s/to oe or/to one or/
>> 
>>     6TiSCH enables a mixed model of centralized routes and distributed
>>     routes.  Centralized routes can for example be computed by a entity
>> 
>>  s/a entity/an entity/
>> 
>>     In the minimal setting defined in [I-D.ietf-6tisch-minimal-security],
>>     the authentication is requires a pre-shared key, based on which a
>> 
>>  s/is requires/requires/
>> 
>>  3.5.  A Non-Broadcast Multi-Access Radio Mesh Network
>> 
>>     A 6TiSCH network is an IPv6 [RFC8200] subnet which, in its basic
>>     configuration, is a single Low Power Lossy Network (LLN) operating
>>     over a synchronized TSCH-based mesh.
>> 
>>  s/Low Power/Low-Power and/
>> 
>>  Figure 10 does not have a Label/Title.
>> 
> 
> Done all of the above, many thanks!!!
> 
>>  4.5.  On Tracks
>> 
>>  What are "Tracks"?
>> 
> 
> Yes the definition first. 4.6 is now:
> 
> "
> 4.6.  On Tracks
> 
>   The architecture introduces the concept of a Track, which is a
>   directed path from a source 6TiSCH node to one or more destination(s)
>   6TiSCH node(s) across a 6TiSCH LLN.
> 
>   A Track is the 6TiSCH instantiation of the concept of a Deterministic
>   Path as described in [I-D.ietf-detnet-architecture].  Constrained
>   resources such as memory buffers are reserved for that Track in
>   intermediate 6TiSCH nodes to avoid loss related to limited capacity.
>   A 6TiSCH node along a Track not only knows which bundles of cells it
>   should use to receive packets from a previous hop, but also knows
>   which bundle(s) it should use to send packets to its next hop along
>   the Track.
> 
> 4.6.1.  General Behavior of Tracks
> 
>   A Track is associated with Layer-2 bundles ...
> "
> 
> 


Super!

> 
>>  4.6.1.3.  Tunnel Metadata
>> 
>>  The term "Metadata" appears only 4 times in this long document, but it is
>>  really not adequatedly defined.
> 
> Yes, I wonder why I used that term. Replaced with "tunneling information”

That’s more descriptive. Thanks.


>> 
>>     At the egress 6TiSCH router, the reverse operation occurs.  Based on
>>     metadata associated to the Track, the frame is passed to the
>>     appropriate Link-Layer with the destination MAC restored.
>> 
>>  So there is a demux function using Metadata -- what kind?
>> 
> 
> Added text, now looks like
> 
> "
> 
>   At the egress 6TiSCH router, the reverse operation occurs.  Based on
>   tunneling information of the Track, which may for instance indicate
>   that the tunneled datagram is an IP packet, the datagram is passed to
>   the appropriate Link-Layer with the destination MAC restored.
> 
> 4.7.1.3.  Tunneling Information
> 
>   Tunneling information coming with the Track configuration provides
>   the destination MAC address of the egress endpoint as well as the
>   tunnel mode and specific data depending on the mode, for instance a
>   service access point for frame delivery at egress.
> 
> 
> "
> 
> Many thanks Carlos! This was very dep and useful.

Back at you.

> 
> 
> I'm publishing a version 20 before cut off, I hope that it solves the issues that you raised to your satisfaction.
> Please let me know…
> 

Most definitely does.

Best,

— Carlos.


> 
> Pascal
> 
>