Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 27 June 2019 16:37 UTC
Return-Path: <pthubert@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 B3F0D120112; Thu, 27 Jun 2019 09:37:29 -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, 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 header.b=K+R4iRQs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DlgKX64D
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 1Eci01GQ4Qut; Thu, 27 Jun 2019 09:37:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5552120151; Thu, 27 Jun 2019 09:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14578; q=dns/txt; s=iport; t=1561653446; x=1562863046; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s15Q8xMLUaVvUS7Ua+yJnQN2ds0Qt2EObr5vxiMk8y4=; b=K+R4iRQs6j86gQacfKp/8ahhYLW8NaxkV0gKtG1c0/b+Lm+2ID3lTYdA DDR5AkPbziplYYqkuKNfgnkwWZiIEUowtc7axKFmjfx5j5RdJrBzJ2cPD xw2Py3SS+/UXMT5g+ykkBRGyktIv7LNpKWp6FDwWvQq8jM4vVh9NNMFex s=;
IronPort-PHdr: 9a23:2dXpTBHVmdoTzJMi39Tl151GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlAADs7xRd/51dJa1lGwEBAQEDAQEBBwMBAQGBVAUBAQELAYFDUANqVSAECyiEGYNHA45agluXP4EuFIEQA1QJAQEBDAEBIwoCAQGEQAIXgmkjNQgOAQMBAQQBAQIBBW2KNwyFSgEBAQQSEREMAQE3AQsEAgEIDgMBAwEBAwImAgICMBUCBggCBAENBQgagwGBagMdAQIMmnkCgTiIYHGBMoJ5AQEFgTYCg1AYghEDBoEMKAGEcYZtF4FAP4ERRoFOfj6CYQEBA4EiJBqDCDKCJo4vL5pnZQkCgheGUo0+giuHF4QMhgaECo0phziPZgIEAgQFAg4BAQWBUQE2gUEPCHAVgyeCQQwXg06FFIU/coEpjXgBAQ
X-IronPort-AV: E=Sophos;i="5.63,424,1557187200"; d="scan'208";a="583511792"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jun 2019 16:37:22 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x5RGbMDu006479 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jun 2019 16:37:22 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 11:37:22 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 12:37:21 -0400
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 12:37:20 -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=s15Q8xMLUaVvUS7Ua+yJnQN2ds0Qt2EObr5vxiMk8y4=; b=DlgKX64DI9mOs2x5oCZljwyaPaX7UGDc6I+KqWzfGsMK2ed7KkXvBRgglXuQDn0LUcGCvlPDNaYEXFpADN15mOsGzMDrTuDVv+nivQcQS5lD8AnoJIphHvWrNQIUkEkNpVBos1KO2qoPAXvkI3fRJRBqSFp7im06FeH/AdBAVZE=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4141.namprd11.prod.outlook.com (20.179.150.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 16:37:19 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 16:37:19 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "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>, "Eliot Lear (elear)" <elear@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: Opsdir last call review of draft-ietf-6tisch-architecture-22
Thread-Index: AQHVLKNeNgt24c3b+kqLUzrCTZivr6au/4tQgACyxtA=
Date: Thu, 27 Jun 2019 16:37:15 +0000
Deferred-Delivery: Thu, 27 Jun 2019 16:36:49 +0000
Message-ID: <MN2PR11MB35651DF806646D6A0AE3A0FCD8FD0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <156161081490.19915.1890732764904910887@ietfa.amsl.com> <MN2PR11MB35652C02A56F8E6CB016B242D8FD0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35652C02A56F8E6CB016B242D8FD0@MN2PR11MB3565.namprd11.prod.outlook.com>
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:1006::89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2c6d3325-3995-4d29-6ba9-08d6fb1db8dd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4141;
x-ms-traffictypediagnostic: MN2PR11MB4141:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB41410759D28C36DA14858933D8FD0@MN2PR11MB4141.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 008184426E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(366004)(136003)(13464003)(189003)(199004)(66946007)(4326008)(229853002)(99286004)(966005)(6116002)(476003)(76116006)(110136005)(2906002)(5024004)(7696005)(486006)(14444005)(52536014)(446003)(5660300002)(6666004)(25786009)(2940100002)(86362001)(14454004)(256004)(66574012)(74316002)(81166006)(33656002)(53936002)(81156014)(6246003)(66556008)(73956011)(6436002)(55016002)(71200400001)(66476007)(64756008)(66446008)(68736007)(7736002)(107886003)(71190400001)(9686003)(8676002)(8936002)(6306002)(316002)(102836004)(186003)(11346002)(76176011)(54906003)(53546011)(6506007)(305945005)(2501003)(46003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4141; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: Y4/IbH+eM7m5WTNkEksk8KzkhECUSckyLzZOoJggTTgUG9lZ2hZqfUUbs+SQUDtY8B+qeTq2oyjxHZ3U20XPdRapPesRG9p2kEqqRXHKfkd805PyIBalRc2ptognaOz+Xv9uaYx3CuC/fM8nsNyRARO9wTrPKuAvmPb0L2WA8v45HXP/nWHASyHKLxgYNsnchzho/OOnevO2OAVtZ+woHDp+wFk6OVtPGM2ZFQ6rsAXy7jWUFB8cuQkyqUiO0SX4JFTHYwX6Q6VvpW3FW+nJus7WeDG7v04pkJEdsVIOkY2QKSbEdBiQN/imOyuyTt/QwKgN/t/Ij6rwcCxLQWnVjB60X6TWmKREqyoN7ggnfIp+laOVagT5JfcdRj9TFA70mG3yBFSjZIyCo3BUUK1bBuFque6gFe/7GfJvnhe6J2Y=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c6d3325-3995-4d29-6ba9-08d6fb1db8dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 16:37:19.1427 (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: MN2PR11MB4141
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/8GqXhPybzfAJInMtkPLyQPk4Voc>
Subject: Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22
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: Thu, 27 Jun 2019 16:37:30 -0000
Hello Qin I looked at it again and found that it was great to move 3.8. Communication Paradigms and Interaction Models . . . . . 21 But not such a great idea to move 4.2. Network Access and Addressing . . . . . . . . . . . . . . 23 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 23 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 25 So my suggestion for the latter is to better introduce the join process and the registration in section 3.1. Proposed text: ' 6TiSCH nodes join a mesh network by attaching to nodes that are already members of the mesh (see Section 4.2.1). The security aspects of the join process are further detailed in Section 6. In a mesh network, 6TiSCH nodes are not necessarily reachable from one another at Layer-2 and an LLN may span over multiple links. This forms an homogeneous non-broadcast multi-access (NBMA) subnet, which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND operations in this type of subnet. Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses and register them using 6LoWPAN ND. This guarantees that the addresses are unique and protects the address ownership over the subnet, more in Section 4.2.2. ' Does that work? Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: jeudi 27 juin 2019 16:48 > To: Qin Wu <bill.wu@huawei.com>; ops-dir@ietf.org > Cc: 6tisch@ietf.org; ietf@ietf.org; draft-ietf-6tisch-architecture.all@ietf.org; > Eliot Lear (elear) <elear@cisco.com>; Carlos Pignataro (cpignata) > <cpignata@cisco.com> > Subject: RE: Opsdir last call review of draft-ietf-6tisch-architecture-22 > > Hello Qin > > Many thanks for your review and for the important amount of time you > obviously spent on our work. This is really appreciated. > Please see below: > > > By looking at high level architecture section, it is hard to create a > > whole picture for what this architecture looks like and how these > > architecture component can be put together. Also architecture > > components defined in architecture component section seem not to align > > with high level architecture section. For Some architecture > > component,e.g.,Communication Paradigms and Interaction Models, Network > > access and addressing haven't appeared in the high level architecture first. > > This is an interesting comment. > > If you look back at say, draft 18, the sections in the high level architecture > have been modified and quite a bit of text went from section 3 to section 4. > The reason is that the first reviews we got from outside the WG told us to > shrink section 3 to the minimum, which caused us to move text to section 4. > > I'm intrigued by your comment " seem not to align with high level architecture > ". This is certainly something we need to act upon; but there is a difference > between the fact that a discussion appears only in section 4 and a > misalignment, which I read as a discrepancy or an inconsistency in the > architecture. Could you please provide suggestions on where to focus without > undoing what we did for the previous reviewers? If this is about moving text > back to section 3, I generally agree but need to confirm with the original > reviewers (cc), more below. > > > A few editorial comments and suggestions > > 1.Section 1 IT and OT should be part of terminology section too. > > Expanded both in first use and added a terminology for OT. IT is a bit too > obvious for a terminology section isn't it? > " > <t hangText="Operational Technology:"> > OT refers to technology used in automation, for instance in > industrial control networks. The convergence of IT and OT is > the main object of the Industrial Internet of Things (IIOT). > " > > > 2.Section 2 > > ND-proxying and binding should provide reference,e.g.,RFC4389 > > Well, this reference would be misleading because it considers specific network > models that are not the one we need in 6TiSCH. So we refrained from using it. > Turns out that there is no IPv6 RFC that would be equivalent to ARP proxya > and that we could reference. That's until now since we are doing the backbone > router. Which is what the architecture discusses later. Sorry but I have no > clean path to fix this... > > > 3.Section 3 I > > think Architecture Components Defined in section 4 should be > > consistent with high level architecture, e.g.,Network access and > > Adressing component seems not to be discussed in high level architecture > section. > > See https://tools.ietf.org/html/draft-ietf-6tisch-architecture-17 section 3.7, > that subsection was in section 3. This is how I thought it should be structured. > But then it was moved to 4 on request of a previous IESG review to improve > the clarity y making section 3 more concise. I'm happy to move it back but cc > the original reviewers to make sure we all agree on the final result. > > Please confirm that this is effectively your recommendation. > > > 4. Section 3.1 figure1 > > NME and PCE should be part of terminology section > > > Added terminology + verified that the terms are expanded in first use. > Note that I got the exact reverse remark from another reviewer, said > something like expanding in first use is the IETF way and sufficient. > A hint that there is no perfection ; ) > > 5.Section 4.3.1.1,1st > > paragraph The first sentence should not belong to this section since this > > section focuses on introduction of Hard cell. > > Agreed; moved above the section boundary. > > 6.Section 4.3.1.1, Section 4.3.1.2 > > Two section seesm only to discuss how to use hard cells or soft cell, but > > doesn't define what it is. Please clarify the difference between hard cell or > soft > > cell > > Actually it does but it could be a lot more clear. > > Proposed text: > > On hard cells > > "Hard" cells are cells that are > are owned and managed by a separate scheduling entity (e.g. a PCE) > that specifies the slotOffset/channelOffset of the cells to be > added/moved/deleted, in which case 6top can only act as instructed, > and may not move hard cells in the TSCH schedule on its own. > > On soft cells > > In contrast, "soft" cells are cells that 6top can manage locally. > 6top contains a monitoring process which monitors the performance of > cells, and can add, remove soft cells in the TSCH schedule to adapt > to the traffic needs, or move one when it performs poorly. > > > > 7. Section 4.4 How this section is related to high level architecture > > described in section 3 > > If that is what you have in mind, yes, this section is mostly an introduction to > sections 4.5 to 4.8. > If that corrects the issue as you see it, then I agree to move it to section 3. > Please confirm that this is effectively your recommendation. > > > > 8. Section 4.5.3 The content in section 4.5.3 is badly > > written and hard to understand. By reading the first paragraph of section > 4.5.3, > > it is hard to get sense of what remote monitoring and schedule management > > means and how reproduced figure 10 is related to remote monitoring and > > schedule management. > > How Remote monitoring and schedule management is different from other > > scheduling mechanism. Please rewrite. > > It is effectively a DetNet/SDN model whereby the controller assigns physical > resources in the form of time slots. > I can add text at the beginning of the section: > > before > " > The work at the 6TiSCH WG is focused on non-deterministic traffic and > does not provide the generic data model that would be necessary to > monitor and manage resources of the 6top sublayer. It is recognized > that CoAP can be appropriate to interact with the 6top layer of a > node that is multiple hops away across a 6TiSCH mesh. > > The entity issuing the CoAP requests can be a central scheduling > entity (e.g. a PCE), a node multiple hops away with the authority to > modify the TSCH schedule (e.g. the head of a local cluster), or a > external device monitoring the overall state of the network (e.g. > NME). It is also possible that a mapping entity on the backbone > transforms a non-CoAP protocol such as PCEP into the RESTful > interfaces that the 6TiSCH devices support. > " > After > > " > Remote monitoring and Schedule Management refers to a DetNet/SDN > model whereby an NME and a scheduling entity, associated with a PCE, > reside in a central controller and interact with the 6top layer to > control IPv6 Links and Tracks (Section 4.6) in a 6TiSCH network. The > composite centralized entity can assign physical resources (e.g., > buffers and hard cells) to a particular Track so as to optimize the > reliability within a bounded latency for a well-specified flow. > > The work at the 6TiSCH WG focused on non-deterministic traffic and > did not provide the generic data model that is necessary for the PCE > to monitor and manage resources of the 6top sublayer. This is > deferred to future work, more in Appendix A.2.2. > > " > > Note that since we do not do the work, it is too early to presume that CoAP > and PCEP will be finally adopted for this purpose and the references are > removed. > > > 9. Section 7 Too many thanks in the acknowledgment section, suggest to > simplify it. > > This is the only place where I really disagree. Those people helped. The WG has > been on this spec for 5+ years. I do not see why it hurts to recognize them. > > > 10.Appendix A not sure the > > importance of this part and how these related work are related to > architecture > > or section 2.3. Suggest to remove this appendix or consolidate some text > with > > section 2.3. > > Then again your suggestion is how I would have done it and actually did in > earlier versions. The text moved to appendix due to IESG review; we got a > concern that the architecture had too many references to incomplete work, so > the text was moved. Since there were 3+ reviewers indicating the issue, I'd > rather not undo if that's OK with you. > > Please
- [6tisch] Opsdir last call review of draft-ietf-6t… Qin Wu via Datatracker
- Re: [6tisch] Opsdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [6tisch] Opsdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [6tisch] Opsdir last call review of draft-iet… Qin Wu
- Re: [6tisch] Opsdir last call review of draft-iet… Qin Wu
- Re: [6tisch] Opsdir last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [6tisch] Opsdir last call review of draft-iet… Qin Wu