On Wed, 18 Aug 2010, The IESG wrote:
The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks'
<draft-ietf-roll-rpl-11.txt> as a Proposed Standard
I've done a solicited but superficial ops-dir review of
draft-ietf-roll-rpl-11. Given the document length (139p) I've had to
skim most of it. The IETF Last Call expired two days ago, but for
information I'm still copying the IETF list, even though this review
is mainly for O&M ADs' and secondarily ROLL WG benefit.
A couple of comments:
In general, ROLL problem space seems to be very similar to MANETs, and
I wonder why a separate protocol needed to be developed here,
especially given the amount of scientific research and also IETF
effort put into MANETs. ROLL WG charter certainly does not mention
this.
Copying/modifying various IPv6 ND options for this purpose may be
required but I wonder if this could have been done in a simpler
fashion, without having to copy the specifications here. For example,
using a TLV container option that includes non-TLV options as-is.
The document mentions uniquely identifying a DODAG by the use of an
IPv6 address. The document does not mention what addresses are to be
used for this purpose, how they are assigned, and how these are
expected to be unique. (Compare to documents on MANET IPv6 address
assignments.)
In S 11 on Packet Forwarding:
1. This specification only covers how a successor is selected from
the DODAG Version that matches the RPLInstanceID marked in the
IPv6 header of the packet being forwarded. [...]
... How is RPLInstanceID marked in the IPv6 header of the packet being
forwarded? Are you modifying IPv6 packet forwarding and processing
algorithms here (must look into the packets)? That would be a major
change. (You're really referring to the hop-by-hop header processing here.)
In general the document doesn't seem to be sufficiently upfront on the basic
semantics how RPL is going to be used (from "non-RPL" perspective). One
could argue Section 3 (some 12 pages) tries to provide
an overview, but from IP perspective, it provides too much detail on e.g.
tree forming and maintenance. The most important things to bring up clearly
should be for example: (1) are there changes to existing packet formats or
usage (e.g. does every packet include some kind of header, does this affect
MTU usable in the network)?, (2) is support for these required at each node
in the network, (3) are there changes to the basic packet processing in
associated nodes?
Upon closer inspection, some answers to these high-level questions can
be found in first paragraph of S 3.3.7 and the last paragraph of S 5,
but I'd really have wanted to see one or two paragraphs in
Introduction.
...
It is a bit strange to see that S 17 on manageability does not mention
security management, because one of the key problems there (as argued
in the draft as well) is how do you manually configure and maintain
shared keys on all these devices.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf