RtgDir Review: draft-kelsey-intarea-mesh-link-establishment-05.txt

[Thomas Heide Clausen <[e-mail]>]

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.