We are good now, please make sure everything coherent in the update,thanks.
发件人： Pascal Thubert (pthubert)<pthubert@xxxxxxxxx>
收件人： Qin Wu<bill.wu@xxxxxxxxxx>;ops-dir<ops-dir@xxxxxxxx>
抄送： 6tisch<6tisch@xxxxxxxx>;ietf<ietf@xxxxxxxx>;draft-ietf-6tisch-architecture.all<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
时间： 2019-06-28 18:56:02
Many thanks Qin !
I posted -23 in the hope that it satisfies all your comments. Please let us know is there is any additional issue we need to look at.
All the best,
Pascal
De : Qin Wu <bill.wu@xxxxxxxxxx>
Envoyé : Friday, June 28, 2019 8:57:22 AM
À : Pascal Thubert (pthubert); ops-dir@xxxxxxxx
Cc : 6tisch@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6tisch-architecture.all@xxxxxxxx; Eliot Lear (elear); Carlos Pignataro (cpignata)
Objet : RE: Opsdir last call review of draft-ietf-6tisch-architecture-22
Envoyé : Friday, June 28, 2019 8:57:22 AM
À : Pascal Thubert (pthubert); ops-dir@xxxxxxxx
Cc : 6tisch@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6tisch-architecture.all@xxxxxxxx; Eliot Lear (elear); Carlos Pignataro (cpignata)
Objet : RE: Opsdir last call review of draft-ietf-6tisch-architecture-22
-----邮件原件-----
发件人: 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
发件人: 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
