Re: [Roll] reminder - end of second WG LC

"Reddy, Joseph" <> Fri, 25 May 2012 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1263221F8462 for <>; Thu, 24 May 2012 18:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wOaGVSTK5jQJ for <>; Thu, 24 May 2012 18:39:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55F5821F8460 for <>; Thu, 24 May 2012 18:39:41 -0700 (PDT)
Received: from ([]) by (8.13.7/8.13.7) with ESMTP id q4P1deRI006830 for <>; Thu, 24 May 2012 20:39:40 -0500
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q4P1deep007539 for <>; Thu, 24 May 2012 20:39:40 -0500
Received: from ([fe80::843:a4aa:bf01:3f68]) by ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Thu, 24 May 2012 20:39:40 -0500
From: "Reddy, Joseph" <>
To: "" <>
Thread-Topic: reminder - end of second WG LC
Thread-Index: Ac06FyOYTn3bpnu+QeaPj5v03WfWVA==
Date: Fri, 25 May 2012 01:39:39 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Roll] reminder - end of second WG LC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 May 2012 01:39:42 -0000

Hi Mukul,

Here are some comments on the P2P-RPL draft

-Regards, Joseph

Section 5:
"...By not allowing the generation of DRO messages, an Origin can use P2P-RPL as purely a mechanism to deliver time-critical application data..."
I question the value of this. The use of trickle timer necessarily adds a minimum delay on each hop. So, it would be faster to use the normal DODAG in most cases even if that route takes more hops. And the normal route would impose much less burden on the intermediate nodes. 

Section 6.1:
"...A P2P-DIO MAY carry one or more RIO and PIO options..."
I am not sure how these options should be used by the DAG members. Later on, in 9.1, it says that "..the temporary DAG must not be used to route packets....". So what is the purpose of RIO and also PIO ?

Default DoDAG config option values:
DIOIntervalMin of 6 is too small for most networks. For default parameter, suggest using 7.
Also, default Lifetime values of infinity does not seem like a good idea for a "temporary DAG"

Section 9.2:
Suggest that Imax setting should be less that the DAG lifetime value
Section 9.4
Bullet 1: 
Under what conditions would a router receive the same DIO and a Data-Option with higher sequence number? I assume that only the Originator can include a Data-Option ? Same question also arises for section 9.5 ( para 1 )

Section 9.5:
"...The Target must transmit the DRO message via the link-local multicast.."
Not sure why it would use link-local multicast...shouldn't it just transmit along the reverse route collected in the P2P-RDO ?

Section 9.6:
"...This hop-by-hop lifetime must expire at the end of the lifetime specified by the default ..."
The lifetime specified in the DODAG config option is intended to limit the DAG lifetime which is used only for discovering the route. However, the actual route lifetime would be used for a much longer period of time. If it expires so quickly, then it would seem that practical use of the p2p-rpl is limited to the source routing option.

Section 11:
It would seem that only the Originator of the temporary DAG can use the routes created by it. The intermediate nodes are storing the routes but cannot actually use them. Is my  understanding right ?

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.  

From:<> []<mailto:[]> On Behalf Of JP Vasseur
Sent: mercredi 23 mai 2012 23:44
To: roll WG
Cc: Michael Richardson
Subject: [Roll] reminder - end of second WG LC

Second last call on

* draft-ietf-roll-p2p-measurement-05 and
* draft-ietf-roll-p2p-rpl-12

will end May 25th at noon ET, just a reminder.



On May 11, 2012, at 2:20 PM, JP Vasseur wrote:

Dear all,

A first WG Last Call took place on March 16th on:
* draft-ietf-roll-p2p-measurement-04 and
* draft-ietf-roll-p2p-rpl-09

Thanks to all of you for the fruitful and constructive comments received during WG Last call, that led to several tickets that have been successfully closed, leading to new revisions of these documents.

This starts a new 2-week WG last call on:
* draft-ietf-roll-p2p-measurement-05 and
* draft-ietf-roll-p2p-rpl-12

The WG Last call will end on May 25th at noon ET. Please send your comments on the mailing list and copy the authors.


JP and Michael.

Begin forwarded message: