Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt

"Pascal Thubert (pthubert)" <> Tue, 10 April 2012 07:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49A6F21F86D4 for <>; Tue, 10 Apr 2012 00:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.854
X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G322FHQ9dKsU for <>; Tue, 10 Apr 2012 00:07:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95A1F21F86D0 for <>; Tue, 10 Apr 2012 00:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=24621; q=dns/txt; s=iport; t=1334041673; x=1335251273; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NqcWBN2ProWY33H9x82hucDYGOVGxhUvzeA+u/2njSs=; b=j9PD7W/Nd5qbMAXxt6fs2XR2cPTDhRmsdbWLKmO2fiMmMfuxIBY/ei2k d+w/szEYbgAJOcMsbd7f++KBGywpmH0lo9m1/NsHnFR6O+TQlXzKlSmys 6zp9cgxiTkRAFGpTBb5Z6FGc0DW4WqwRwkcOLWXNkAzLqKrbXTm/Lltu+ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.75,396,1330905600"; d="scan'208,217"; a="70437147"
Received: from ([]) by with ESMTP; 10 Apr 2012 07:07:51 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3A77oDh007248; Tue, 10 Apr 2012 07:07:50 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 09:07:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD16E8.A48B3739"
Date: Tue, 10 Apr 2012 09:06:46 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
Thread-Index: Ac0WJV5n6LEHmcKjRXm9sr3W5ZknZwAuhQQw
References: <> <>
From: "Pascal Thubert (pthubert)" <>
To: Federico Consoli <>
X-OriginalArrivalTime: 10 Apr 2012 07:07:51.0756 (UTC) FILETIME=[A4D998C0:01CD16E8]
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 07:07:58 -0000

Hi Frederico :


My scenario is just a high level direction and does not intend to be
Phil's final text. I used that to illustrate the difference between my
expected behavior and my reading of the current text. 

You'll also note that my text mandates that the preferred parent it the
one that results with the lowest resulting rank, which is an OF decision
and could be done differently here.

> I think that if you want to put a constraint on the parent-set it can
not be MaxRankIncrease but it should be another variable/constraint.


Semantically speaking, you're probably right. It will be cleaner if the
OF cares to define the max Rank stretch between the least and worst
parent when computing the initial value for L.

I assumed it was simpler to just define the initial computation of L and
then live by the rules. But that could be confusing.


And I agree with your wanted behavior. That's the spirit of section item 3 in RPL. A next sentence could be that if the node is
unhappy with the resulting parent set it may advertise infinite and pick
any parent. 

But that must be exceptional, like for nodes that do not want to be a
router anyway. I trust that if this is generalized then the greedy
misbehavior (see section 3.7.1) will become apparent.

For instance, if we add a router that sees 2 existing routers, with
Ranks far apart, what do we expect?  Does that depend on the metric? 

If the new node bases its Rank on the worst of the 2 existing routers,
it will be mostly unusable as a parent => adding a new node will fail to
improve connectivity for others.


RPL provides hints for that and indicates that the preferred parent
gives the sense of the position in the graph. Though it's up to the OF,
L is naturally the calculated Rank via the preferred parent: DIO Message Processing


The most preferred parent should be used to restrict which other

nodes may become DODAG parents.


You'll note that the preferred parent does not necessarily mean that it
has the lowest resulting Rank, so it is up to the OF to define something
more complex than my scenario.






From: Federico Consoli [] 
Sent: lundi 9 avril 2012 09:50
To: Pascal Thubert (pthubert)
Subject: Re: [Roll] New Version Notification


Hi, IMHO I think that if you use MaxRankIncrease it's because you want a
particular behavior of RPL and especially you want that: 

"If a node's Rank were to be higher than allowed by L +
when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK."

If you calculate the  parent set as you wrote in step 3 you simply avoid
this (wanted) behavior; in fact I can also say: 
"If you use MaxRankIncrease this relation
MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I
"fixed" the problem.

I think that if you want to put a constraint on the parent-set it can
not be MaxRankIncrease but it should be another variable/constraint.

Consoli Federico

It is an implementation decision as long as it does not lead to interop
issue or unwanted behavior, which is probably the case here.
RFC 6550 demands that a node can't stray from the best Rank as computed
amongst parents by more than MaxRankIncrease.
This 3 clauses do not seem to capture this that we are discussing do not
seem to capture this. 
With (my reading of) the text as it stands, it seems that the
implementation has all freedom to select parents and then is given rules
to compute a Rank. 
The resulting Rank could be anything if the parent set as no constraint.
In particular  " The largest  calculated Rank among paths through the
parent set, minus MaxRankIncrease" must be less that the Rank obtained
from the preferred parent, not the final computed Rank.
The node should:
1) Compute the Ranks form its parent set. 
2) Determine a preferred parent as resulting with the lowest Rank (using
the computation described in the previous paragraph)
3) Determine which parents generate a Rank that is between that lowest
Rank and MaxRankIncrease
4) Pick a set of parents between those 
What do you think?
-----Original Message-----
From: Philip Levis [] 
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris;
Subject: Re: [Roll] New Version Notification
On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote:

	The point is that with this clause the node selects its parents
	and its Rank second. The spec recommends picking a preferred
	first, computing the Rank based on the preferred parent, and
then only


	consider any node with a lower floor as an acceptable parent. I 
	understand that want to allow reversing that operation, but then
	should be an option and text should indicate that using it may


	the parent set for some nodes but end up reducing it for others.

Don't you think this is an implementation decision? I tried to write the
specification text to be completely neutral on this matter (as some of
the MRHOF discussions have gone into). The input to DIO generation is a
preferred parent and a parent set; how those two are selected is
complete outside the specification with the caveat that it places some
constraints (MaxRankIncrease).
Roll mailing list