Hi Tim and co-authors,
> Did we address your concerns?
Yes, thanks for the very thorough reply. I think all your proposed
updates are fine. As for:
> 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.
I agree. I think a small clarification in the text will be sufficient.
Regards
Brian
On 2010-09-14 02:02, Tim Winter wrote:
> 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
