Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-draft-kelsey-intarea-mesh-link-establishment-05.txt
Reviewer: Thomas Clausen
Review Date: 2013-09-13
IETF LC End Date: 2013-09-16
Intended Status: Proposed Standard
Summary:
========
I have some minor concerns about this document that I think should be resolved
before publication.
Comments:
=========
This document is generally well written, and easy to read.
I especially appreciate the the last paragraph of Section 15 "Security
Considerations"; while it is not a new technique (as is called out), it is
always of educational value to have such "tricks" called out and explained.
The document specifies several message types (or rather, one message type with
different "commands" - effectively, being "different message types sharing a
similar frame format"), TLV types, and other code-points, with "mini IANA
sections" scattered throughout the text defining these. While there is an IANA
section in the end of the document, I would much prefer seeing mnemonics used
for code points through the text, and with the IANA section assigning values
for these in a single location. It makes it easier to read "FooBar message"
rather than "message 42" ( or "message 42 (foobar)" ), easier to code, and less
prone to editorial snafu's.
Also, as the document specifies a number of TLVs, which MAY/MUST be included in
different messages, would it be possible to provide an overview/table
centralizing this information? If I was to go implement this protocol, my
inclination would be to have the parser "know" the required/forbidden TLVs for
each given message type, and reject on parsing based on that - and such a
table/overview would help.
Major Issues:
=============
Section 3, "Applicability":
I have an issue with the mention of MLE being blanket-applicable to also "other
radio standards" here. I find it to be too broad when stated unqualified.
It would be of great value if the applicability statement could point out the
boundaries within which MLE applies. What I am getting at is, if MLE applies to
simply /any/ L2, or if there are L2s where it either can't operate -- or, L2s
where it can't bring any benefit. Not in terms of "it works for IEEE XXX but
not for IEEE YYY", but in terms of "If a radio standard has the characteristics
ZZZ and WWW, MLE applies - but if it has the characteristics QQQ, then it
doesn't".
A secondary question here would be "why /radio/ standards"? Is there something
inherent in /radio/ that wouldn't also apply in - say - PLC, and which would
render MLE inappropriate there?
The reliance of the 802.15.4 security suite seems to indicate that there are
some requirements from an underlaying L2 that could be brought forward, for
example....
An alternative would be to scope this document narrowly to 802.15.4, which I
understand to be the targeted usecase, e.g.: "This applies to 802.15.4. It may
also be applicable elsewhere, but we do not know that, or how, yet."
Section 8 "Message Transmission":
Last paragraph before table with parameter states "Because MLE messages do not
require complex processing and are not relayed"....yet two paragraphs above, it
was stated "...allow update messages to be forwarded multiple hops" - does that
not exactly imply that some MLE messages /are/ indeed relayed? Later (Section
11, 2nd paragraph) it is even specified that for that relaying, "simple
flooding" is sufficient.
Minor Issues:
=============
Section 3 "Applicability":
While the motivation for MLE, given in previous sections, is clear, it is a
little unclear (by the use of the word "extends") here, in which fashion it is
for the IETF to "extend" a L2 protocol.
Would it be possible to say something like a variation over "This protocol
provides a support mechanism for using IEEE 802.15.4 for IPv6-based multi-hop
mesh networks".
Section 4 "Overview":
The first bullet point has to do with "links", presumably as defined by "pairs
of interfaces" (although, that's not entirely clear?). The last bullet point,
then, talks about devices.
How about devices with multiple interfaces on the same radio channel? Take the
simple case of two devices A (with interfaces a1, a2) and B (with interfaces
b2, b2), and where links being unidirectional (or, at least, useful in a
meaningful fashion only in one direction) a1->b1 and b2->a2. Bi-directional
communication between A and B is (in principle) possible, despite no single
bidirectional link between A and B. Is this case handled by MLE, or is that a
condition where MLE doesn't / can't /shouldn't apply? Later in the document, it
appears that MLE explicitly excludes non-bidirectional links, if so, calling
that out here would be helpful. Section 4.3 and Section 12 hint at, but
doesn't clarify, this issue entirely.
Section 5 and onwards:
While this protocol may follow the usual "custom" of byte order, endianness and
alignment/padding, and it is, occasionally, specified for some fields in some
messages/TLVs, I would suggest that what is used should be stated explicitly,
once, and up-front.
Section 10 "Link Configuration" and Section 11 "Parameter Dissemination":
I am a little surprised by the use of "SHOULD" in this, and the following,
sections; it would appear to me that most of the "SHOULD" really ought to be
"MUST", as they govern when messages are sent and what proper responses to
those messages are by receivers. Is there a subtlety that I am missing?
Nits:
=====
Section 7.7 "Link quality":
Suggest, for RES, "MUST be set to 000 on transmission, and SHOULD be ignored on
receipt"
Section 11 "Parameter Dissemination":
In 2nd paragraph, it is suggested that simple flooding is sufficient for
dissemination of these messages. That is quite likely true. If I may, I would
suggest explicitly calling out the need for implementing duplicate detection
for the flooding operation; it won't impact interoperability how exactly such
is done (unless doing so requires adding, say, an additional sequence number to
messages - if an existing and always available sequence number can be used, it
might help to call that out), but it will be harmful if a less-than-vigilant
implementer forgets this point.