All,
The INT ADs have been asking the Internet Area directorate to
review all documents coming from our WGs. I would like to see this
discussed on the list and we can use time in Prague to resolve any
outstanding points.Regards, Brian -------- Forwarded Message -------- 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] _______________________________________________ Int-dir mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-dir
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
