I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-roll-rpl-11.txt
Reviewer: Brian Carpenter
Review Date: 2010-08-28
IETF LC End Date: 2010-09-01
IESG Telechat date: 2010-09-09
Summary: In good shape, some issues and questions
--------
This draft is 139 pages long so my review is inevitably superficial.
I have not reviewed the packet formats and protocol details.
However, I'd like to congratulate the authors and WG: for a
document of this size, it's very well structured and is actually
readable.
Also, the writeup says:
> During the course of the design of this document, a number of implementations
> have been reported (more than 10) and two interoperability events took place
> under the control of the IPSO (IP for Smart Object) alliance and the Zigbee
> alliance. Interoperability results were shared on the ROLL WG mailing list,
> concerns have been addressed and all issues known so far have been fixed.
This is good news. I still have quite a few questions and some issues
below; please excuse me if these have been asked and answered already, but
this is a new topic to me.
Questions:
----------
Is a sub-DODAG a DODAG?
All the examples shown in Fig 1 and Fig 2 are trees. The definition
of a DODAG doesn't seem to be restricted to trees. Are Fig 1 and 2
DODAGs, or are they spanning trees over DODAGs?
> 3.6. Rank Properties
>
> The rank of a node is a scalar representation of the location of that
> node within a DODAG Version. The rank is used to avoid and detect
> loops, and as such must demonstrate certain properties. The exact
> calculation of the rank is left to the Objective Function, and may
> depend on parents, link metrics, node metrics, and the node
> configuration and policies.
I can read the words, but I don't understand what constraints on, and properties
of, the objective function are needed in order to guarantee that the resulting
rank meets the rules and therefore guarantees loop detection. Is there some
graph theory behind this? (You say a bit later that "The Objective Function
itself is decoupled from the routing metrics and constraints used by RPL.",
but the rank computed by the objective function is surely not going to be
decoupled from them.)
Note added later: a forward reference to Section 14 would help the reader.
> 11.2.2.1. Instance Forwarding
>
> RPLInstanceIDs are used to avoid loops between DODAGs from different
> origins. DODAGs that are constructed for antagonistic constraints
> might contain paths that, if mixed together, would yield loops.
I may have missed it, but does this depend on the assertion that a given
RPL Instance is guaranteed loop-free? If so, how is that assertion proved?
Major issues:
-------------
> 3.3.7. Datapath Validation and Loop Detection
>
> RPL carries routing information in a RPL Option contained in an IPv6
> Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option].
I'm aware that this choice was a major discussion point and that using
the IPv6 Flow Label to support RPL was rejected for very sound reasons.
However, I can't help worrying about the impact of this overhead
on packet size and processing load in the ROLL context. More generally,
RPL is complicated, and that means memory, processing, and bits on
the wire. This whole approach seems to call for a rationale, either
as an Appendix to this document, or as a separate Informational document.
I don't see any trace of this in the WG charter pages.
> 3.3.8. Distributed Algorithm Operation
...
> It is up
> to the end-to-end application to select the RPL instance to be
> associated to its traffic (should there be more than one instance)
> and thus the default route upwards when no longer-match exists.
This worries me quite a bit. We have a long history of not expecting
applications to know anything about routing, and now we expect them
to select a routing instance? How is that going to happen? Will there
be a default choice of RPL instance?
Minor issues:
-------------
The Abstract seems too long and (unnecessarily) complicated (by parentheses).
Not all terminology is defined in Section 2. I noticed that DIO and DAO were
missing, for example, and I had to search around as a result.
> 3.3.8. Distributed Algorithm Operation
...
> o Nodes provision routing table entries, for the destinations
> specified by the DIO message, via their DODAG parents in the DODAG
> Version. Nodes that decide to join a DODAG MUST provision a DODAG
> parent as a default route for the associated instance.
It isn't clear how a node knows which DODAG parent to use. Maybe this is made
clear later, but the reader wants to know now.
There are numerous instances of "out of scope for this document." It would be
very useful to provides hints of whether these are covered in companion
documents, will be covered in planned documents, or are truly for future study.
Some of these items seem quite fundamental for deployment, e.g.
> Mechanisms
> for allocating and provisioning global RPLInstanceID are out of scope
> for this document.
> 11.1. Suggestions for Packet Forwarding
I'm more used to seeing sending *rules*, not suggestions. Is this section
as a whole a MAY or a SHOULD, and what are the alternative "suggestions"?
...
> 3. If the packet header specifies a source route by including a RH4
> header as specified in [I-D.ietf-6man-rpl-routing-header], then
> use that route. If the node fails to forward the packet with
> that specified source route, then that packet SHOULD be dropped.
It is not at all clear when to ignore the SHOULD or what the alternatives
to dropping the packet are. Where will we send it if the source route is
broken?
> 11.2.2.1. Instance Forwarding
...
> In
> that case, the source of the packet MAY tag the flow label with the
> RPLInstanceID.
I believe the authors intend to delete this sentence. It's the remnant
of a previous idea.
> 14.1. Objective Function Behavior
...
> o An OF computes self's rank by adding to the rank of the candidate
> a value representing the relative locations of self and the
> candidate in the DODAG Version.
This is not a well-constructed English sentence. What is "self"? Does
it mean the device in which the OF is running? And the phrase starting
"a value" is very obscure. What is "relative locations"? Please rewrite
this sentence; I suspect it needs to be expressed in two or three
separate sentences.
There are several further uses of the word "self" in the following bullets,
all of which don't work as English sentences. You need to choose a noun
that works in English and define it precisely. Maybe "the node in which a
given instance of the OF is running"?
Nits:
-----
17.2.1. Initialization Mode
"Architectural Principles of the Internet" [RFC1958], Section 3.8,
states: "Avoid options and parameters whenever possible. Any options
and parameters should be configured or negotiated dynamically rather
than manually. This is especially true in LLNs ...
The closing quotation mark is missing from the extract from RFC 1958.
[sha2] "FIPS Pub 180-3, Secure Hash Standard (SHS)", ,
February 2008.
That reference is incomplete. I had to work quite hard to find
http://www.nist.gov/itl/upload/fips180-3_final.pdf
== Outdated reference: A later version (-04) exists of
draft-ietf-roll-trickle-02_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
