[Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT)
Ralph Droms <rdroms.ietf@gmail.com> Mon, 08 August 2011 23:23 UTC
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E221F8B57; Mon, 8 Aug 2011 16:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfUn-cM-Gyir; Mon, 8 Aug 2011 16:23:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0477421F8B3D; Mon, 8 Aug 2011 16:23:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ralph Droms <rdroms.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.57
Message-ID: <20110808232350.30897.61741.idtracker@ietfa.amsl.com>
Date: Mon, 08 Aug 2011 16:23:50 -0700
Cc: roll@ietf.org, draft-ietf-roll-of0@tools.ietf.org, roll-chairs@tools.ietf.org
Subject: [Roll] Ralph Droms' Discuss on draft-ietf-roll-of0-15: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 23:23:51 -0000
Ralph Droms has entered the following ballot position for draft-ietf-roll-of0-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. I would like to discuss the interoperability and deployability of nodes in a RPL Instance that uses OF0. If I understand section 4.1 correctly, a node is free to compute step-of-rank using any method it chooses. There is a suggestion that using link properties for the computation is preferred, but the specific link properties and the method of computation are not specified. Later, section 4.1 defines two parameters, rank_factor and stretch_factor, that modify step_of_rank to generate a "stretched step_of_rank". The latter value is then multiplied by the MinHopRankIncrease to compute the node's rank_increase. My concern is the degrees of freedom provided to the implementation in the computation of rank_increase. I'm hoping I can get an explanation of some reason to believe that independent implementations, using different methods to compute step_of_rank and potentially different configured values for rank_factor and stretch_factor, will interoperate successfully to form an operational network. More specifically, if a simple metric that leads to a hop-count computation for path lengths and route computation is know to yield unusable performance, why is it not required that a node use some sort of computation based on link characteristics? And, if the computation of the step_factor is entirely up to the node, why are the rank_factor and stretch_factor needed? Why not just leave the entire computation to the implementation, with limitations that the resulting step_factor lie in the range MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK? 2. I would also like to discuss the requirement for a mandatory-to-implement OF, whether OF0 is that mandatory-to-implement OF and where the requirement to implement OF0 is specified. 3. In section 7.1, why is support of the DODAG Configuration option only a SHOULD? An OF0 implementation SHOULD support the DODAG Configuration option as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the parameters contained therein. 4. This point is more editorial than completely technical, but I list it as a Discuss because of the potential for confusion among implementors. I found the use of "DODAG Version" a little confusing, because it appears sometimes to mean one of the successive Versions of one DODAG and at other times to mean a specific DODAG chosen from several DODAGs. For example, from the Introduction: RPL forms Directed Acyclic Graphs (DAGs) as collections of Destination Oriented DAGs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed as a new DODAG Version to enable a global reoptimization of the graph. An instance of RPL running on a device uses an Objective Function to help it determine which DODAG Version it should join. The OF is also used by the RPL instance to select a number of routers within the DODAG Version to serve as parents or as feasible successors. In my opinion, the first use of "DODAG Version" refers to a sucessive Version of one DODAG, while the second use refers to a selection of one DODAG from many DODAGs. Would it be possible to just use "DODAG" for the second intended use? Or am I confused about the intended meanings? 5. In section 4.2.1, what does it mean to "validate a router"? Why would a router that passes validation ("succeeded that validation process") only be "preferable"? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. I consider the following comment to be a technical rather than an editorial suggestion because of the redundancy and potential conflict between the text in the Introduction of this document and the contents of draft-ietf-roll-rpl-19. It would improve the document to edit the Introduction down to a paragrpah that combines the following sentence from the first paragraph with the content from the last paragraph: An Objective Function defines how a RPL node selects and optimizes routes within a RPL Instance based on the information objects available. Editing out the text describing RPL would also presumably address Stewart's Discuss about the use of multiple OFs in one RPL Instance. 2. I don't understand this phrase from the last paragraph of the Introduction: [...] OF0 enforces normalized values for the rank_increase of a normal link and its acceptable range Do I have it right that a node uses OF0 to determine the rank_increase for a successor within the range: MINIMUM_STEP_OF_RANK < stretched step_of_rank < MAXIMUM_STEP_OF_RANK Unless I'm missing something, these limits on the stretched step_of_rank enforce (indirectly) a range on rank_increase, but don't normalize rank_increase by some normalizing factor. 3. Is there a reason to switch between "successor" and "parent" throughout the document? For example, the title of section 4.2 is "Feasible Successors Selection" and the title of the immediately following section 4.2.1 is "Selection Of The Preferred Parent". Are "successor" and "parent" are synonymous in this context? Would it be asking for foolish consistency to choose one or the other? 4. In section 7.1, what is "build-time"? At build-time [...] Also in section 7.1, what is a "fixed constant" (as opposed to any other kind of "constant"). Why are overridden values - I assume these are overriden by some administrative method like CLI configuration or some management protocol? - only applied at the next Version of the DODAG? 5. In section 3, how is "good enough" defined? From reading the rest of the spec, I don't see where any assessment of quality is applied to ensure that "good enough" is more than basic connectivity. I suggest just dropping "good enough".
- [Roll] Ralph Droms' Discuss on draft-ietf-roll-of… Ralph Droms
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Pascal Thubert (pthubert)
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Michael Richardson
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Ralph Droms
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Ralph Droms
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Pascal Thubert (pthubert)
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Pascal Thubert (pthubert)
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Michael Richardson
- Re: [Roll] Ralph Droms' Discuss on draft-ietf-rol… Tsao, Tzeta