[6tisch] FW: #40 (minimal): Ralph's INT AREA review on minimal

["Pascal Thubert (pthubert)" <[e-mail]>]

I received the echo of the below truncated; there may be a weird character in there; in case you got it truncated too, I'm resending a copy plain text;

Pascal

> I had a hard time mapping from the points in my review to the issues 
> tracked in bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
> 
> In particular, I don't see where these comments were addressed:
> 
>  1. Goals and requirements are unclear
> 
>  The requirements for this document are unclear to me.  Exactly what  
> services would a "minimal mode of operation" provide?  The Abstract 
> and  most of the document talks about the operation of an IEEE 
> 802.15.4 TSCH  network, yet the title of the document is "Minimal 6TiSCH Configuration".
>  Does a network that follows these rules provide an L2 IEEE 802.15.4  
> service, an
> IPv6 6TiSCH service, ???
> 
>  Related to this question, does this document describe "a minimal set 
> of  rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of  operation"
> (both text snippets from the Abstract).


This issue is related with the next. I'll be proposing text at the end of this mail;

> 
>  2. Requirement for RPL is ill-advised
> 
>  This document seems to be focused on IEEE 802.15.4 TSCH operational 
> parameters.  Yet, it calls for the use of RPL, which seems to me to be 
> a  highly undesirable entangling of protocols at different layers of the  protocol stack.
> IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL.

6TiSCH includes the mesh support by default, which is kind of natural for 802.15.4 as opposed to, say, Bluetooth.
So we care to get interoperation at that level as well and include that in the minimum support. 

6TiSCH was put together to address the NBMA nature of the multihop network as opposed to considering only one hop, like BTLE does, which would probably be have been 6lo work. 

>  My understanding of the document is that RPL is assumed to be in use  
> because it is required in a 6TiSCH network.  RPL is then used to 
> generate  the Join Priority through the DAGRank function as specified 
> in section  7.2.  The use of RPL implies to me the configuration and 
> operation of a  full IPv6 stack, which hardly seems like a minimal mode of operation for  IEEE 802.15.4 TSCH.

Looks like a definition issue, maybe we can reword the intro. An abstract "minimal mode of operation for  IEEE 802.15.4 TSCH " does not need IP at all but that's not what we are defining here. We are defining a "minimal mode of operation for IPv6 over a IEEE 802.15.4 TSCH network", in other words the minimal thing that is needed to build a 6TiSCH network, which includes the capability to support multihop operation, which includes synchronization.

6TiSCH requires RPL for data and time synchronization over multiple hops. That capability is part of our bare minimum. If someone only cares for hub and spoke, then RPL is not needed, but supporting only that model is below the bar of the 6TiSCH bare minimum. 

> I looked at draft-ietf-6tisch-minimal-13, and I see that there are no 
> changes to the abstract or the introduction.  As I read that text, 
> this document is intended to give minimal operational parameters for 
> IEEE802.15.4 TSCH.  However, the title of the document is "Minimal 
> 6TiSCH Configuration" and the content goes far beyond the parameters 
> needed to run IEEE802.15.4 TSCH.  As an aside, I don't see any mention 
> of TiSCH or 6TiSCH in the document, other than in the title.

I agree, Ralph;

Proposals:



--------------
Abstract (before)

   This document describes the minimal set of rules to operate an IEEE
   802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal
   mode of operation can be used during network bootstrap, as a fall-
   back mode of operation when no dynamic scheduling solution is
   available or functioning, or during early interoperability testing
   and development.

----------
Abstract (after)

   This document describes the minimal set of rules to operate a 6TiSCH
   Network, which provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
   Timeslotted Channel Hopping (TSCH) links.  This minimal set only
   provides static scheduling, but it can be complemented in operating
   networks by distributed, or centrally controlled, dynamic scheduling
   extensions.

----------


------------



1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   The nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  The entity (centralized or decentralized) responsible for
   building and maintaining that schedule has precise control over the
   trade-off between the network's latency, bandwidth, reliability and
   power consumption.  During early interoperability testing and
   development, however, simplicity is more important than efficiency.
   One goal of this document is to define the simplest set of rules for
   building a TSCH-compliant network, at the necessary price of lesser
   efficiency.  Yet, this minimal mode of operation MAY also be used
   during network bootstrap before any schedule is installed into the
   network so nodes can self-organize and the management and
   configuration information be distributed.  In addition, the minimal
   configuration MAY be used as a fall-back mode of operation, ensuring
   connectivity of nodes in case that dynamic scheduling mechanisms fail
   or are not available.  The IEEE 802.15.4 specification provides a
   mechanism whereby the details of slotframe length, timeslot timing,
   and channel hopping pattern are communicated when a node time
   synchronizes to the network [IEEE802154].  This document describes
   specific settings for these parameters.


------------------------------

1.  Introduction

   A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
   Timeslotted Channel Hopping (TSCH) links.  

   Nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  An entity (centralized or decentralized) responsible for
   building and maintaining that schedule has precise control over the
   trade-off between the network's latency, bandwidth, reliability and
   power consumption. The degree of optimization that is obtained
   depends on the capabilities of the controlling entity and the acceptable
   complexity for a given deployment. In a minimal configuration,
   this controlling entity is omitted, and the schedule is static.

   The IEEE 802.15.4 specification provides a mechanism whereby the
   schedule, expressed as details of slotframe length, timeslot timing,
   and channel hopping pattern, is obtained by a node at the time it joins
   the network [IEEE802154].

   This specification defines a Minimal Configuration to build a 6TiSCH
   Network, using the Routing Protocol for LLNs (RPL) and a static TSCH
   Schedule.  The 802.15.4 TSCH mode, RPL [RFC6550], and its Objective
   Function 0 (OF0) [RFC6552], are used unmodified, but parameters and
   particular operations are specified  to guarantee interoperability
   between nodes in a 6TiSCH Network.
   
   More advanced work is expected in the future to complement the
   Minimal Configuration with dynamic operations that can adapt the
   Schedule to the needs of the traffic in run time.

        


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

------------------------------


The changes above attempt to address Ralph's comments, but also Brian's point that 2119 language should come after the introduction, and removes unnecessary text on particular usages which appeared to limit the applicability of the draft.



> I really need to get clarity on the purpose and scope of the document 
> before I can continue my re-review.

Yes; and ultimately the purpose is to match charter item 3:

"
3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is.

The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied in ROLL.
"

Huge thanks for your patience and your willingness help / make sure we do the right thing.

Take care,

Pascal