Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 10 April 2012 07:07 UTC
Return-Path: <pthubert@cisco.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 49A6F21F86D4 for <roll@ietfa.amsl.com>; Tue, 10 Apr 2012 00:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.854
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G322FHQ9dKsU for <roll@ietfa.amsl.com>; Tue, 10 Apr 2012 00:07:54 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1F21F86D0 for <Roll@ietf.org>; Tue, 10 Apr 2012 00:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; 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-Anti-Spam-Result: AgEFAODbg0+Q/khN/2dsb2JhbABEgka3B4EHggkBAQEDAQEBAQ8BCREDPgQFAgUHBAIBCA4DBAEBCwYQBwEGASYfCQgBAQQTCBqHZwULmiigMgSPfmMEpDmBaYJp
X-IronPort-AV: E=Sophos; i="4.75,396,1330905600"; d="scan'208,217"; a="70437147"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2012 07:07:51 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3A77oDh007248; Tue, 10 Apr 2012 07:07:50 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com 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: <BDF2740C082F6942820D95BAEB9E1A84015DEA18@XMB-AMS-108.cisco.com>
In-Reply-To: <4F829499.7090902@ipv6it.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
Thread-Index: Ac0WJV5n6LEHmcKjRXm9sr3W5ZknZwAuhQQw
References: <BDF2740C082F6942820D95BAEB9E1A84015DE8D0@XMB-AMS-108.cisco.com> <4F829499.7090902@ipv6it.org>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Federico Consoli <admin@ipv6it.org>
X-OriginalArrivalTime: 10 Apr 2012 07:07:51.0756 (UTC) FILETIME=[A4D998C0:01CD16E8]
Cc: Roll@ietf.org
Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt
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: 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 8.2.2.4 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: 8.2.3.1. 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. Cheers, Pascal From: Federico Consoli [mailto:admin@ipv6it.org] Sent: lundi 9 avril 2012 09:50 To: Pascal Thubert (pthubert) Cc: Roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt 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 + DAGMaxRankIncrease, 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. -- Regards Consoli Federico Phil: 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? Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: samedi 7 avril 2012 16:58 To: Pascal Thubert (pthubert) Cc: Matteo Paris; roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote: The point is that with this clause the node selects its parents first and its Rank second. The spec recommends picking a preferred parent 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 that should be an option and text should indicate that using it may augment 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). Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- Re: [Roll] New Version Notification -draft-ietf-r… Philip Levis
- Re: [Roll] New Version Notification -draft-ietf-r… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification -draft-ietf-r… Federico Consoli
- Re: [Roll] New Version Notification -draft-ietf-r… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification -draft-ietf-r… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification -draft-ietf-r… Philip Levis