#39: Ralph's INT AREA review
I am an assigned INT directorate reviewer for draft-ietf-6tisch-
minimal-12. These comments were written primarily for the benefit of the
Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any
other Last Call comments that have been received. For more details on the
INT Directorate, see http://www.ietf.org/iesg/directorate.html.
Review submitted by Ralph Droms
Summary: In my opinion, the WG needs to reconsider some of the fundamental
aspects of this proposed specification, and the document needs significant
restructuring and editing. I will be happy to work with the WG to revise
the document and review future revisions.
There may be overlaps between my comments and those in other reviews
because I avoided reading those reviews before writing up my review.
Here are my comments on the document. The first four comments apply to
the document as a whole, while the remainder address more specific issues,
roughly in the order of appearance in the document.
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 have a question about this text from section 7.2:
When a node joins the network,
it MUST NOT send EBs before having acquired a RPL rank. This avoids
routing loops and matches RPL topology with underlying mesh topology.
What is meant by "avoiding routing loops"? My understanding is that IEEE
802.15.4 TSCH simply provides for frame delivery between neighbors and
does not provide frame forwarding. How would routing loops arise from
running IEEE 802.15.4 TSCH?
Has the WG considered reorganizing the 6TiSCH protocol suite and documents
to separate the minimal operation of IEEE 802.15.4 TSCH from
IPv6/RPL/ND/etc? For example, has the WG considered allowing a simpler,
initial Join Priority scheme that would provide minimal IEEE
802.15.4 TSCH operation until the full IPv6 suite is running, at which
time RPL will provide optimal routing.
3. Restatement of specifications in IEEE 802.15.4 documents
I haven't read the most recent IEEE 802.15.4 docs and it has been a while
since I took a close look at earlier revs. With that disclaimer in mind,
how much of the text in sections 3 through 9 is a restatement of the IEEE
802.15.4 specification and how much is the specification of operational
parameters for minimal operation of a IEEE 802.15.4 TSCH network?
Restatement of specifications can be confusing and lead to a lack of
interoperability. As a small example, here is section 6:
6. Acknowledgment
Link-layer acknowledgment frames are built according to [IEEE802154].
Unicast frames sent to a unicast MAC destination address MUST request
an acknowledgment. The sender node MUST set the ACK requested bit in
the MAC header. The acknowledgment frame is of type ACK (frame type
value 0b010). Each acknowledgment contains the following IE:
ACK/NACK Time Correction IE: The ACK/NACK time correction IE
carries the measured de-synchronization between the sender and the
receiver. Refer to Section 11.3 for an example of the Header IE
content. The possible values for the Time Synchronization
Information and ACK status are described in [IEEE802154].
Out of that section, it seems to me that the first sentence is harmless,
the second sentence is a specification for this document, the third and
fourth sentences are a restatement of [IEEE802154] and the fifth sentence
is an inferred specification for this document. The description of the IE
is a restatement of [IEEE802154].
Section 6 could be rewritten as:
6. Acknowledgement frames
Unicast frames sent to a unicast MAC destination address MUST request
an acknowledgment. Each acknowledgment MUST contain an ACK/NACK
Time Correction IE.
4. Default behavior versus learned behavior
Which of the configuration and operational specifications in this document
must be pre-configured before a node joins the network, and which are
learned through, e.g., EBs. Are operational control and management
questions out of scope for this document, such as:
- when does a node switch from the "minimal 6TiSCH configuration" to
some other configuration?
- does a node use the configuration parameters it has received
through EBs to generate its own EBs or does it use the "minimal
6TiSCH configuration" parameters?
5. In this text from the Introduction, does "synchronizes with the
network" mean time synchronization or something else:
[...] when a node synchronizes to the network.
6. I don't think the last sentence of the Introduction is relevant to an
Introduction.
7. The document could use a section on the terminology used in the
document, to provide definitive sources for definitions of the various
terms and acronyms used in the document. Most likely, the terminology
section would simply point to relevant sections of [IEEE802154] and [I-D
.ietf-6tisch-terminology].
8. Section 11 should be an Appendix, rather than part of the body of the
document, so as to avoid making those examples normative standards text.
9. I think the contents of section 7.1 are entirely dependent on the
specifics of an implementation and the section should be omitted.
10. I think the information in section 8 would be more generally useful if
not stated in terms of a queue-based implementation:
A node must not transmit frames containing higher-layer packets until
the node has successfully joined a network.
Frame types BEACON and ACK
Frames generated by the IEEE 802.15.4 layer are transmitted before
frames containing higher-layer packets.
11. According to [I-D.ietf-6tisch-terminology], the correct term is
"timeslot", so s/time slot/timeslot/ throughout the document.
12. In the table at the top of page 4 (BTW, please number and add a title
to all tables), are the listed properties the only properties that have
numeric or short text string values? If not, all of those properties
should be gathered together into a single table. As an editorial aside,
this table is pretty much what I expected to be the bulk of this document.
13. Even if the number of timeslots in a slotframe is variable for this
minimal configuration, should there be a default?
14. In the table at the top of page 5, what do the empty boxes represent?
15. The last sentence of section 3.2 seems to be a low-level
implementation detail that can be omitted.
16. Without having read the IEEE 802.15.4 docs recently to confirm, I'll
suggest that almost all of section 3.4 is a restatement of the IEEE
802.15.4 spec. The last sentence is important, and isn't entirely clear.
It would be clearer to write:
For the minimal configuration specified in this document, the use
of CCA is OPTIONAL.
17. End of section 3 - not clear when to use macTimeslotTemplate.
18. The third paragraph of section 4 is completely unclear to me:
A Node aiming to join the network by receving a properly formed
BEACON shall enter in a scan phase and shall store the value of
macPANId and then set it to 0xffff for the duration of the scan in
order to meet the filtering rules in [IEEE802154].
What are "macPANId" and "scan phase"? I don't see those terms used
anywhere else in this document; do the terms come from the IEEE
802.15.4 specs? Why would an implementation store the value of macPANId
and then set it to 0xffff?
19. Does "synchronization" in section 5 mean "time synchronization"?
20. In section 5, is "EB_PERIOD" the same value as defined in the table in
section 10.2.4 that defines "RPL-related variables"? If so, I don't
understand why "EB_PERIOD" is in that table, as it only appears once in
the rest of the document in section 5.
21. I see that section 10 includes the statement:
Nodes in a multihop network MUST use the RPL routing protocol
[RFC6550].
This statement is certainly false if one takes a broad definition of the
word "multihop". Even if edited to "multilink subnet" or "mesh", I can't
find any support in RFC 6550 for the statement "MUST use RPL routing
protocol". I think it would be much clearer and more correct to quote
verbatim the text describing this requirement from RFC 6550 rather than
paraphrasing it here.
Similarly, this sentence in section 10.1 needs, at least, to be edited,
and I think it should be replaced with quoted text from RFC 6552.
Nodes in the multihop network MUST implement the RPL Objective
Function Zero [RFC6552].
While I haven't provided a detailed review of the remainder of section
10 because I don't think it's necessary for the goals of this document, it
appears to me that much of section 10 is a restatement of the RPL
specification from RFC 6550 and should, therefore, be omitted (if RPL is
retained as a part of this recommendation).
--
--------------------------------+--------------------------------
Reporter: [email protected] | Owner: [email protected]
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: architecture | Version: 1.0
Severity: Active WG Document | Keywords:
--------------------------------+--------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/39>
6tisch <http://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
