Hi Brian,
> 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>.
Thank you for your review.
>
> 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?
The sub-DODAG is itself a DODAG. Trees/spanning trees are a degraded form
of DODAGs. We do not intend to suggest that only trees can be used. We can
clarify this further in the text surrounding such examples.
Since trees are a degraded form of DODAGs, a deployment can be done in such
a way that only trees are built.
The appearance of trees as examples comes in part from the limits of ASCII
art. Perhaps we can add an extra link or two to such examples to make them
clearly less tree-like, but rapidly that will make the drawing unreadble.
>
> > 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.
>
The key property for enabling loop detection is this: A vector in the DODAG
MUST be oriented from a higher to a lower Rank, so as we follow the DODAG
towards the root, the Rank should always decrease. (Prior revisions did
have a concept of routing along siblings, but that was left to future study
and elaboration in order to simplify the base draft.
The intent in that specific text is only to point out that the objective
function may rely on any of these, or other, inputs in its computation of
Rank, as long as that resulting Rank conforms to certain properties. We
can clarify this in the text and add a reference to Section 14.
We can then clarify here :
Even though the specific computation of the rank is left to the
Objective Function, the rank must implement generic properties
regardless of the objective function.
In particular, the rank of the nodes must monotonically decrease
as the DODAG version is followed towards the DODAG destination.
In that regard, the rank can be regarded as a scalar representation
of the location or radius of a node within a DODAG Version.
The details of how the Objective Function computes rank are beyond the
scope of this specification, although that computation may depend, for
example, on parents, link metrics, node metrics, and the node
configuration and policies. See Section 14 for more information.
> > 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?
>
We do not mean to say that a RPL Instance is guaranteed loop free, in fact
that is not necessarily true and cannot be proven (because of the transient
and lossy nature of the LLN, thus we have also incorporated loop
detection).
What we are getting at here is that if there are nodes participating in
multiple RPL instances, then there is a possibility that nodes may forward
packets _between_ those instances in such a way that a loop results.
Consider for example a case where there are two instances which each
install a different default route, and then a packet is allowed to be
routed between the two instances (to cross over between them) in such a way
that it heads toward the first default route and then enters the other
instance and reverses its progress by heading toward the second default
route, and then crosses again, ..., thus travelling in a loop.
However, we do not intend to go too much in detail regarding the operation
of RPL among multiple instances in this draft, in fact it is stated
explicitly in Section 1.1 that we only describe operation within a single
instance.
(In an earlier revision we did start to have those rules more relaxed and
allow resulting topologies to waterfall into others in a strictly ordered
fashion, but then again, it was decided to keep it simple for the base
specification and leave that for future specification)
We do mean to describe how traffic is 'bound' to a particular instance.
That is accomplished in the later paragraphs of 11.2.2.1.
Since the paragraph that you have highlighted does not have any key impact
on the functionality of the base specification, and since it may indeed
cause confusion, we propose to remove that paragraph.
> 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.
>
We'll produce a small additional text and provide further informative
references to give some background for the rationale in the art and
practice. In short, what RPL applies is a rather common/best practice in
this space to ignore a transient routing inconsistency (at worst a loop)
unless there's traffic that actually suffers from it.
Longer answer:
Looking at the criteria that we produced in the early stage of this WG,
http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07, you'll find
that to satisfy the control cost criterion, a protocol's control traffic
communication rate must be bounded by the data rate, plus a small constant.
Now:
- Typical LLNs sensor networks exhibit low traffic rates and drastic
constraints for energy conservation.
- To keep the control overhead relatively low, the routing mechanism
must be lazy and may incur transient loops
- In particular, control inconsistencies that do not affect traffic do
not need repair.
- Thus routing inconsistencies are discovered in the data plane by
marking packets Hop-by-Hop and checking for inconsistency.
At present, as you are aware, 6man advice was followed at the time the HbH
option approach was selected.
Future work, including the possibility that the IPv6 Flow Label may become
mutable, may allow a future proposal of an alternate solution that replaces
the HbH option with a different scheme, perhaps even Flow Label, in order
to minimize the impact on packet size and possibly gain other benefits.
The key point is that the current draft does not preclude such future work.
The mechanisms for enforcing consistency should be applicable no matter how
the related information is carried inline with the packets.
> > 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?
>
We don't mean to suggest that applications must know about routing, and in
fact we don't mean to mandate anything about how a mapping to a RPL
instance may or may not occur.
What we mean to mandate in this specification is that there is a routing
topology built by RPL that conforms to certain objectives and constraints
and that may be identified by a RPLInstanceID. We then have a means by
which traffic may be bound to that topology, thus benefiting from those
objectives and constraints.
It is clear that in a practical deployment that for a traffic flow to gain
the benefits of RPL then somehow the ingress router needs to be able to
direct that traffic to the proper RPL instance by setting a RPLInstanceID.
We do not mean to say how that mapping is done, whether it is explicit,
e.g. somehow directly signaled by an application endpoint or implicit,
e.g. based on some observed property of the packet that the endpoint is no
necessarily aware of but that is suitable to determine a routing policy.
We do not mean to say how the mapping is determined, e.g. by a service
discovery mechanism or explicit configuration/administration/ ... Finally,
we do not mean to say how a default instance is provisioned or when it is
chosen.
All of these elements are important to consider in the practical deployment
of a system that includes a RPL domain. However we do want to leave the
base specification to define RPL as a routing protocol, which does define
the ability to build and name the routing topology, and leave to future
specifications to detail the mapping by ingress routers of traffic onto
those routing topologies by selecting among RPL instances.
To clarify the text, we propose to relax any text such as the excerpt you
have pointed out where it can be construed that the application endpoint
itself must be aware of the RPLInstanceID.
> Minor issues:
> -------------
>
> The Abstract seems too long and (unnecessarily) complicated (by parentheses).
>
We will rework the abstract.
> 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.
>
We will add DIO, DIS, DAO, and CC to the terminology
> > 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.
The parent selection belongs to the objective function. All RPL does is
provide the generic rules that all OF must obey. It is left as a task for
future specifications to describe the interaction between multiple
topologies.
>
> 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.
We'll make sure to add text and point to external documents where they
exist, including:
Objective functions:
http://tools.ietf.org/html/draft-ietf-roll-of0-03
http://tools.ietf.org/html/draft-gnawali-roll-etxof-01
Metrics:
http://tools.ietf.org/html/draft-ietf-roll-routing-metrics-09
...
In other cases those 'out of scope' items are really out of scope for a
routing protocol to handle. We will review to add general pointers in
those cases. Finally we can point out those items which are left to future
study for the routing protocol itself.
>
>
> > 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"?
>
> ...
This whole section should read as a MAY (or even less). We did not intend
to mandate how forwarding should work in a routing document, but we did
want to highlight how forwarding could behave to be consistent with RPL,
since loop detection and other aspects of RPL can interact with forwarding
behaviour.
If we really start standardizing forwarding, then there's a lot that could
be said for this particular space and that would definitely be a very
interesting piece of work to do. In any case, we see that as beyond the
scope of this particular spec.
We propose to add to clarify: 'This document specifies a routing protocol.
These non-normative suggestions are here to aid in the design of a
forwarding implementation by illustrating how such an implementation could
work with RPL'
> > 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?
>
To be consistent with the prior comment, we should make this a
non-NORMATIVE 'should'
>stributed 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?
This is to be addressed as a 'Major Issue' above (duplicate)
> ...
> > 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.
>
This text was intended to leave open the possibility that future work may
proceed to find a way to use the flow label for this purpose, as in the
response to your prior comment re: HbH signaling for Datapath Validation /
Loop Detection.
As it stands, it appears that this sentence may create confusion and does
not add to the functionality of the draft.
Thus we propose to remove this sentence from the base specification.
Perhaps at some point it may be possible to resurrect the idea in a future
specification, to some benefit, if developments in 6man make it feasible.
As in the prior comment, the key point is that current draft does not
preclude such future work.
>
> > 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"?
>
We will fix / edit such wording. All such uses of 'self' will be
corrected.
>
> 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.
This will be fixed
>
> [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
This will be fixed
>
> == Outdated reference: A later version (-04) exists of
> draft-ietf-roll-trickle-02
This will be fixed
Did we address your concerns?
Regards,
-RPL Authors
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
