Hello Eliott All the best,
Pascal From: Eliot Lear <[email protected]> Sent: jeudi 7 mars 2019 17:10 To: Pascal Thubert (pthubert) <[email protected]> Cc: iot-dir <[email protected]>; [email protected]; [email protected]; Suresh Krishnan <[email protected]>; Carlos Pignataro (cpignata) <[email protected]>; CARLOS JESUS BERNARDOS CANO <[email protected]> Subject: Re: Early IoT-Dir review of draft-ietf-6tisch-architecture-19 On 26 Feb 2019, at 15:08, Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Hello Eliot Many thanks for your early review! And yes, I agree that a smaller committee is great to clean up the major aspects before opening to the wider public. Please see below (in purple in the text): First, the good. I commend you on using the early review option! This provides you the opportunity to consider substantial changes prior to garnered consensus, saving you lots of time and energy. You have much of the content that is necessary to explain the architecture. In several reads I became confident that much of this will actually work. Clearly the approach is quite flexible to support a great many deployments. It seems to me you have identified all the right building blocks. > Yes, and we have built it (2 open source plus a major private > implementations) and interop tested it (with ETSI) over the recent years : ) Major issues The bad. It took me several reads over a week to really get it, and I was trying. * This document introduces a great many concepts. It is not clear to me that they should all be introduced in one document. As a test, ask yourself this question: what would the reader lose if you did not include Section 4.4.3? If you are going to introduce all of these concepts, then you need to pay a bit more attention to the organization. Your hint that you have a problem in this regard is your table of contents: you are spending roughly 12 pages to describe what you label as “High Level Architecture”. Section 3 needs to be sufficiently succinct that it fits into Section 1. Otherwise it must be combined into Section 4, which in turn could be broken up into major sections. I also would have expected something of a mapping between Sections 3 and 4: that is, high level in one, details in the other. But that’s not really what we get. Section 3.7 and 3.8 feel as though it really belongs in Section 4. * Section 4.4.3 positions the future work at PAW. This is what enables the “deterministic thing” and is the major mode of operation in the pre-6tisch art of process control network. We could not really ignore it. The split with a high level architecture is a result of a review by Ralph long ago. Ralph expected a succinct high level architecture and the doc with section 3 and 4 as one was too deep and wide. I agree with you that 3.7 and 3.8 could move to section 4, this would reduce section 3 down to 8 pages and get us closer to what Ralph expected I guess. I think Ralph and I were agreeing in principle, then. * * The outlook of the ToC would then be: 2. Terms and References . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 11 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12 3.1. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 12 3.2. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 14 3.3. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 14 3.4. Routing and Forwarding Over TSCH . . . . . . . . . . . . 16 3.5. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 17 3.6. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 19 4. Architecture Components . . . . . . . . . . . . . . . . . . . 20 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 20 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 21 4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 21 4.2. Network Access and Addressing . . . . . . . . . . . . . . 22 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 22 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 24 4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 26 * Works? The only real issue is whether Sections 1 and 3 can be combined, and I would not stand on my head on it. The key thing is to make sure that people can gain a clear understanding of what the architecture is trying to achieve in Section 1, and then how it does so. The closer those two textual components are at the high level, the better you will be. But that’s just me, and others may see this differently, and it is general (non-IoT) advice. Ø I’ll keep that in mind for the next round * While there are some illustrations, there are not any examples of how this stuff is intended to function in practice. I will readily concede that examples are hard to write and get right, but they’re still important, and perhaps nowhere more-so with your AND and OR discussion in Section 4.7.2. My suggestion is that you seriously consider the validity of any component that you cannot show an example for. I think visualising schedules in several instances would help, for example. * will do, but that will take time and I do not want to hold my answer : ) * You have quite a number of groupings and disparate explanations of them. In this document alone you have cells, slots, slot frames, bundles, tracks, and packets. These are fundamental to your architecture. There needs to be a single section that introduces these, and shows how they fit together. It is not necessary in this introductory session to detail every aspect of these groupings, but simply to show their relationship to one another. You have a lot of the right diagrams in Sections 3 and 4, but one wants to understand the big picture before delving into the components. * I can do that too, and place text in section 2 or 3. There is a difficult tension between the desire to shrink those sections that you expressed earlier and the request you’re making here. You addressed this, I think in the other email. * * Sections 2.2, 2.3, and 2.4 should be combined and reduced. Keep in mind that the style of the IETF is to define on first use. What you want to avoid is the reader having to continuously flip back to the glossary. People aren’t reading this stuff on paper anymore. You might think this a minor issue. However, what you have told me, your dear reader, in Section 2.3 in particular is that I am unlikely to understand this architecture without having a full understanding of a year’s worth of reading, when that’s clearly not the case. * Problem there. We were asked to merge the 6TiSCH terminology document https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10 into the architecture to save RFC numbers and IESG cycles. We already used “define on first use” but the terminology was also useful when coming back to the doc or not reading it serially, as well as when reading another draft from the WG. I can move it to the appendix if that looks better, but I do not think we should eliminate or shrink dramatically what used to be a WG document just like that. We could try to convince Suresh (cc) to resplit but there is little hope. My suggestion is still to consolidate Terminology and Glossary. References don’t go in the front. * There I distinction between the externam acronyms that come from outside sources and the 6TiSCH terminology. A merge would make it look like we define 6BBR here, which is not the case. The format used here echoes the one that went through successfully in RFC 8505. People found useful that all this IOT jargon * I see I need to rename section 2.3. It is not a “reference” but a useful reading section. RFC 8505 called it “related documents” and calls terminology “New terms”. Is that better? * • To this end, you should include in your introduction something like Figure 4 that introduces the components. You might also state some of the operating assumptions of the devices involved, and focus on a few use cases as to how it would be applied (see examples above). * Will do; I’ll come back to you when I have progressed on all the above and probably published a rev so you can diff through easily. Note that again, this goes against a desire for increased conciseness. My understanding of what you describe looks a lot like a full book on 6TiSCH. I have no time to write that, I would if I did, and the reader is probably not expecting that from an IETF specification Minor issues * You are referencing BCP 14 but not really using it. If you are referencing it to explain that you do not mean to be making normative statements, I think it is best to plainly say just that. * It’s a nits thingy since we are going for std track. I’ll let the IESG sort that out with the DetNet architecture and will mimic when they are done. I don’t think you intend this draft to be normative. By saying that clearly, you will save potential confusion; as in when in doubt, go find the normative reference. Ø I know it looks strange. The original intent was to go for Informational. But discussing the detnet architecture that I also co-author, we found rationale for going standard track, pretty much related to getting an appropriate review level for a doc that concerns outside of IETF bodies like IEEE. The IESG is looking at the case for the detnet architecture now. My take is that this doc should follow the same path for the same reason. Not sure which that will be : ) Many thanks! Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
