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

["Ralph Droms (rdroms)" <[e-mail]>]

> On Dec 9, 2015, at 3:58 AM 12/9/15, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> Hello Ralph:
> 
>> 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, ???

This is the key question I was trying to get an answer for.  I think what I read below is that the intention for this document is to define "a set of rules for simplest operation of an 6TiSCH network".


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

OK.

>> 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 key question is whether this document aimed at a description of how to use IEEE 802.15.4 TSCH or 6TiSCH.  As the goal is a description of 6TiSCH, a description of how to use RPL is, of course, appropriate.

> 
>> 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 still think tying the join process to the use of RPL is a bad idea, but that's a minor design point for the WG.

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

I apologize if I appear to be wordsmithing (or even bikeshedding).

I don't think the first sentence is right.  I think what this document describes is a simple mode of operation to provide IPv6-over-6Tisch service.  The motivation for this mode of operation is testing, initial deployment and/or "required to implement" to provide a baseline of interoperability.  I think the focus should be on the purpose of the document as a whole and the details of the scheduling mechanism can be left for the Introduction.


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

Good - a crisp definition of "6TiSCH" is critical.

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

What about all the other protocols required to run an IPv6 network?

I would assume that the reader knows about IEEE 802.15.4 TSCH, RPL, etc., and their principles of operation.  In the interest of conciseness, I recommend eliding motivations and descriptions of protocols that are available elsewhere.  If I were reading this document, I would want to know what protocols I need to implement, what is the default operation of those protocols, what operational parameters a device will receive through the network, what defaults a device should use for other operational parameters.

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

On reflection, I think this charter item is incomplete.  It focuses on only two aspects of how to build a simple 6TiSCH network: scheduling and routing.  A complete IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND, address management, prefix management, etc.

Ideally, this document would be paired with a complete IPv6-over-6TSCH specification, so that this document specifies only those particular operational parameters required for the simple subset of the IPv6-over-6TSCH specification.  I understand that there is a circular dependency in that it's likely this simple 6TiSCH definition will be needed for development and testing before a complete 6TiSCH definition is published.  In that case, this document will need to be a standalone document and include descriptions of how to use all of the protocols required for 6TiSCH service.

> 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
> 
>> -----Original Message-----
>> From: Ralph Droms (rdroms)
>> Sent: mardi 8 décembre 2015 15:56
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal
>> 
>> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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 really need to get clarity on the purpose and scope of the document before I
>> can continue my re-review.
>> 
>> - Ralph
>> 
>>> On Nov 30, 2015, at 7:20 AM 11/30/15, 6tisch issue tracker
>> <[e-mail]> wrote:
>>> 
>>> #40: Ralph's INT AREA review on minimal
>>> 
>>> 
>>> Comment (by [e-mail]):
>>> 
>>> Xavi addressed comments one by one, tracked under bitbucket as
>>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
>>> All issues are solved but the intended status that we will track with
>>> a separate ticket
>>> 
>>> --
>>> -----------------------------------+----------------------------------
>>> -----------------------------------+--
>>> Reporter:  [e-mail]     |       Owner:  [e-mail]
>>>   Type:  defect                 |      Status:  new
>>> Priority:  major                  |   Milestone:  milestone1
>>> Component:  minimal                |     Version:  1.0
>>> Severity:  Submitted WG Document  |  Resolution:
>>> Keywords:                         |
>>> -----------------------------------+----------------------------------
>>> -----------------------------------+--
>>> 
>>> Ticket URL:
>>> <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:1>
>>> 6tisch <https://tools.ietf.org/6tisch/>
>>> IPv6 over the TSCH mode of IEEE 802.15.4e
>>> 
>>> _______________________________________________
>>> 6tisch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tisch
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch