ietf
[Top] [All Lists]

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

2010-09-08 01:53:31
Le 03/09/2010 07:54, Pekka Savola a écrit :
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.

I think this comment makes sense.  There was an important draft at some
point discussing why MANET protocols are not enough and why new protocol
was needed.  That WG item was used to motivate the new at that time ROLL
Charter requesting a new protocol design.  However, that draft was
discard soon after and not revived.  I believe that was an error: WG
items are never dropped, even less when they're used to motivate further
Charterer work.   That can still be corrected (revive
draft-ietf-roll-protocols-survey-07).

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.)

I agree the document is not very clear about how address configuration
is performed.  For example, it says nothing about the use of link-local
addresses - this silence is very wrong.

Another potential error lies in this RPL text:
Prefix Length  8-bit unsigned integer.  The number of leading bits
in the Prefix that are valid.  The value ranges from 0 to 128. The
prefix length field provides necessary information for on- link
determination (when combined with the L flag in the prefix
information option).  It also assists with address autoconfiguration
 as specified in [RFC4862], for which there may be more restrictions
 on the prefix length.

Does this mean that the prefix in a DIO is used for address
autoconfiguration, instead of a PIO in rfc4861?  I guess yes, and it is
wrong, because it is a new address autoconfiguration mechanism and it
says nothing about how it interacts with the old.

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).

I agree!  The RPL protocol seems to be designed for a non-Internet
network.  It seems to need more refinement before interoperating with
other IPv6 nodes.

Alex

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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf