-----邮件原件----- 发件人: Pascal Thubert (pthubert) [mailto:pthubert@xxxxxxxxx] 发送时间: 2019年6月28日 0:37 收件人: Qin Wu <bill.wu@xxxxxxxxxx>; ops-dir@xxxxxxxx 抄送: 6tisch@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6tisch-architecture.all@xxxxxxxx; Eliot Lear (elear) <elear@xxxxxxxxx>; Carlos Pignataro (cpignata) <cpignata@xxxxxxxxx> 主题: RE: Opsdir last call review of draft-ietf-6tisch-architecture-22 Hello Qin I looked at it again and found that it was great to move 3.8. Communication Paradigms and Interaction Models . . . . . 21 [Qin]: Can we remove it or consolidated it into other existing sections. I don't see this section adds anything besides providing a bunches of references. But not such a great idea to move 4.2. Network Access and Addressing . . . . . . . . . . . . . . 23 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 23 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 25 So my suggestion for the latter is to better introduce the join process and the registration in section 3.1. Proposed text: ' 6TiSCH nodes join a mesh network by attaching to nodes that are already members of the mesh (see Section 4.2.1). The security aspects of the join process are further detailed in Section 6. In a mesh network, 6TiSCH nodes are not necessarily reachable from one another at Layer-2 and an LLN may span over multiple links. This forms an homogeneous non-broadcast multi-access (NBMA) subnet, which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND operations in this type of subnet. Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses and register them using 6LoWPAN ND. This guarantees that the addresses are unique and protects the address ownership over the subnet, more in Section 4.2.2. ' Does that work? [Qin]: Much better, thanks. Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: jeudi 27 juin 2019 16:48 > To: Qin Wu <bill.wu@xxxxxxxxxx>; ops-dir@xxxxxxxx > Cc: 6tisch@xxxxxxxx; ietf@xxxxxxxx; > draft-ietf-6tisch-architecture.all@xxxxxxxx; > Eliot Lear (elear) <elear@xxxxxxxxx>; Carlos Pignataro (cpignata) > <cpignata@xxxxxxxxx> > Subject: RE: Opsdir last call review of > draft-ietf-6tisch-architecture-22 > > Hello Qin > > Many thanks for your review and for the important amount of time you > obviously spent on our work. This is really appreciated. > Please see below: > > > By looking at high level architecture section, it is hard to create > > a whole picture for what this architecture looks like and how these > > architecture component can be put together. Also architecture > > components defined in architecture component section seem not to > > align with high level architecture section. For Some architecture > > component,e.g.,Communication Paradigms and Interaction Models, > > Network access and addressing haven't appeared in the high level architecture first. > > This is an interesting comment. > > If you look back at say, draft 18, the sections in the high level > architecture have been modified and quite a bit of text went from section 3 to section 4. > The reason is that the first reviews we got from outside the WG told > us to shrink section 3 to the minimum, which caused us to move text to section 4. > > I'm intrigued by your comment " seem not to align with high level > architecture ". This is certainly something we need to act upon; but > there is a difference between the fact that a discussion appears only > in section 4 and a misalignment, which I read as a discrepancy or an > inconsistency in the architecture. Could you please provide > suggestions on where to focus without undoing what we did for the > previous reviewers? If this is about moving text back to section 3, I > generally agree but need to confirm with the original reviewers (cc), more below. > > > A few editorial comments and suggestions > > 1.Section 1 IT and OT should be part of terminology section too. > > Expanded both in first use and added a terminology for OT. IT is a bit > too obvious for a terminology section isn't it? > " > <t hangText="Operational Technology:"> > OT refers to technology used in automation, for instance in > industrial control networks. The convergence of IT and OT is > the main object of the Industrial Internet of Things (IIOT). > " > > > 2.Section 2 > > ND-proxying and binding should provide reference,e.g.,RFC4389 > > Well, this reference would be misleading because it considers specific > network models that are not the one we need in 6TiSCH. So we refrained from using it. > Turns out that there is no IPv6 RFC that would be equivalent to ARP > proxya and that we could reference. That's until now since we are > doing the backbone router. Which is what the architecture discusses > later. Sorry but I have no clean path to fix this... > > > 3.Section 3 I > > think Architecture Components Defined in section 4 should be > > consistent with high level architecture, e.g.,Network access and > > Adressing component seems not to be discussed in high level > > architecture > section. > > See https://tools.ietf.org/html/draft-ietf-6tisch-architecture-17 > section 3.7, that subsection was in section 3. This is how I thought it should be structured. > But then it was moved to 4 on request of a previous IESG review to > improve the clarity y making section 3 more concise. I'm happy to > move it back but cc the original reviewers to make sure we all agree on the final result. > > Please confirm that this is effectively your recommendation. > > > 4. Section 3.1 figure1 > > NME and PCE should be part of terminology section > > > Added terminology + verified that the terms are expanded in first use. > Note that I got the exact reverse remark from another reviewer, said > something like expanding in first use is the IETF way and sufficient. > A hint that there is no perfection ; ) > > 5.Section 4.3.1.1,1st > > paragraph The first sentence should not belong to this section since > > this section focuses on introduction of Hard cell. > > Agreed; moved above the section boundary. > > 6.Section 4.3.1.1, Section 4.3.1.2 > > Two section seesm only to discuss how to use hard cells or soft > > cell, but doesn't define what it is. Please clarify the difference > > between hard cell or > soft > > cell > > Actually it does but it could be a lot more clear. > > Proposed text: > > On hard cells > > "Hard" cells are cells that are > are owned and managed by a separate scheduling entity (e.g. a PCE) > that specifies the slotOffset/channelOffset of the cells to be > added/moved/deleted, in which case 6top can only act as instructed, > and may not move hard cells in the TSCH schedule on its own. > > On soft cells > > In contrast, "soft" cells are cells that 6top can manage locally. > 6top contains a monitoring process which monitors the performance of > cells, and can add, remove soft cells in the TSCH schedule to adapt > to the traffic needs, or move one when it performs poorly. > > > > 7. Section 4.4 How this section is related to high level > > architecture described in section 3 > > If that is what you have in mind, yes, this section is mostly an > introduction to sections 4.5 to 4.8. > If that corrects the issue as you see it, then I agree to move it to section 3. > Please confirm that this is effectively your recommendation. > > > > 8. Section 4.5.3 The content in section 4.5.3 is badly written and > > hard to understand. By reading the first paragraph of section > 4.5.3, > > it is hard to get sense of what remote monitoring and schedule > > management means and how reproduced figure 10 is related to remote > > monitoring and schedule management. > > How Remote monitoring and schedule management is different from > > other scheduling mechanism. Please rewrite. > > It is effectively a DetNet/SDN model whereby the controller assigns > physical resources in the form of time slots. > I can add text at the beginning of the section: > > before > " > The work at the 6TiSCH WG is focused on non-deterministic traffic and > does not provide the generic data model that would be necessary to > monitor and manage resources of the 6top sublayer. It is recognized > that CoAP can be appropriate to interact with the 6top layer of a > node that is multiple hops away across a 6TiSCH mesh. > > The entity issuing the CoAP requests can be a central scheduling > entity (e.g. a PCE), a node multiple hops away with the authority to > modify the TSCH schedule (e.g. the head of a local cluster), or a > external device monitoring the overall state of the network (e.g. > NME). It is also possible that a mapping entity on the backbone > transforms a non-CoAP protocol such as PCEP into the RESTful > interfaces that the 6TiSCH devices support. > " > After > > " > Remote monitoring and Schedule Management refers to a DetNet/SDN > model whereby an NME and a scheduling entity, associated with a PCE, > reside in a central controller and interact with the 6top layer to > control IPv6 Links and Tracks (Section 4.6) in a 6TiSCH network. The > composite centralized entity can assign physical resources (e.g., > buffers and hard cells) to a particular Track so as to optimize the > reliability within a bounded latency for a well-specified flow. > > The work at the 6TiSCH WG focused on non-deterministic traffic and > did not provide the generic data model that is necessary for the PCE > to monitor and manage resources of the 6top sublayer. This is > deferred to future work, more in Appendix A.2.2. > > " > > Note that since we do not do the work, it is too early to presume that > CoAP and PCEP will be finally adopted for this purpose and the > references are removed. > > > 9. Section 7 Too many thanks in the acknowledgment section, suggest to > simplify it. > > This is the only place where I really disagree. Those people helped. > The WG has been on this spec for 5+ years. I do not see why it hurts to recognize them. > > > 10.Appendix A not sure the > > importance of this part and how these related work are related to > architecture > > or section 2.3. Suggest to remove this appendix or consolidate some > > text > with > > section 2.3. > > Then again your suggestion is how I would have done it and actually > did in earlier versions. The text moved to appendix due to IESG > review; we got a concern that the architecture had too many > references to incomplete work, so the text was moved. Since there were > 3+ reviewers indicating the issue, I'd rather not undo if that's OK with you. > > Please
