Re: [Roll] draft-ietf-6man-rpl-routing-header-07

Mukul Goyal <mukul@uwm.edu> Thu, 22 December 2011 17:24 UTC

Return-Path: <prvs=3304ccdf4=mukul@uwm.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 38E9C21F899F; Thu, 22 Dec 2011 09:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.496
X-Spam-Level:
X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 tUZjQBsZTOZj; Thu, 22 Dec 2011 09:24:43 -0800 (PST)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9EC21F893C; Thu, 22 Dec 2011 09:24:43 -0800 (PST)
Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 22 Dec 2011 11:24:42 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E7F6B1FD013; Thu, 22 Dec 2011 11:24:42 -0600 (CST)
X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu
Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXO5W0Vhr9RZ; Thu, 22 Dec 2011 11:24:42 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id A8F311FD011; Thu, 22 Dec 2011 11:24:42 -0600 (CST)
Date: Thu, 22 Dec 2011 11:24:42 -0600
From: Mukul Goyal <mukul@uwm.edu>
To: Jonathan Hui <jonhui@cisco.com>
Message-ID: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <6C1711F1-AB47-4870-8228-A6A36A0C3164@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll <roll@ietf.org>, ipv6@ietf.org
Subject: Re: [Roll] draft-ietf-6man-rpl-routing-header-07
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: Thu, 22 Dec 2011 17:24:44 -0000

>Again, just because you received a message on an interface for which you've enabled RPL doesn't mean you know the message came from a router that is within the same RPL routing domain.  A router not running RPL could have sent you that message.

A router not running RPL could have sent me a message carrying SRH?

>> A more complicated scheme would be to allow for multiple RPL domains and list the RPL Domain ID in the SRH. The router would know which RPL domains its interfaces belong to and would treat the packet accordingly.

>Except that there is no such concept.  RPL Instance ID is the closest we have.

Yes, the concept of RPL domain needs to be defined - either in rpl-terminology draft or in your draft.

>> I am trying to say that RPL Instance ID does not give that information to the tunnel exit point. As per RPL spec, RPL Instance ID would have a mapping to the OF. It nowhere says that RPL Instance ID also has a mapping to metrics in use.

>From Section 3.2.1 of draft-ietf-roll-rpl:

   The Objective Function (OF) defines how RPL nodes select and optimize
   routes within a RPL Instance.  The OF is identified by an Objective
   Code Point (OCP) within the DIO Configuration option.  An OF defines
   how nodes translate one or more metrics and constraints, which are
   themselves defined in [I-D.ietf-roll-routing-metrics], into a value
   called Rank, which approximates the node's distance from a DODAG
   root.  An OF also defines how nodes select parents.  Further details
   may be found in Section 14, [I-D.ietf-roll-routing-metrics],
   [I-D.ietf-roll-of0], and related companion specifications.

>As you state, RPL Instance maps to OF which, from the cited text, maps to metrics and route selection.  By transitivity, RPL Instance ID does map to metrics and how routes are formed.

The text you quoted no where says that an OF maps to particular metric. OF0 is metrics-independent. OF1 (draft-ietf-roll-minrank-hysteresis-of-04) applies to any additive metric. No RPL doc says that, for a particular LLN, a particular OF maps to a particular metric only. 

I think the following text clearly specifies what an RPL Instance is. Also, this text clearly says that an RPL Instance ID maps to a particular OF:

rpl-19 section 3.1.2:
      A RPLInstanceID identifies a set of
      one or more Destination Oriented DAGs (DODAGs).  A network may
      have multiple RPLInstanceIDs, each of which defines an independent
      set of DODAGs, which may be optimized for different Objective
      Functions (OFs) and/or applications.  The set of DODAGs identified
      by a RPLInstanceID is called a RPL Instance.  All DODAGs in the
      same RPL Instance use the same OF.

This definition says an RPLInstanceID identifies a set of DAGs with a common OF. No more and no less. A particular LLN may choose to map an OF to a particular metric but there is no such requirement as per RPL specs.
 
>> RPL Instance is the top level identifier of the DAGs that can be used to forward the packet. It also maps to a particular OF. In my opinion and as per RPL spec, RPL instance has no other significance.

>See above.  RPL Instance does map to metrics.

It need not.

>The definition I proposed was simply a collection of routers running RPL under the same administrative domain.  As mentioned above, that does not mean that every router on an interface belongs to a RPL routing domain.

I think the definition you provided is sufficient. An RPL domain is a collection of routers running RPL under the same administrative domain. Each router in the RPL domain needs to classify all its interfaces regarding whether they belong to the RPL domain or not.

A packet can be assumed to be coming from a router in the RPL domain if it carries an SRH.

Thanks
Mukul