Subject: [6tisch] Opsdir last call review of draft-ietf-6tisch-architecture-22

From: Qin Wu via Datatracker <[email-masked]>
Date: Wed, 26 Jun 2019 21:46:54 -0700

Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

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
 LowPower wireless deterministic applications.

Major issue:
Not found

Minor issue:
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. A few editorial comments and suggestions 1.Section 1
IT and OT should be part of terminology section too. 2.Section 2 ND-proxying
and binding should provide reference,e.g.,RFC4389 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. 4. Section 3.1 figure1 NME and
PCE should be part of terminology section 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. 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 7. Section 4.4
How this section is related to high level architecture described in section 3
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. 9. Section 7 Too many thanks in the
acknowledgment section, suggest to simplify it. 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Jun 2019 14:47:43 +0000

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:

> 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.
> 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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Jun 2019 16:37:15 +0000

Hello Qin

I looked at it again and found that it was great to move 

     3.8.  Communication Paradigms and Interaction Models  . . . . .  21

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?

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: jeudi 27 juin 2019 16:48
> To: Qin Wu <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Eliot Lear (elear) <[email-masked]>; Carlos Pignataro (cpignata)
> <[email-masked]>
> 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.
> 
> 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.
> 
> 
> Expanded both in first use and added a terminology for OT. IT is a bit too
> obvious for a terminology section isn't it?
> "
> 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.
> 
> Note that I got the exact reverse remark from another reviewer, said
> something like expanding in first use is the IETF way and sufficient.
> 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.
> 
> 
> 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.
> 
> 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