Dear all:
Ralph kindly provided a review for Archie on behalf of the Internet Area directorate INT-DIR. Please find below some discussion, comments welcome. Please see below Pascal ------------------------------------------------ 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 <Pascal> I'll be asking you for suggestions to implement this. The discussion below may help structure that. </Pascal> * 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 <Pascal> Agreed: As you point out we have 2 things here; *one is a mid-level architecture, with components like the PCE, the backbone, the backbone routers, the RPL Roots/6LBRs, the 6LRs and the 6TiSCH nodes. In this architecture we position protocols and provide example flows to illustrate how things work. The architecture also positions the mix to distributed (RPL) and centralized (DetNet) flows. * the other is a more refined study of the components we were chartered to work on, mostly distributed routing over a fixed schedule. The missing pieces that we identified are 1) Security, 2) DetNet, and 3) distributed routing over a dynamic schedule. For the DetNet piece, the architecture clearly references the external document from DetNet: The DetNet Architecture [I-D.finn-detnet-architecture<https://tools.ietf.org/html/draft-ietf-6tisch-architecture-08#ref-I-D.finn-detnet-architecture>] studies Layer-3 aspects of Deterministic Networks, and covers networks that span multiple Layer-2 domains. For the others, we understand that they are not covered in the same depth, and that is why we have proposed this notion of volume. We can explain that better in the intro? >From there, suggestions are welcome. One option would be to better explain the structure in volumes and what will come with the next volumes if we get the WG rechartered. Another that seems implied by your review is that we should split the doc, reopen the overall mid-level architecture (and eventually keep it open for the next round(s) till we have the whole story), while shipping the pieces for which we have a more complete design or specification content. Is that we you have in mind? </Pascal> 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 protocols 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. <Pascal> I'm not sure what the recommendation is for section 6? Should we make it lighter? We discussed quite a bit about having already a security section. It is clearly high level, but summarizes the consensus in the Security DT that was reviewed by the WG. But security is clearly one of the items that is deferred to next volumes. </Pascal> 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? <Pascal> These are key issues for the DetNet operation. The document effectively addresses them by reference to detnet architecture. We discussed central scheduling and deterministic tracks quite a bit and have a clear picture of what we want there that really depends on the devices, thus the text on tracks and forwarding in the architecture document. We also provide the data models. When it came to chartering, we did not charter for the work that related to the questions above. More recently, we contributed to the DetNet discussions which end up now as a WG forming BoF in Prague. The group decided to defer to DetNet. So the questions above will be answered there if the WG forms. 6TiSCH still provides the data models for configuring the 6TiSCH devices https://tools.ietf.org/html/draft-ietf-6tisch-6top-interface and https://tools.ietf.org/html/draft-ietf-6tisch-coap but we are waiting for the generic approach from DetNet to see how that is instantiated for 6TiSCH. </Pascal> 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 <Pascal> Full disagreement here. The work on dynamic routing (RPL) with static schedule does not depend on the DetNet work. Proof by the minimal work is quite convincing with 3 implementations doing interop testing in Prague. The document reflects the work of the WG and is applicable in real products as demonstrated by the plugtest. Our charter was actually to work on the items above, so we did and this is the conclusion that we committed to deliver to the IESG. </Pascal> 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? <Pascal> I agree that text about that would be informative. Typical control loops are in the order of a second, but a tight schedule could run down to a few Hundredths of seconds if energy is not an issue. </Pascal> What are the requirements for mobility? Do those requirements mandate the hierarchical multi-link subnet architecture? <Pascal> I agree that text about that would be informative there too. There is usually no physical mobility in the classical sense, at least when deterministic scheduling is involved. But the radio conditions may make it so that a device reparents elsewhere, ending up attached to a different backbone router. There's also the case of a fully machine that is moved elsewhere and reconnects. </Pascal> 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. <Pascal> Standards that I'm aware of rely on L2 and L4 security but have no IP layer security RPL operations are protected by the L2 security. For your point, are you suggesting that we remove that section completely? </Pascal> 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. <Pascal> Fully agree. Will make these changes unless the group disagrees explicitly in this thread. </Pascal> 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. <Pascal>My reading is that the RFC 4903 lists issues that makes it so that in a classical environment, Multilink subnets is probably a bad idea. I have not seen that it deprecates the concept. Those issues in 4903 were reviewed in the context of 6TiSCH and other IoT environments, and the protocols that needed to be reconsidered like ND were effectively adapted. There is no issue that I am aware of against the ML subnet design in 6TiSCH. It is actually the only way to scale the subnet to the size that we are after without renumbering. The backbone with a backbone router is a very classical design in that space that is represented in the ISA100.11a specs as well.</Pascal> 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? <Pascal> I see value in adding text to cover your questions. Now the redundant text was added as part of the WG review process so we have to be careful there. Would you have an explitcit suggestion? </Pascal> 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. <Pascal>Same as the first points. Will make these changes unless the group disagrees explicitly in this thread. </Pascal> Thanks a lot Ralph! Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
