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

"Reddy, Joseph" <jreddy@ti.com> Mon, 04 June 2012 04:51 UTC

Return-Path: <jreddy@ti.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 067D121F8890 for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 21:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 BrQYWkFyUfaj for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 21:50:58 -0700 (PDT)
Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF5B21F887E for <roll@ietf.org>; Sun, 3 Jun 2012 21:50:54 -0700 (PDT)
Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q544osn4008426; Sun, 3 Jun 2012 23:50:54 -0500
Received: from DFLE71.ent.ti.com (dfle71.ent.ti.com [128.247.5.62]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q544osOX002679; Sun, 3 Jun 2012 23:50:54 -0500
Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE71.ent.ti.com ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Sun, 3 Jun 2012 23:50:54 -0500
From: "Reddy, Joseph" <jreddy@ti.com>
To: "'Mukul Goyal'" <mukul@uwm.edu>
Thread-Topic: Use P2P-RPL to repair DAO routes
Thread-Index: AQHNQTeLad/wP4Slmk+rhqippmOu2pbpkwbggAAFsLA=
Date: Mon, 4 Jun 2012 04:50:53 +0000
Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB99@DLEE10.ent.ti.com>
References: <992131173.513367.1337956316701.JavaMail.root@mail17.pantherlink.uwm.edu> <1851893033.579685.1338693497231.JavaMail.root@mail17.pantherlink.uwm.edu> <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB6A@DLEE10.ent.ti.com>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB6A@DLEE10.ent.ti.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.170.170.90]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "roll@ietf.org" <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 04:51:06 -0000

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