Re: [Roll] Use P2P-RPL to repair DAO routes

Mukul Goyal <mukul@uwm.edu> Mon, 04 June 2012 06:30 UTC

Return-Path: <prvs=49575ab5a=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 E99D621F86B1 for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 23:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.427
X-Spam-Level:
X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 buDk2CNTX1xc for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 23:30:14 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7621F86AF for <roll@ietf.org>; Sun, 3 Jun 2012 23:30:13 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAJtVzE9/AAAB/2dsb2JhbABFhU6xdgEBBSNWDA8OAwQBAQMCDRkCUQgGE4gLpECIWokEgSOJboR+gRIDiECMW492gn6BOCM
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 7042BE6A8D; Mon, 4 Jun 2012 01:30:13 -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 tJe6EpZeteHI; Mon, 4 Jun 2012 01:30:13 -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 205D2E6A72; Mon, 4 Jun 2012 01:30:13 -0500 (CDT)
Date: Mon, 04 Jun 2012 01:30:13 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Joseph Reddy <jreddy@ti.com>
Message-ID: <457536501.582806.1338791413060.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB99@DLEE10.ent.ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: Re: [Roll] Use P2P-RPL to repair DAO routes
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: Mon, 04 Jun 2012 06:30:15 -0000

Thanks Joseph. I guess this issue is closed too as far as P2P-RPL is concerned.

Mukul

----- Original Message -----
From: "Joseph Reddy" <jreddy@ti.com>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: roll@ietf.org
Sent: Sunday, June 3, 2012 11:50:53 PM
Subject: RE: Use P2P-RPL to repair DAO routes


Hi Mukul,

Thanks for the clarification. I agree with your suggestion to consider this as subject for a separate document.

-Regards, Joseph


----- Forwarded Message -----
[Joseph]   
Section 12:
..In general, P2P-RPL operation does not affect core RPL operation.."
I think this is unfortunate as P2P can be used to fix issues with core rpl. For example, in core RPL, there is no way to repair a downward route until the actual Target sends another DAO, which can take a long time. It would be very nice if the DoDag root can use P2P-RPL to discover a route to a Target node that is unreachable and then use the resulting source route as the downward route.  

[Mukul]
What the text you quoted means is that it does not break core RPL operation. P2P-RPL can certainly be used in the manner you specified. The root of a global DODAG can certainly use P2P-RPL to discover a source route to any target. Just that it will involve creation of a separate temporary DAG. If you want to do this route discovery within the scope of the existing global permanent DAG, it can be done but needs to be written up in a separate document. I dont think this provision should be inside P2P-RPL document. This is because, for RPL deployments that would not otherwise support P2P-RPL, it may be more efficient to simply use an RPL Target Option inside a DIO to trigger DAOs that would allow desired route to be discovered. Ofcourse, this needs to be written up to (since currently Target Option cannot sit inside a non-P2P mode DIO).