> On Dec 9, 2015, at 3:58 AM 12/9/15, Pascal Thubert (pthubert) > <[email protected]> wrote: > > Hello Ralph: > >> 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, ???
This is the key question I was trying to get an answer for. I think what I read below is that the intention for this document is to define "a set of rules for simplest operation of an 6TiSCH network". >> >> 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; OK. >> 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 key question is whether this document aimed at a description of how to use IEEE 802.15.4 TSCH or 6TiSCH. As the goal is a description of 6TiSCH, a description of how to use RPL is, of course, appropriate. > >> 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 still think tying the join process to the use of RPL is a bad idea, but that's a minor design point for the WG. >> 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. > > ---------- I apologize if I appear to be wordsmithing (or even bikeshedding). I don't think the first sentence is right. I think what this document describes is a simple mode of operation to provide IPv6-over-6Tisch service. The motivation for this mode of operation is testing, initial deployment and/or "required to implement" to provide a baseline of interoperability. I think the focus should be on the purpose of the document as a whole and the details of the scheduling mechanism can be left for the Introduction. > > ------------ > > > > 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. Good - a crisp definition of "6TiSCH" is critical. > 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. What about all the other protocols required to run an IPv6 network? I would assume that the reader knows about IEEE 802.15.4 TSCH, RPL, etc., and their principles of operation. In the interest of conciseness, I recommend eliding motivations and descriptions of protocols that are available elsewhere. If I were reading this document, I would want to know what protocols I need to implement, what is the default operation of those protocols, what operational parameters a device will receive through the network, what defaults a device should use for other operational parameters. > 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. On reflection, I think this charter item is incomplete. It focuses on only two aspects of how to build a simple 6TiSCH network: scheduling and routing. A complete IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND, address management, prefix management, etc. Ideally, this document would be paired with a complete IPv6-over-6TSCH specification, so that this document specifies only those particular operational parameters required for the simple subset of the IPv6-over-6TSCH specification. I understand that there is a circular dependency in that it's likely this simple 6TiSCH definition will be needed for development and testing before a complete 6TiSCH definition is published. In that case, this document will need to be a standalone document and include descriptions of how to use all of the protocols required for 6TiSCH service. > 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 > >> -----Original Message----- >> From: Ralph Droms (rdroms) >> Sent: mardi 8 décembre 2015 15:56 >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal >> >> >> 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). >> >> 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. >> >> 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. >> >> 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 really need to get clarity on the purpose and scope of the document before >> I >> can continue my re-review. >> >> - Ralph >> >>> On Nov 30, 2015, at 7:20 AM 11/30/15, 6tisch issue tracker >> <[email protected]> wrote: >>> >>> #40: Ralph's INT AREA review on minimal >>> >>> >>> Comment (by [email protected]): >>> >>> Xavi addressed comments one by one, tracked under bitbucket as >>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/ >>> All issues are solved but the intended status that we will track with >>> a separate ticket >>> >>> -- >>> -----------------------------------+---------------------------------- >>> -----------------------------------+-- >>> Reporter: [email protected] | Owner: [email protected] >>> Type: defect | Status: new >>> Priority: major | Milestone: milestone1 >>> Component: minimal | Version: 1.0 >>> Severity: Submitted WG Document | Resolution: >>> Keywords: | >>> -----------------------------------+---------------------------------- >>> -----------------------------------+-- >>> >>> Ticket URL: >>> <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:1> >>> 6tisch <https://tools.ietf.org/6tisch/> >>> IPv6 over the TSCH mode of IEEE 802.15.4e >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
