Re: [6tisch] comments on latest terminology draft
"Turner, Randy" <Randy.Turner@landisgyr.com> Wed, 27 April 2016 18:44 UTC
Return-Path: <Randy.Turner@landisgyr.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 2E17F12D53F for <6tisch@ietfa.amsl.com>; Wed, 27 Apr 2016 11:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.onmicrosoft.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 3IR4O3_Uywdm for <6tisch@ietfa.amsl.com>; Wed, 27 Apr 2016 11:44:47 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1BF12D534 for <6tisch@ietf.org>; Wed, 27 Apr 2016 11:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LandisGyr.onmicrosoft.com; s=selector1-landisgyr-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jVA7TNRBReEKvhf71p7DYztW+WHr/OkN7ZWRZfoplK8=; b=GHgiKE74KMEe/5Q7YKKaj8dd4eyXhN+p+QCKrU1VYJujjkX6/5NfXRzEegO6GA3WFtMl5nnjEEcz7i/B67Tag7nQlqrWK2diBE620iJz0U9vqDg3Z3wVF4GZpMVEcNiLQjUsOINSoRifSF3sijjA69SxZjEz6LaE0dYHHExOUv0=
Received: from DB5PR01MB1815.eurprd01.prod.exchangelabs.com (10.166.168.149) by DB5PR01MB1814.eurprd01.prod.exchangelabs.com (10.166.168.148) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 27 Apr 2016 18:44:27 +0000
Received: from DB5PR01MB1815.eurprd01.prod.exchangelabs.com ([10.166.168.149]) by DB5PR01MB1815.eurprd01.prod.exchangelabs.com ([10.166.168.149]) with mapi id 15.01.0477.012; Wed, 27 Apr 2016 18:44:27 +0000
From: "Turner, Randy" <Randy.Turner@landisgyr.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Thread-Topic: [6tisch] comments on latest terminology draft
Thread-Index: AdGZoKbHRgGFx6QnSAi+5uwPNBhAfgC9gawAAABL2YAA/1eFgAAB/x2AAACFE3cAAFph0AAEM3GA
Date: Wed, 27 Apr 2016 18:44:26 +0000
Message-ID: <DB5PR01MB181509D20F9E25041069D08080640@DB5PR01MB1815.eurprd01.prod.exchangelabs.com>
References: <F085911F642A6847987ADA23E611780D1D14D40C@hoshi.uni.lux> <1978594436.3446991.1461769097749.JavaMail.yahoo@mail.yahoo.com>, <4182254c2db74175ba8ecae4e8862531@XCH-RCD-001.cisco.com> <5297F78C-4A3B-4BE6-A871-367A0F573322@landisgyr.com> <0380ad85364d4fa2a957f019a3c8fa64@XCH-RCD-001.cisco.com>
In-Reply-To: <0380ad85364d4fa2a957f019a3c8fa64@XCH-RCD-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=landisgyr.com;
x-originating-ip: [148.80.255.144]
x-ms-office365-filtering-correlation-id: 3853582f-b66d-49eb-95f8-08d36ecbf5d3
x-microsoft-exchange-diagnostics: 1; DB5PR01MB1814; 5:0AJ1V/3s2VevcZyflenFxZZj2A+PGaE3/YqQjRXKcMLhgOADKslnAnCG+GPWtvBRmOyY4N+gwGMZd3dkC8V0RzqAySfNcTxRBVnBkhqoRjL2kFaoGX7p/tRms5xrtCbFONb6NeMNLvrm0lX+2cYUKA==; 24:BPZo2oVEMu0l+EJ3gLUuN4+EVQGUJ4VRVzphbgOXnBMt6nOAesVNdrm0wG34Kh/fi86tb4vr2s9irgZx+9IbXdfP9LwjLaQUSvRSPptyBKA=; 7:dnbrFLvxAimZsHsXlUJ3U7fEcgJ5DAgdBLEZtKBHan1H1DSdiyNF03D7P3aqHDMc+D88CrRoWPPasKRqB35MHe4NDcupPcOCW09VhGKjOM6ea94IWgXVolkiWon3zLLeynypfBoN/Jgo+h3vCkppDC6999Vv0b5xRnQZTeBVoqWk3kwZHcgdGNuKOkhdNMdv
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR01MB1814;
x-microsoft-antispam-prvs: <DB5PR01MB18147AC7327E3ACCA34D678D80640@DB5PR01MB1814.eurprd01.prod.exchangelabs.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB5PR01MB1814; BCL:0; PCL:0; RULEID:; SRVR:DB5PR01MB1814;
x-forefront-prvs: 0925081676
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(24454002)(377454003)(76176999)(92566002)(2950100001)(87936001)(77096005)(19300405004)(10400500002)(2900100001)(54356999)(15975445007)(19625215002)(50986999)(551934003)(6116002)(66066001)(790700001)(19609705001)(33656002)(1220700001)(19580395003)(19580405001)(19617315012)(5002640100001)(122556002)(5003600100002)(2906002)(5008740100001)(11100500001)(3846002)(74316001)(110136002)(4326007)(189998001)(5004730100002)(1096002)(93886004)(586003)(16236675004)(9686002)(81166005)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR01MB1814; H:DB5PR01MB1815.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR01MB181509D20F9E25041069D08080640DB5PR01MB1815eurp_"
MIME-Version: 1.0
X-OriginatorOrg: landisgyr.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2016 18:44:26.6541 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR01MB1814
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/hWGm7NK8i4dOAKf6jYxJVxhpUWc>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] comments on latest terminology draft
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 27 Apr 2016 18:44:51 -0000
Yes, I think renaming the 15.4 link to a cell was good idea - our terminology draft restates the definition of "link" from RFC 2460 - maybe we should just stop there, or just refer to RFC 2460 - I think the rest of the text in the terminology draft definition of "link" complicates what we're really trying to say. R. From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, April 27, 2016 12:27 PM To: Turner, Randy Cc: Qin Wang; Maria Rita PALATTELLA; Thomas Watteyne; 6tisch@ietf.org Subject: RE: [6tisch] comments on latest terminology draft Well, Randy: IEEE 802.15.4 has a concept of " link" which we renamed as a cell to avoid that confusion. A 6TiSCH link is an IP link, we do not rename or overload. Mapping the concept to L2 TSCH requires pointing on a set of cells in and cells out. Which are bundled together, thus the name bundle. Cells in a bundle are equipotent. The question is whether we share the same bundles for all RPL instances or if we say that these are as many subinterfaces, on which we plug the instances as VRFs. So far the answer seems to have been yes. Cheers, Pascal From: Turner, Randy [mailto:Randy.Turner@landisgyr.com] Sent: mercredi 27 avril 2016 18:10 To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> Cc: Qin Wang <qinwang6top@yahoo.com<mailto:qinwang6top@yahoo.com>>; Maria Rita PALATTELLA <maria-rita.palattella@uni.lu<mailto:maria-rita.palattella@uni.lu>>; Thomas Watteyne <thomas.watteyne@inria.fr<mailto:thomas.watteyne@inria.fr>>; 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: Re: [6tisch] comments on latest terminology draft The way 6tisch has thought about the term link is confusing for folks not steeped in the history and context of this group R. On Apr 27, 2016, at 11:55 AM, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Qin It takes at least 2 bundles to create what a mote sees as a link, one in each direction. Now, should we have different bundles for different RPL instance? Pascal From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Qin Wang Sent: mercredi 27 avril 2016 16:58 To: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu<mailto:maria-rita.palattella@uni.lu>>; Thomas Watteyne <thomas.watteyne@inria.fr<mailto:thomas.watteyne@inria.fr>>; Turner, Randy <Randy.Turner@landisgyr.com<mailto:Randy.Turner@landisgyr.com>> Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: Re: [6tisch] comments on latest terminology draft Hi all, Do we really need the term "Link"? IMO, "Link" in 6TiSCH is same as Bundle. Right? Thanks Qin On Friday, April 22, 2016 9:07 AM, Maria Rita PALATTELLA <maria-rita.palattella@uni.lu<mailto:maria-rita.palattella@uni.lu>> wrote: Randy, sorry for my late answer. Thomas, thanks for jumping into it. Sure, the typos will be fixed in the next version ;) About the definition of "link" I have to say this is a kind of endless story... We have been discussed a lot in the past how to define it, how to make clear that the concept for 6TiSCH is different from classical IETF link definition, but it seems we created confusion, by putting too much information all together into it. Thomas's suggestion could simplify the problem. The link in fact exists when the two neighbors have at least one cell to exchange pkts. Thank you. Maria Rita From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Thomas Watteyne Sent: Friday, April 22, 2016 2:59 PM To: Turner, Randy <Randy.Turner@landisgyr.com<mailto:Randy.Turner@landisgyr.com>> Cc: 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: Re: [6tisch] comments on latest terminology draft Randy, I'll let Maria Rita comment about the typos, I assume it's just a matter to spinning the doc. About "link", I went back to read the draft. The following definition... ------------------ A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Thus, the IETF parlance for the term "Link" is adopted, as opposed to the IEEE802.15.4e terminology. In the context of the 6TiSCH architecture, which applies to Low Power Lossy Networks (LLNs), an IPv6 subnet is usually not congruent to a single link and techniques such as IPv6 Neighbor Discovery Proxying are used to achieve reachability within the multilink subnet. A link is distinct from a track. In fact, link local addresses are not expected to be used over a track for end to end communication. Finally, from the Layer 3 perspective (where the inner complexities of TSCH operations are hidden to enable classical IP routing and forwarding), a single radio interface may be seen as a number of Links with different capabilities for unicast or multicast services. --------------- ... is confusing, to say the least. IMO, it touches on almost all of the IETF work (talking about ND proxy, mutiling subnets, tracks in the definition of link ?!?) , is incredibly confusing, and as a result carries 0 information. What about A link exists between two nodes when at least one cell is schedule between them. Thomas On Mon, Apr 18, 2016 at 8:38 PM, Turner, Randy <Randy.Turner@landisgyr.com<mailto:Randy.Turner@landisgyr.com>> wrote: Hi Guys, I had a couple of comments on the recent -07 terminology draft: Deterministic Network - "A deterministic network can allocates..." should be "A deterministic network can allocate..." "6top Data Convey Model" - Model describing how the 6top adaptation layer...<snip> Is this really an adaptation layer? - In the IETF, the term "adaptation layer" has come to mean something different 6p Transaction - "Part of the 6top Protocol, in consists in" should probably be "...consists of" "Bundle" - typo "usining" should be "using" "Link" - When I read this description, it sounds similar to an interference domain - should the difference (if any) be spelled out or distinguished ? Or am I the only one that sees this similarity? Thanks! R. _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com<http://www.thomaswatteyne.com/> _______________________________________ _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch
- [6tisch] comments on latest terminology draft Turner, Randy
- Re: [6tisch] comments on latest terminology draft Thomas Watteyne
- Re: [6tisch] comments on latest terminology draft Maria Rita PALATTELLA
- Re: [6tisch] comments on latest terminology draft Qin Wang
- Re: [6tisch] comments on latest terminology draft Pascal Thubert (pthubert)
- Re: [6tisch] comments on latest terminology draft Turner, Randy
- Re: [6tisch] comments on latest terminology draft Pascal Thubert (pthubert)
- Re: [6tisch] comments on latest terminology draft Turner, Randy
- Re: [6tisch] comments on latest terminology draft Wang, Chonggang
- Re: [6tisch] comments on latest terminology draft Pascal Thubert (pthubert)
- Re: [6tisch] comments on latest terminology draft Wang, Chonggang