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

Jonathan Hui <jonhui@cisco.com> Thu, 22 December 2011 18:02 UTC

Return-Path: <jonhui@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 1959B21F84CE; Thu, 22 Dec 2011 10:02:29 -0800 (PST)
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 IpcuwoHl+aAA; Thu, 22 Dec 2011 10:02:28 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 829DA21F84CD; Thu, 22 Dec 2011 10:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=4452; q=dns/txt; s=iport; t=1324576948; x=1325786548; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rk6oJcPLieem4HkndKo6KGDOLHjm5a1wk2lVuo9vPhM=; b=k4ocyQ7V+5Azk3lx28eSteR3V3bZ9t8W1RqJ666znkcEY61YKZHVj9uA rMMJeCGG0o1W4EcXpNZLwdZxlEqA0niAZtaa61TQX8lfOt36Iz3uArb18 uvuG3As8mGTdQpJ8cWHtHtV7IaHMfu0eWtKGbKpSf4QfX1jUXfIZZwrHv Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABZw806rRDoG/2dsb2JhbABDDqwfgQWBcgEBAQMBEgEnLRIFCwtGVwY1h1iZCAGeKYssYwSIN4xKkXtY
X-IronPort-AV: E=Sophos;i="4.71,394,1320624000"; d="scan'208";a="22147265"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 18:02:28 +0000
Received: from dhcp-128-107-155-213.cisco.com (dhcp-128-107-155-213.cisco.com [128.107.155.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBMI2SVe000675; Thu, 22 Dec 2011 18:02:28 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Jonathan Hui <jonhui@cisco.com>
In-Reply-To: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Thu, 22 Dec 2011 10:02:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6EF9DCC-5743-41FF-BEF5-5AA7C6C27BA9@cisco.com>
References: <1033338721.734443.1324574682571.JavaMail.root@mail17.pantherlink.uwm.edu>
To: Mukul Goyal <mukul@uwm.edu>
X-Mailer: Apple Mail (2.1084)
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 18:02:29 -0000

On Dec 22, 2011, at 9:24 AM, Mukul Goyal wrote:

>> 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?

Sure.  It could be a host as well.  Part of limiting the scope is to limit the scope of an attack.  See the Security Considerations.

>> 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. 

Incorrect.  From draft-ietf-roll-routing-metrics-19:

   The set of routing metrics and constraints used by an RPL deployment
   is signaled along the DAG that is built according to the Objective
   Function (rules governing how to build a DAG) and the routing metrics
   and constraints are advertised in the DAG Information Option (DIO)
   message specified in [I-D.ietf-roll-rpl].

In other words, the combination of the OCP and the metrics identified by the DODAG Root describes how to optimize the routes.  In the case of OF0, the metric is the Rank itself.

> 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.

You never answered my question.  Why bother having a RPL Instance ID if you don't care how the routes are optimized?  Why bother maintaining multiple paths optimized using different OFs and/or metrics?

>>> 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.

You are incorrect again!

>> 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.


Nope.  As I stated before, that would invalidate the Security Considerations section.

--
Jonathan Hui