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, ???
>
> 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
> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: mardi 8 décembre 2015 15:56
> To: [email protected]
> Cc: [email protected]
> 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
> <[email protected]> wrote:
> >
> > #40: Ralph's INT AREA review on minimal
> >
> >
> > Comment (by [email protected]):
> >
> > 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: [email protected] | Owner: [email protected]
> > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
