Telechat Review of draft-kelsey-intarea-mesh-link-establishment-06
review-kelsey-intarea-mesh-link-establishment-06-opsdir-telechat-baker-2014-06-24-00

I am reviewing this for the Operations Directorate. I have a few questions. I
personally do not have experience in radio mesh networks, and as a result will
not be able to comment on the correctness or completeness of the protocol per
se. However, I’ve designed a few protocols, and found a few points surprising.

Was a reference implementation built and tested?

The author is an employee of Ember, which is now owned by Silicon Labs. This is
a positive thing; Ember is a vendor of mesh networking equipment, which
suggests that the author likely has experience and expertise. But it makes me
wonder what similarities this protocol might have to Ember/SL proprietary
products. There are no IPR disclosures, but I wonder whether there should be,
and I wonder whether the title should be “SL’s ...". Note that this is neither
an accusation nor an assertion. It’s a “due diligence” question, and with any
luck it has been asked and answered. I’m just not personally in possession of
the answer, and would like to be sure the AD is.

A nit relating to terminology; IP is at the “Network Layer”, and specifically
the “Internet” layer or sublayer. It is not the “Routing” layer, as routes are
developed not only in the IP network but in the various underlying networks it
connects. I would expect that a document approved by the IETF would use
language that the IETF consistently uses in its other documents.

Section 6 is entitled “Command format”; I take it from this that the protocol
is a member of a class of command/response or command/telemetry protocols.
Codes 1 and 3 (Link Accept and Link Request) are *responses* to codes 0 and 2,
at least from their names. Question: if these are “commands”, what action is
taken upon the receipt of the response messages - who is commanding whom to do
what? The section seems to me more of a “message format” than a “command
format”.

A question regarding the multicast distribution algorithm... The development
and specification of network multicast has been trying in the IETF, and is
generally not obvious. The answer to this question may be inherent in 802.15.4
multicast, which I’m not familiar with. However, I’m curious. IP multicast
tries to deliver a message exactly once to each member of a multicast group,
and in sequence. In a mesh network, that may not be possible and in any event
probably isn’t work the effort to achieve. However, a message should be
provably delivered to every node in the multicast group at least once, should
not be delivered unnecessarily often, and if it changes the state of the
network in some way, such changes should not be reordered. How does multicast
work in this network? Is it that every node that receives a message repeats it
once but not on subsequent receptions, and hopes for the best? Is there an
acknowledge number or bit pattern that would let a neighbor know that it had
missed something?

Are integers in this protocol in “network byte order”, aka “big endian?”

Section 8 refers to a site-local multicast address. This is not called out in
the IANA Considerations as needing to be assigned. The call-out, when added,
should refer to section 2.7 of RFC 4291.

Are the IP addresses used in this protocol IPv4, IPv6, or both? I’d suggest
that “IP” be defined as “IPv6” or globally replaced to read “IPv6", with
appropriate references to RFCs 2460 and 4291. In the RFC series, “IP” usually
is a reference to IPv4 for historical reasons.

The security considerations looks at the TTL to ensure that it is exactly 255.
That’s fine for unicast messages. With a multicast message, I would expect the
TTL to be decremented, and the decremented TTL to be accepted. Network
multicast is used to distribute network-wide parameters, if I understand this
correctly.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail