[Roll] Closure text for ticket #89

Mukul Goyal <mukul@uwm.edu> Fri, 13 April 2012 13:39 UTC

Return-Path: <prvs=44399eb11=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 80DDD21F8630 for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 06:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Level:
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 fyo07Opp3o1q for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 06:39:05 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9B21F8622 for <roll@ietf.org>; Fri, 13 Apr 2012 06:39:05 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHUriE9/AAAB/2dsb2JhbABFhWa0bCNWNQINGQJZBi6Hc6ZiiW+JCYEvigOFDYEYBIhajRKQNoMFgTY
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1ACBEE6A8E; Fri, 13 Apr 2012 08:39:05 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GcV1j+XaI6s; Fri, 13 Apr 2012 08:39:04 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id D78A4E6A8D; Fri, 13 Apr 2012 08:39:04 -0500 (CDT)
Date: Fri, 13 Apr 2012 08:39:04 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: JP Vasseur <jpv@cisco.com>
Message-ID: <856340696.15964.1334324344794.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <BDF2740C082F6942820D95BAEB9E1A84016A8DE6@XMB-AMS-108.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
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>
Subject: [Roll] Closure text for ticket #89
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, 13 Apr 2012 13:39:06 -0000

#89: Spec is limited to single interface intermediate routers

 Problem
 ------------------------------
 The spec does not allow for routers with multiple interfaces. It expects  that an address is usable downwards and upwards.

Resolution:
-----------------------------
Add the following text to the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both forward and backward directions, which it quite typical in usual LLN routers with a single radio"

 Discussion
 -------------

 [Pascal]
 "When an
 intermediate router adds itself to a route, it MUST ensure that the
 IPv6 address added to the route is reachable in both forward and  backward directions."
 This is written with the vision that the router has a single interface  and acts as a repeater.
 But really a router could have 2 interfaces on a same subnet in which  case that clause does not fly.

 [Mukul]
 All I mean is that the accumulated route MUST NOT have an address that  cannot be accessed in one of the directions. If the address cannot be  accessed in the backward direction, then the DRO would not be able to  travel to the origin.

 [Pascal2] Then you're preventing a router with 2 interfaces. That's sad.
 I'm fine for an experimental draft   but for standard track that will
 have to be changed.

 [Mukul2] OK, I am keeping it the way it is.

 [Pascal3] This also need to be logged as a last call issue and its  proposed resolution. Nothing wrong with having limitations, yet I think  we must have specific text to indicate that the spec so far is limited  to devices with a single interface. When we make the Standard Track  version, I expect we'll have to go beyond that limitation. The drawback  is for experimental  implementations that may not be interoperable with  the final solution.

 [Mukul3] Could you please explain how does the requirement regarding  addresses to be accessible in both forward and backward directions  limits P2P-RPL to only single interface devices? I think this  requirement means that P2P-RPL cannot be used across link layers. Is  that what you mean? I think allowing operation across link layers would  require P2P-RDO to accumulate additional information (backward address  to be used for forward addresses not accessible in backward direction).
 I think at the moment we want to avoid this complexity.

 [Pascal4] Because an IP address is associated to an interface. If you  have 2 interfaces, even in a same subnet, there should be 2 addresses.

 [Mukul4] But, why would the two IP addresses the device has on the same  subnet wont be accessible in both forward and backward directions?

[Mukul5]
I propose the following text to be placed inside the Applicability section:

"The participation in a P2P-RPL route discovery is currently limited to the routers with IPv6 addresses that are reachable in both incoming and outgoing directions, which it quite typical in usual LLN routers with a single radio"

Can we close this ticket?

[Pascal5]

I'd prefer to use upward and downward which are the terms that RPL traditionally uses.... 

Is that OK with you? Otherwise yes, this text addresses my issue.

[Mukul6]
Should we use forward and backward terms? I already define them in the draft.

[Pascal6]
Yes, that would be perfect