Re: [Roll] Working Last Call on draft-ietf-roll-of0-05

Philip Levis <pal@cs.stanford.edu> Tue, 22 February 2011 17:04 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F193A6924 for <roll@core3.amsl.com>; Tue, 22 Feb 2011 09:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usIloX4SYi6G for <roll@core3.amsl.com>; Tue, 22 Feb 2011 09:04:58 -0800 (PST)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 430023A68DC for <roll@ietf.org>; Tue, 22 Feb 2011 09:04:58 -0800 (PST)
Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1PrvgE-0001nH-5G; Tue, 22 Feb 2011 09:05:43 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com>
Date: Tue, 22 Feb 2011 09:05:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E5FAC28-5607-4C5B-BD81-602E9C4F29DF@cs.stanford.edu>
References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com>
To: JP Vasseur <jpv@cisco.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1082)
X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06
Cc: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 22 Feb 2011 17:04:59 -0000

On Feb 22, 2011, at 12:03 AM, JP Vasseur wrote:

> Dear all,
> 
> This document has been stable for quite some time and the latest revision has addressed all comments received so far. This starts a 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET.
> 
> Please send your comments to the authors and copy the mailing list.

5 comments (some just grammatical, some significant)

1. "the Objective Function selects the DODAG" -> "An Objective Function selects the DODAG"

2. "OF0 uses a MinHopRankIncrease of 0x100 so that Rank value can be stored in one octet.  This allows up to at least 16 hops when each hop has the worst Rank Increment of 16."

- This worries me. It means that networks with incompatible OFs, or which have to go to the last resort OF, have a maximum hopcount of 16. I'd recommend that instead the worst Rank increment be made smaller, in order to support more hops. E.g., 4/64. When we built CTP we made sure it could support more than 16 hops because there were established deployments which were > 32 hops (e.g., the network measuring the Golden Gate Bridge). Is there any basis for this particular breakdown? Are we really going to go back to RIP? Putting the reasoning in the document isn't a good idea, but I'd like to know what it is so I can feel comfortable with it.

3. "It MAY stretch its step of Rank " -> "A node MAY stretch its step of Rank"

4. "   o  The preferred parent MUST be ignored.

   o  A Router that is not in the same DODAG as the preferred parent,
      either in the current or a subsequent iteration, MUST be ignored."

- I'd suggest writing these as "The backup next_hop MUST NOT be the preferred parent" and "The backup next_hop MUST be in the same DODAG iteration as the preferred parent." It's not 100% clear what "ignores" means in this context.



5. "   Trigger    The OF0 support may trigger the RPL core to inform it that
              a change occurred.  This indicates whether the change
              requires a new DIO to be fired, trickle timers to be
              reset, etc..."

- You probably don't want an ellipsis here.


Phil