Re: [Tsv-art] [6tisch] TSV-ART review of draft-ietf-6tisch-architecture

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 17 June 2019 14:58 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4F1200F5; Mon, 17 Jun 2019 07:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 header.b=JCKXrhjS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pDlfbDS0
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 u6ZjTC8fC6qr; Mon, 17 Jun 2019 07:58:54 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE74912013E; Mon, 17 Jun 2019 07:58:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44266; q=dns/txt; s=iport; t=1560783533; x=1561993133; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x8EHQQhP5rh0Dz9hFzwfDCoN0Jtvd5GbceHz4Y2MALM=; b=JCKXrhjSkPqIoCfnKQ4P82DcgUeb+bzN59bO6USrqzEr011uh8bMr49n zWp9tCBmfAJBXmJSLIlE1pkAxbleLXNJ5MFi+8Z60FQTX+F1Xnln3VU2Q SyuPbdg5kJOAAhCquEDTxmjfzOTdMkkQlKHlVOP2F30+4FHTiApv/f3KY I=;
IronPort-PHdr: 9a23:tQifvRGTQQp55TqDsMZBM51GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AnAADqqQdd/5RdJa1mDgwBAQEBAQIBAQEBBwIBAQEBgVQCAQEBAQsBgQ4vUANqVSAECyiHXQOOYYJXfpY4gUKBEANUCQEBAQwBASUIAgEBhEACgkwjNwYOAQMBAQQBAQIBBG0cDIVKAQEBAwEMBhUGEwEBKQ4BBAsCAQgSJgENMhcOAgQBDQ0TB4MBgR1NAw4PAQIMnT0CgTiIX4FvM4J5AQEFgTIBAwEQOwQBgnIYghAJgTQBhHCGbReBQD+BEUaCFzU+gj4jAQEBAoFCBBorgw+CJotwhz+ISo0CZAkCghCGSIReiEeCJ4cDBYl/hAKNGQSHIoxQgnECBAIEBQIOAQEFgWYigVhwFYJzAQEBMQmCBgkDF4NNJIFbgxWFBDtyAYEojE8rgiUBAQ
X-IronPort-AV: E=Sophos;i="5.63,385,1557187200"; d="scan'208,217";a="574066017"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2019 14:58:52 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x5HEwqC8031207 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jun 2019 14:58:52 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 09:58:51 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 09:58:51 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Jun 2019 10:58:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L5ak/swepMn0k1UvHdJnDy4KSvLlahGYb9yfGMHRb6o=; b=pDlfbDS0Uf9/xGhqa3ERGNjY4fCSc6LflAzAEsxSt6zRGAJkcXZmL3Q5NuYRdPkL/jKeSMAgpRxF4edDMDrGUnyGPkvbSQq54CqqebE6ckIJpZ1JZ15RAeXgQclcO2uooTT7YsCnJXe4BMg5K0P720/ZHR/yarGLEPlGZlX0F+c=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4399.namprd11.prod.outlook.com (52.135.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Mon, 17 Jun 2019 14:58:49 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 14:58:49 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: G Fairhurst <gorry@erg.abdn.ac.uk>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "6tisch@ietf.org" <6tisch@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>
Thread-Topic: [6tisch] TSV-ART review of draft-ietf-6tisch-architecture
Thread-Index: AQHVJN3U0rK160EY/Ean5Q77BjiWxKaf8DXQ
Date: Mon, 17 Jun 2019 14:58:37 +0000
Deferred-Delivery: Mon, 17 Jun 2019 14:58:24 +0000
Message-ID: <MN2PR11MB35650133F622DD26B64B349ED8EB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <5D06775E.1070407@erg.abdn.ac.uk>
In-Reply-To: <5D06775E.1070407@erg.abdn.ac.uk>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1001::c0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 38f5522b-fbc0-4e86-f513-08d6f3344e49
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4399;
x-ms-traffictypediagnostic: MN2PR11MB4399:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <MN2PR11MB4399183174D95A0CDBD2B2F7D8EB0@MN2PR11MB4399.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0071BFA85B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(376002)(396003)(346002)(129504002)(199004)(189003)(81166006)(6666004)(236005)(66574012)(8676002)(71200400001)(71190400001)(6116002)(790700001)(561944003)(33656002)(606006)(2906002)(8936002)(478600001)(6436002)(81156014)(4326008)(68736007)(229853002)(55016002)(74316002)(25786009)(7736002)(86362001)(76176011)(46003)(446003)(99286004)(966005)(6506007)(2501003)(14454004)(52536014)(66556008)(64756008)(66446008)(102836004)(66476007)(76116006)(21615005)(54906003)(486006)(476003)(316002)(296002)(256004)(14444005)(186003)(54896002)(110136005)(7696005)(53936002)(6246003)(11346002)(6306002)(9686003)(5660300002)(66946007)(73956011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4399; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 71ufNJbtzjq75gsCa1+VpCKMZ7ZCUv6khN9WrCWbIGWBgi/iNoaB/AVfg293Ycg4kdX7kP0IeRdcig1TlsaQqovjlXRN46sqZ4qNvljnEavpX1nxq+Ij125roxxXKMeZG7WwAhKOGjr18qOgfac+/Qkou2m0aMT5X8HKSYWAevlGlvuqB21SOKLMp6Lwnm7+/CnuLxIV22E3Axx3sOZucfRJ5E4G+i37XaFU6LgyJPIxgyOFam15RSc1vfJVAlR+9Ms/IMdo/R6PdPG02KCpkOoCXJ8ZtSyb5HF158HGm9mHULN9Iq48bzxdiIopQRwxhmWnOB9ePuEaUg8G03KGa0Wb2wyGbkE8Ah0ElmRyPqduhTbz8aknvIJ/WweaQPIRIzBOXa18vAFopfHkceLd6URNbviAgaLR2sysTAVLvWY=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35650133F622DD26B64B349ED8EB0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 38f5522b-fbc0-4e86-f513-08d6f3344e49
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 14:58:49.5553 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4399
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/VY_j9KoZqaKMl_CKYw_Cwi2SHoQ>
Subject: Re: [Tsv-art] [6tisch] TSV-ART review of draft-ietf-6tisch-architecture
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2019 14:58:59 -0000

Hello Gorry:



Many thanks for your review, this is much appreciated.



Please see below



> Intended status

> -------------

>

> The document is proposed with standards track status, but appears to mainly

> provide informational background about the architecture. There are no

> normative requirements made. This could be published as informational.



It was originally intended informational. The discussion for the DetNet architecture lead to a different track because of external visibility - this spec is highly related to IEEE work.

As editor I'm agnostic, up to the A-Ds and I'll respect their decision.



>

> * Use of References:

>

> I suggest someone checks the presence of a large body of informative

> references to current working group documents - rather than normative

> citation of the published work.

> I am concerned about citing individual work in progress within the body of the

> document:

>

> Final para of Section 3.1 makes a reference to an individual draft that appears

> to target the ROLL WG.

>



This one is already solved: draft-thubert-roll-unaware-leaves is now https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves .

It is a rather simple draft since it is the IGP counterpart of RFC 8505 but really important for low power nodes that will not need to support RPL.





> Section 3.2 makes reference to an individual draft to describe multicast

> [ID.thubert...] Section 4.1.1 makes a reference to an individual draft that

> appears to target the ROLL WG, mentioned twice as defining something,

> Section 4.1.1 makes a reference to an individual draft that appears to target

> the ROLL WG.

>



[I-D.thubert-6lo-unicast-lookup] is an optimization. I cannot fathom its success as RFC. But it is interesting as an architectural construct.

Explaining that what this draft does is an architectural possibility is of interest in an architecture document, feels incomplete to ignore it.

Note that the feature ships using non-standard methods (e.g., derived from LISP). I'd rather cite an open document, be it a draft.

The bottom line is that 6TiSCH has been trying to build a complete architecture and doing so, found overlaps and gaps between existing RFCs.

We started a number of document in several WGs and int and rtg and working hand in hand with experts in others e.g., sec.

Some of those documents are RFCs, e.g., 8505. Others passed WGLC like the backbone router and AP ND that are cited in this spec.

This one is only in inception but still addresses a gap that must be discussed in the architecture.

Maybe I could rephrase from:



"

   A 6LBR located on the backbone may contribute to Duplicate Address

   Detection as well as Address Lookup and save multicast operations

   [I-D.thubert-6lo-unicast-lookup].

"



To



"



    The use of multicast can also be reduced on the backbone with an optional

    registrar that would contribute to Duplicate Address Detection as well as

    Address Lookup using only unicast request/response exchanges.

    <xref target="I-D.thubert-6lo-unicast-lookup"/> provides an example of how

    that can be achieved with an extension of <xref target="RFC8505"/>, using a

    6LBR as a SubNet-level registrar.

"





> * References to unchartered individual work in Appendix.

>

> Appendix A describes a set of architectural dependencies that depend on non-

> adopted (individual) documents or work not formally chartered by the IETF.

> This description raises concerns about what happens when the present

> document is published, and this work is not taken-up or some alternative

> proposal is instead pursued, it would be safer to remove these references - or

> at least to confine them to an appendix that clearly sets out that this work is

> individual work in progress.

>

>



Makes sense. I took the latter approach.

The bottom line is that we could build interoperable 6TiSCH stacks without any of those features, IOW they are optional and future optimizations (e.g., zerotouch, broadcast reduction, etc...).

I had to rework the appendix to sort that out. The result looks like:



"



   Appendix A.  Related Work In Progress . . . . . . . . . . . . . .  61
     A.1.  Chartered IETF work items . . . . . . . . . . . . . . . .  61
     A.2.  Unchartered IETF work items . . . . . . . . . . . . . . .  62
       A.2.1.  6TiSCH Zerotouch security . . . . . . . . . . . . . .  62
       A.2.2.  6TiSCH Track Setup  . . . . . . . . . . . . . . . . .  62
       A.2.3.  Using BIER in a 6TiSCH Network  . . . . . . . . . . .  63
     A.3.  External (non-IETF) work items  . . . . . . . . . . . . .  63



"





> Transport issues

> --------------

>

> * "Transport Mode"

>

> Section 4.7.1 describes a "transport mode", but from the perspective of the

> IETF transport area is not a transport. While there have been many

> interpretations of "transports" by SDOs and IETF Specs, I suggest it would

> beneficial to add a few words refining the meaning of the words in the present

> usage: e.g. that this does not provide a "transport protocol", but provides a

> way to send and receive IPv6 packets that carry a transport protocol.



The language is inherited from IPSec http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html

I agree we should migrate to a different terminology as DetNet did in a similar collision situation recently.

Would "native" work? By default I'll migrate to that.



>

> * The IPv6 Flow Label may be zero

>

> Section 4.7.1.1 seems to imply that IPv6 packets carry a non-zero flow label

> value. Whilst I would support that desire, there are still cases where no flow

> label is set, and this casts should be described (or

> noted) in the text.



In general hope it's zero since a non-zero cannot be compressed : )

But for a Track we need a flow ID. DetNet has immensely progressed on IP and now

We have a reference for the words in that section, so I changed to:



"

              In native mode, the Protocol Data Unit (PDU) is associated

               with flow-dependent meta-data that refers uniquely to the Track,

               so the 6top sublayer can place the frame in the appropriate cell

               without ambiguity. In the case of IPv6 traffic, this flow

               identification may be done using a 6-tuple as discussed in

               [I-D.ietf-detnet-ip].

               The flow identification is validated at egress before restoring

               the destination MAC address (DMAC) and punting to the upper layer.



"



>

> * Assumption about IPv6 MTU

>

> Section 4.7.3 notes the IPv6 MTU is 1280 B. This is not true, please rewrite this

> sentence. It could be that the intentional was to state the minimum IPv6 MTU

> or something else was intended?



The 6LoWPAN MTU is 1280, though it is the IPv6 Minimal MTU.  Proposed change:



"

   Considering that 6LoWPAN packets can be as large as 1280 bytes (the

   IPv6 MTU)

"

->

"

   Considering that per section 4 of [RFC4944] 6LoWPAN packets can be as

   large as 1280 bytes (the IPv6 minimum MTU)

"





>

> * Possible PHB - reference to not chartered transport work.

>

> Section 4.8.3 describes a transport feature (diffserv PHB) and appears to

> promote an individual draft. The particular drafts appear to target tsvwg, but I

> do not recall these being proposed to that WG for adoption, and therefore this

> seems a little presumptuous to appear in the main body of text or within the

> architecture. The reference is also out-of-date.

> - I suggest it would be sufficient to explain that a future document could define

> a PHB for this purpose and refer to the IANA registry as the place where IETF-

> defined PHBs are listed.

> - Please this without citing a ref to an individual spec.?

> - In addition, I think if this sections retained, it needs to be moved to the

> appendix.



Ack. The section now reads:

"





4.8.3.  Differentiated Services Per-Hop-Behavior



   A future document could define a PHB for Deterministic Flows, to be

   indicated in the IANA registry where IETF-defined PHBs are listed.



"



The reference was removed.



>

>

> Editorial Issues

> -------------

>

> The following editorial issues should be addressed:

>

> The document makes frequent use of the phrase "in order to", which in most

> (all?) cases could be replaced more simply by "to" without loss of meaning.



Scanned and applied





> This would remove several cases where the sentence could currently be mis-

> interpreted as requiring temporal ordering of the actions.



Good!



>

> Section 4.3.3: "infoirmation" should be "information".



Applied



>

> Section 1, Sentence "Distributed is a concurrent model that..". i could not

> understand the intended meaning of this sentence.

>



Proposed change

"

         In contrast, Distributed Routing refers to a model that relies on the

         concurrent peer to peer protocol exchanges for TSCH resource allocation

         and routing operations.

"





> "such a Advance metering". "a" maybe should be "as"? Why is Advanced

> capitalised, I think this sentence lacks some necessary explanation, please add,

> and provide a reference.



Great point. I modified the sentence as follows, adding a link to DoE.

"



   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 as used in the Advanced Metering

   Infrastructure [AMI] solutions that leverage distributed routing to

   enable multipath forwarding over large LLN meshes.



"





   [AMI]      US Department of Energy, "Advanced Metering Infrastructure

              and Customer Systems", 2006,

              <https://www.energy.gov/sites/prod/files/2016/12/f34/

              AMI%20Summary%20Report_09-26-16.pdf>.









>

> CoJP - no reference is provided to where this is specified.



JP is now introduced as:

"



   CoJP (Constrained Join Protocol):  The Constrained Join Protocol

               (CoJP) enables a pledge to securely join a 6TiSCH network

               and obtain network parameters over a secure channel.

               Minimal Security Framework for 6TiSCH

               [I-D.ietf-6tisch-minimal-security] defines the minimal CoJP

               setup with pre-shared keys defined.  In that mode, CoJP

               can operate with a single round trip exchange.



"









Please let me know if the changes are OK and I'll publish a revision.





Again, many thanks Gorry!



Pascal