Re: [Roll] MRHOF draft-07 comments

Philip Levis <pal@cs.stanford.edu> Fri, 30 March 2012 16: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 A24C321F8670 for <roll@ietfa.amsl.com>; Fri, 30 Mar 2012 09:06:23 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9AhvQFOvgR3 for <roll@ietfa.amsl.com>; Fri, 30 Mar 2012 09:06:23 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2271821F8671 for <Roll@ietf.org>; Fri, 30 Mar 2012 09:06:23 -0700 (PDT)
Received: from ast-lambert-153-1-157-249.w90-44.abo.wanadoo.fr ([90.44.96.249] helo=[192.168.100.145]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <pal@cs.stanford.edu>) id 1SDeLG-0008Af-Jp; Fri, 30 Mar 2012 09:06:22 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <4F759C31.2050306@ipv6it.org>
Date: Fri, 30 Mar 2012 18:06:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5EEFAFF-B683-4D32-AD5F-F6E0778BA01B@cs.stanford.edu>
References: <4F723A15.7040900@ipv6it.org> <747F05A8-A525-49EB-9D9E-5A0B072EF74D@cs.stanford.edu> <4F7444F0.3020101@ipv6it.org> <A78FB66B-E578-4D2D-9D13-AF9A57F35859@cs.stanford.edu> <4F74A202.2040206@ipv6it.org> <55B55877-4CF8-444C-9E09-711C6990BC9D@cs.stanford.edu> <4F759C31.2050306@ipv6it.org>
To: Federico Consoli <admin@ipv6it.org>
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f
Cc: Roll@ietf.org
Subject: Re: [Roll] MRHOF draft-07 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: Fri, 30 Mar 2012 16:06:23 -0000

On Mar 30, 2012, at 1:42 PM, Federico Consoli wrote:

> 
> I got a question about the PARENT_SET_SIZE.
> 
> "PARENT_SET_SIZE: The number of candidate parents, including the preferred parent, in the parent set."
> "candidate parents"  = "candidate neighbour"  or are different?

RFC 6550, 8.2.1:

   RPL's Upward route discovery algorithms and processing are in terms
   of three logical sets of link-local nodes.  First, the candidate
   neighbor set is a subset of the nodes that can be reached via link-
   local multicast.  The selection of this set is implementation and OF
   dependent.  Second, the parent set is a restricted subset of the
   candidate neighbor set.  Finally, the preferred parent is a member of
   the parent set that is the preferred next hop in Upward routes.
   Conceptually, the preferred parent is a single parent; although, it
   may be a set of multiple parents if those parents are equally
   preferred and have identical Rank.


> 
> "A node MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors in its parent set."
> It's a upper bound? Could a node have more than PARENT_SET_SIZE additional candidate neighbors in its parents set?

Yes: there is no MUST NOT or even a SHOULD NOT.

Phil