I received the echo of the below truncated; there may be a weird character in there; in case you got it truncated too, I'm resending a copy plain text;
Pascal > I had a hard time mapping from the points in my review to the issues > tracked in bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/ > > In particular, I don't see where these comments were addressed: > > 1. Goals and requirements are unclear > > The requirements for this document are unclear to me. Exactly what > services would a "minimal mode of operation" provide? The Abstract > and most of the document talks about the operation of an IEEE > 802.15.4 TSCH network, yet the title of the document is "Minimal 6TiSCH > Configuration". > Does a network that follows these rules provide an L2 IEEE 802.15.4 > service, an > IPv6 6TiSCH service, ??? > > Related to this question, does this document describe "a minimal set > of rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of > operation" > (both text snippets from the Abstract). This issue is related with the next. I'll be proposing text at the end of this mail; > > 2. Requirement for RPL is ill-advised > > This document seems to be focused on IEEE 802.15.4 TSCH operational > parameters. Yet, it calls for the use of RPL, which seems to me to be > a highly undesirable entangling of protocols at different layers of the > protocol stack. > IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL. 6TiSCH includes the mesh support by default, which is kind of natural for 802.15.4 as opposed to, say, Bluetooth. So we care to get interoperation at that level as well and include that in the minimum support. 6TiSCH was put together to address the NBMA nature of the multihop network as opposed to considering only one hop, like BTLE does, which would probably be have been 6lo work. > My understanding of the document is that RPL is assumed to be in use > because it is required in a 6TiSCH network. RPL is then used to > generate the Join Priority through the DAGRank function as specified > in section 7.2. The use of RPL implies to me the configuration and > operation of a full IPv6 stack, which hardly seems like a minimal mode of > operation for IEEE 802.15.4 TSCH. Looks like a definition issue, maybe we can reword the intro. An abstract "minimal mode of operation for IEEE 802.15.4 TSCH " does not need IP at all but that's not what we are defining here. We are defining a "minimal mode of operation for IPv6 over a IEEE 802.15.4 TSCH network", in other words the minimal thing that is needed to build a 6TiSCH network, which includes the capability to support multihop operation, which includes synchronization. 6TiSCH requires RPL for data and time synchronization over multiple hops. That capability is part of our bare minimum. If someone only cares for hub and spoke, then RPL is not needed, but supporting only that model is below the bar of the 6TiSCH bare minimum. > I looked at draft-ietf-6tisch-minimal-13, and I see that there are no > changes to the abstract or the introduction. As I read that text, > this document is intended to give minimal operational parameters for > IEEE802.15.4 TSCH. However, the title of the document is "Minimal > 6TiSCH Configuration" and the content goes far beyond the parameters > needed to run IEEE802.15.4 TSCH. As an aside, I don't see any mention > of TiSCH or 6TiSCH in the document, other than in the title. I agree, Ralph; Proposals: -------------- Abstract (before) This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fall- back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development. ---------- Abstract (after) This document describes the minimal set of rules to operate a 6TiSCH Network, which provides IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links. This minimal set only provides static scheduling, but it can be complemented in operating networks by distributed, or centrally controlled, dynamic scheduling extensions. ---------- ------------ 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction The nodes in a IEEE 802.15.4 TSCH network follow a communication schedule. The entity (centralized or decentralized) responsible for building and maintaining that schedule has precise control over the trade-off between the network's latency, bandwidth, reliability and power consumption. During early interoperability testing and development, however, simplicity is more important than efficiency. One goal of this document is to define the simplest set of rules for building a TSCH-compliant network, at the necessary price of lesser efficiency. Yet, this minimal mode of operation MAY also be used during network bootstrap before any schedule is installed into the network so nodes can self-organize and the management and configuration information be distributed. In addition, the minimal configuration MAY be used as a fall-back mode of operation, ensuring connectivity of nodes in case that dynamic scheduling mechanisms fail or are not available. The IEEE 802.15.4 specification provides a mechanism whereby the details of slotframe length, timeslot timing, and channel hopping pattern are communicated when a node time synchronizes to the network [IEEE802154]. This document describes specific settings for these parameters. ------------------------------ 1. Introduction A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) links. Nodes in a IEEE 802.15.4 TSCH network follow a communication schedule. An entity (centralized or decentralized) responsible for building and maintaining that schedule has precise control over the trade-off between the network's latency, bandwidth, reliability and power consumption. The degree of optimization that is obtained depends on the capabilities of the controlling entity and the acceptable complexity for a given deployment. In a minimal configuration, this controlling entity is omitted, and the schedule is static. The IEEE 802.15.4 specification provides a mechanism whereby the schedule, expressed as details of slotframe length, timeslot timing, and channel hopping pattern, is obtained by a node at the time it joins the network [IEEE802154]. This specification defines a Minimal Configuration to build a 6TiSCH Network, using the Routing Protocol for LLNs (RPL) and a static TSCH Schedule. The 802.15.4 TSCH mode, RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used unmodified, but parameters and particular operations are specified to guarantee interoperability between nodes in a 6TiSCH Network. More advanced work is expected in the future to complement the Minimal Configuration with dynamic operations that can adapt the Schedule to the needs of the traffic in run time. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. ------------------------------ The changes above attempt to address Ralph's comments, but also Brian's point that 2119 language should come after the introduction, and removes unnecessary text on particular usages which appeared to limit the applicability of the draft. > I really need to get clarity on the purpose and scope of the document > before I can continue my re-review. Yes; and ultimately the purpose is to match charter item 3: " 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is. The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied in ROLL. " Huge thanks for your patience and your willingness help / make sure we do the right thing. Take care, Pascal _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
