#39: Ralph's INT AREA review Description changed by [email protected]:
Old description: > I am an assigned INT directorate reviewer for draft-ietf-6tisch- > minimal-12. These comments were written primarily for the benefit of the > Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with any > other Last Call comments that have been received. For more details on the > INT Directorate, see http://www.ietf.org/iesg/directorate.html. > > Review submitted by Ralph Droms > > Summary: In my opinion, the WG needs to reconsider some of the > fundamental aspects of this proposed specification, and the document > needs significant restructuring and editing. I will be happy to work > with the WG to revise the document and review future revisions. > > There may be overlaps between my comments and those in other reviews > because I avoided reading those reviews before writing up my review. > > Here are my comments on the document. The first four comments apply to > the document as a whole, while the remainder address more specific > issues, roughly in the order of appearance in the document. > > 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 have a question about this text from section 7.2: > > When a node joins the network, > it MUST NOT send EBs before having acquired a RPL rank. This avoids > routing loops and matches RPL topology with underlying mesh topology. > > What is meant by "avoiding routing loops"? My understanding is that IEEE > 802.15.4 TSCH simply provides for frame delivery between neighbors and > does not provide frame forwarding. How would routing loops arise from > running IEEE 802.15.4 TSCH? > > Has the WG considered reorganizing the 6TiSCH protocol suite and > documents to separate the minimal operation of IEEE 802.15.4 TSCH from > IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler, > initial Join Priority scheme that would provide minimal IEEE > 802.15.4 TSCH operation until the full IPv6 suite is running, at which > time RPL will provide optimal routing. > > 3. Restatement of specifications in IEEE 802.15.4 documents > > I haven't read the most recent IEEE 802.15.4 docs and it has been a while > since I took a close look at earlier revs. With that disclaimer in mind, > how much of the text in sections 3 through 9 is a restatement of the IEEE > 802.15.4 specification and how much is the specification of operational > parameters for minimal operation of a IEEE 802.15.4 TSCH network? > Restatement of specifications can be confusing and lead to a lack of > interoperability. As a small example, here is section 6: > > 6. Acknowledgment > > Link-layer acknowledgment frames are built according to [IEEE802154]. > Unicast frames sent to a unicast MAC destination address MUST request > an acknowledgment. The sender node MUST set the ACK requested bit in > the MAC header. The acknowledgment frame is of type ACK (frame type > value 0b010). Each acknowledgment contains the following IE: > > ACK/NACK Time Correction IE: The ACK/NACK time correction IE > carries the measured de-synchronization between the sender and > the > receiver. Refer to Section 11.3 for an example of the Header IE > content. The possible values for the Time Synchronization > Information and ACK status are described in [IEEE802154]. > > Out of that section, it seems to me that the first sentence is harmless, > the second sentence is a specification for this document, the third and > fourth sentences are a restatement of [IEEE802154] and the fifth sentence > is an inferred specification for this document. The description of the > IE is a restatement of [IEEE802154]. > > Section 6 could be rewritten as: > > 6. Acknowledgement frames > > Unicast frames sent to a unicast MAC destination address MUST request > an acknowledgment. Each acknowledgment MUST contain an ACK/NACK > Time Correction IE. > > 4. Default behavior versus learned behavior > > Which of the configuration and operational specifications in this > document must be pre-configured before a node joins the network, and > which are learned through, e.g., EBs. Are operational control and > management questions out of scope for this document, such as: > > - when does a node switch from the "minimal 6TiSCH configuration" to > some other configuration? > - does a node use the configuration parameters it has received > through EBs to generate its own EBs or does it use the "minimal > 6TiSCH configuration" parameters? > > 5. In this text from the Introduction, does "synchronizes with the > network" mean time synchronization or something else: > > [...] when a node synchronizes to the network. > > 6. I don't think the last sentence of the Introduction is relevant to an > Introduction. > > 7. The document could use a section on the terminology used in the > document, to provide definitive sources for definitions of the various > terms and acronyms used in the document. Most likely, the terminology > section would simply point to relevant sections of [IEEE802154] and [I-D > .ietf-6tisch-terminology]. > > 8. Section 11 should be an Appendix, rather than part of the body of the > document, so as to avoid making those examples normative standards text. > > 9. I think the contents of section 7.1 are entirely dependent on the > specifics of an implementation and the section should be omitted. > > 10. I think the information in section 8 would be more generally useful > if not stated in terms of a queue-based implementation: > > A node must not transmit frames containing higher-layer packets until > the node has successfully joined a network. > > Frame types BEACON and ACK > > Frames generated by the IEEE 802.15.4 layer are transmitted before > frames containing higher-layer packets. > > 11. According to [I-D.ietf-6tisch-terminology], the correct term is > "timeslot", so s/time slot/timeslot/ throughout the document. > > 12. In the table at the top of page 4 (BTW, please number and add a title > to all tables), are the listed properties the only properties that have > numeric or short text string values? If not, all of those properties > should be gathered together into a single table. As an editorial aside, > this table is pretty much what I expected to be the bulk of this > document. > > 13. Even if the number of timeslots in a slotframe is variable for this > minimal configuration, should there be a default? > > 14. In the table at the top of page 5, what do the empty boxes represent? > > 15. The last sentence of section 3.2 seems to be a low-level > implementation detail that can be omitted. > > 16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll > suggest that almost all of section 3.4 is a restatement of the IEEE > 802.15.4 spec. The last sentence is important, and isn't entirely clear. > It would be clearer to write: > > For the minimal configuration specified in this document, the use > of CCA is OPTIONAL. > > 17. End of section 3 - not clear when to use macTimeslotTemplate. > > 18. The third paragraph of section 4 is completely unclear to me: > > A Node aiming to join the network by receving a properly formed > BEACON shall enter in a scan phase and shall store the value of > macPANId and then set it to 0xffff for the duration of the scan in > order to meet the filtering rules in [IEEE802154]. > > What are "macPANId" and "scan phase"? I don't see those terms used > anywhere else in this document; do the terms come from the IEEE > 802.15.4 specs? Why would an implementation store the value of macPANId > and then set it to 0xffff? > > 19. Does "synchronization" in section 5 mean "time synchronization"? > > 20. In section 5, is "EB_PERIOD" the same value as defined in the table > in section 10.2.4 that defines "RPL-related variables"? If so, I don't > understand why "EB_PERIOD" is in that table, as it only appears once in > the rest of the document in section 5. > > 21. I see that section 10 includes the statement: > > Nodes in a multihop network MUST use the RPL routing protocol > [RFC6550]. > > This statement is certainly false if one takes a broad definition of the > word "multihop". Even if edited to "multilink subnet" or "mesh", I can't > find any support in RFC 6550 for the statement "MUST use RPL routing > protocol". I think it would be much clearer and more correct to quote > verbatim the text describing this requirement from RFC 6550 rather than > paraphrasing it here. > > Similarly, this sentence in section 10.1 needs, at least, to be edited, > and I think it should be replaced with quoted text from RFC 6552. > > Nodes in the multihop network MUST implement the RPL Objective > Function Zero [RFC6552]. > > While I haven't provided a detailed review of the remainder of section > 10 because I don't think it's necessary for the goals of this document, > it appears to me that much of section 10 is a restatement of the RPL > specification from RFC 6550 and should, therefore, be omitted (if RPL is > retained as a part of this recommendation). New description: Subject: [Int-dir] Internet Directorate review of draft-ietf-6tisch- architecture-08.txt Date: Wed, 17 Jun 2015 11:04:08 -0400 From: Ralph Droms <[email protected]> To: [email protected], <[email protected]> <[email protected]> CC: [email protected], [email protected], [email protected] I am an assigned INT directorate reviewer for <draft-ietf-6tisch- architecture-08.txt>. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Summary ------- This document is not ready for publication. It needs to address several technical and editorial issues before publication. In my opinion, the document: * misses the intent of an "architecture" document * mixes high-level architecture with more complete design or specification content * misses some architecture components * is incomplete and/or has been submitted for publication prior to completion of the architecture design Substantive/technical issues ----------------------------- This document seems to be a work in progress. There are several references to "first volume of the 6TiSCH architecture". In my opinion, it should be possible to write a description of the architecture in a single document. If not, then there should be a plan for what aspects of the architecture will go into other volumes. This document can't be assessed for completeness without some overview of the entire architecture. It might be that the WG would be better served by publishing the key components of this document in a more dynamic way, such as in a wiki, and then publish the final architecture when the component rotocols and specifications are complete. In my opinion, this document contains aspects of an architecture document, a requirements document and a design specification. However, it is missing some key aspect of each kind of document. For example, section 8 gives what I consider to be a description of the communication paradigms that are part of the architecture. The communication paradigms are described (for the most part) in the abstract, without specifying the design of how those paradigms are implemented. Section 6, on the other hand, gives specific design details that would be better expressed in a design or specification document. Similarly, section 10 specifies the current, preliminary design for the join process, rather than an architecture for security that describes all of the required security functions and how they relate to each other. Several key pieces of the design and architecture are missing. While I understand that this is the "first volume" of a suite of architecture documents, it seems to me that decisions about: * How do applications interact with the network to request deterministic behavior of a datagram, a flow, a bundle of flows? * How does the network report back to an application in the case where the deterministic behavior can't be met, or in the case where the network status has changed and an existing reservation can no longer be met? * How is centralized track computation performed? * How will the PCE/NME interact with other, autonomous functions such as the routing protocol? Or, will the PCE/NME control all forwarding? need to be made before decisions about the following can be made: * using a hierarchical multi-link subnet architecture * management protocols * routing protocols * scheduling protocols * fragment forwarding What, precisely, are the requirements? I see this text: traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. What are the time scales for jitter and latency - nanoseconds, microseconds, milliseconds? What are acceptable loss rates? What are the tradeoffs between loss and jitter/latency? What are the requirements for mobility? Do those requirements mandate the hierarchical multi-link subnet architecture? I'm not a security person, but it seems to me that relying solely on L2 security as described in section 10 is inadequate. The details of the join procedure belong in another document. Editorial issues ---------------- I think the abstract should read something like: This document describes a network architecture that provides low-latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of industrial deterministic applications. In general, try to avoid time-dependent references. For example: TSCH was introduced with the IEEE802.15.4e [IEEE802154e] amendment and will be wrapped up in the next revision of the IEEE802.15.4 standard. only makes sense at the time the document is published. Also try to avoid "new"; for example, change: At the same time, a new breed of Time Sensitive Networks is being developed to enable traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. to: Time Sensitive Networks enable traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. What is the "different time scale" for TSN and TSCH? The document gives no sense about the relative requirements and operational characteristics of TSN and TSCH. Explain in the Introduction (if I have this right) that the 6tisch architecture uses route computation to allocate and schedule cells to IPv6 packets. Rather than go into detail, for example, about using routing protocols to distribute ND registrations, explain that the multi-link subnet architecture requires extensions to NDP because not all hosts in a subnet can communicate with each other directly. I can't find the term "mote" anywhere else in the document, nor is it a widely used term, so the parenthetical "(also called motes)" is unneeded. I think the reference to 6tisch-terminology should come first in section 2. It took me a while to discover the importance of that document in understanding this architecture document. The citation of "Multi-link Subnet Support in IPv6" [I-D.ietf-ipv6-multilink-subnets] in the terminology section seems inappropriate, as the document expired 13 years ago and the concept was explicitly deprecated in RFC 4903. The overview in section 4 is helpful but provides some redundant details and leaves out some others. In particular, what are the roles of the PCE and NME, and what communication is required among them and the various forwarding nodes to complete the schedule computation and distribute the schedules? What are the architectural components of route computation and update? It would help the reader understand the motivation for the multi-volume architecture to move the first paragraph of section 5.1 to the Introduction. Can sections 3, 4 and 5 be merged? They all appear to explain aspects of an overview of the architecture. - Ralph Droms [email protected] -- -- --------------------------------+--------------------------------- Reporter: [email protected] | Owner: [email protected] Type: defect | Status: new Priority: major | Milestone: milestone1 Component: architecture | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | --------------------------------+--------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/39#comment:1> 6tisch <http://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
