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

Mukul Goyal <mukul@uwm.edu> Thu, 22 December 2011 15:04 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 9B8AA21F8A7D; Thu, 22 Dec 2011 07:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.466
X-Spam-Level:
X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 n3npceKxeo7r; Thu, 22 Dec 2011 07:04:48 -0800 (PST)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDD21F8A66; Thu, 22 Dec 2011 07:04:48 -0800 (PST)
Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 22 Dec 2011 09:04:35 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5B3281FD0AB; Thu, 22 Dec 2011 09:04:35 -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 YIqWAzTiRgx1; Thu, 22 Dec 2011 09:04:34 -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 1989D1FD014; Thu, 22 Dec 2011 09:04:34 -0600 (CST)
Date: Thu, 22 Dec 2011 09:04:33 -0600
From: Mukul Goyal <mukul@uwm.edu>
To: Jonathan Hui <jonhui@cisco.com>
Message-ID: <1026538192.732410.1324566273913.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <04F68F74-2053-4902-AB99-BDE5FD65FCCF@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 15:04:52 -0000

Hi Jonathan

>And by the same logic, when forwarding a message, there is no guarantee that all neighboring nodes reachable via an interface belong to the same RPL routing domain.

The receiving router could check if it belongs to the RPL domain listed in the SRH. If not, it can drop the packet.

>The *entire* point of the RPL Instance concept is to support MTR.  The RPL Instance is used to distinguish between different DODAGs from the same root.  It gives you the ability to have multiple different routes to the same destination (e.g. one that minimizes latency vs. one that minimizes energy consumption).  If you don't have the RPL Instance information when forwarding a packet, how do you know whether to forward along the path that minimizes latency vs. the path that minimizes energy?

Suppose a tunnel exit point knows that the SRH that carried the packet so far had RPL Instance ID 'x' which happens to be associated with OF0. What information does that give to the tunnel exit point? Is OF0 associated with minimizing of latency or of energy? What is preventing this particular RPL Instance ID 'x' with OF0 to be associated with two different DAGs - one minimizing latency and the other minimizing energy?

>See slide 18 of http://www.iab.org/wp-content/IAB-uploads/2011/04/Vasseur.pdf if you want one such reference of MTR and RPL Instances.

>As I mentioned above, the RPL Instance allows you to have multiple distinct paths towards the same destination.  The RPL hop-by-hop option includes a RPL Instance ID so that a forwarding node knows which routing topology to use.  If RPL did not allow multiple routes to the same destination, then why bother having a RPL Instance?  You would only need the DODAGID to uniquely identify a DODAG (whereas the existing definition is the "tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG".

All this discussion is really besides the point. If we could just have the RPL domain and not the RPL Instance as the scope for an SRH, that will solve my problem.

Thanks
Mukul


--
Jonathan Hui