Re: [Roll] MRHOF draft-11 comments

Philip Levis <pal@cs.stanford.edu> Sun, 05 August 2012 22:06 UTC

Return-Path: <pal@cs.stanford.edu>
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 1E25C21F857E for <roll@ietfa.amsl.com>; Sun, 5 Aug 2012 15:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.98
X-Spam-Level:
X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
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 wI5IRDJ+7HXa for <roll@ietfa.amsl.com>; Sun, 5 Aug 2012 15:06:13 -0700 (PDT)
Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 91F6621F851B for <roll@ietf.org>; Sun, 5 Aug 2012 15:06:12 -0700 (PDT)
Received: from [207.239.114.206] (helo=[192.168.71.50]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <pal@cs.stanford.edu>) id 1Sy8xf-0006Py-Le; Sun, 05 Aug 2012 15:06:11 -0700
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0@ITR-EXMBXVS-1.itron.com>
Date: Sun, 05 Aug 2012 15:06:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <98384B4B-6F45-4124-A25B-FD4C18F15F1C@cs.stanford.edu>
References: <10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0@ITR-EXMBXVS-1.itron.com>
To: "Mani, Mehdi" <Mehdi.Mani@itron.com>
X-Mailer: Apple Mail (2.1278)
X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] MRHOF draft-11 comments
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: Sun, 05 Aug 2012 22:06:14 -0000

On Jul 25, 2012, at 7:02 AM, Mani, Mehdi wrote:

> In section 3.3, it seems that the rank value using the case 3 is always less than the one calculated in case 2; then it is useless to have it. (if my understanding is true!)  This is basically because the highest “rank increase” that would be possible is equal to MaxRankIncrese.

I think that #3 can be higher than #2 when a link cost is much higher than MaxRankIncrease. Here's a parent set:

Parent A advertises a Rank of 40, link cost is 10.
Parent B advertises a Rank of 50, link cost is 250

Let's suppose MaxRankIncrease is 5 and MinHopRankIncrease is 15. Following rule 2, the advertised rank must be 60. Following rule 3, the advertised rank must be 245. I realize this is a pretty extreme case (why is parent B in the parent set?!?!), but there are less extreme ones and these rules are for correctness, not performance.

Does this sound right to you?

Phil