Re: Last Call: <draft-ietf-roll-rpl-11.txt> (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]