Subject: [Roll] Comments on Section 6 Re: Comments on draft-dt-roll-p2p-rpl-01

From: Mukul Goyal <[email-masked]>
Date: Mon, 21 Jun 2010 03:02:54 -0500 (CDT)

Hi JP

Here are responses to the comments on Section 6. Again, the comments not responded to here do not require discussion/clarification and will be incorporated in the next version of the draft.

I think I am done responding to your comments.

Overall, I would like to thank you for your detailed comments. I think these comments will help clarify lot of things in the next version of the draft.

Thanks
Mukul

This document defines a new RPL Control Message type, the Discovery
   Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that
   serves the following functions:

   o  An acknowledgement from the target router to the origin router
      regarding the successful discovery of backward source routes;

JP> ACK of routes from the origin to the target: you may not have routesin the opposite direction.
MG> Thats why the draft allows Discovery Reply messages, acting as an ACK or carrying source routes, to be sent to the origin router in any manner. Such messages may be source routed or sent along any DAG, including the temporary DAG. Only the Discovery Reply message, that needs to establish a hop-by-hop route, needs to travel along reverse of the source-route accumulated by the corresponding Discovery message.

When a target router discovers a backward source route, 
JP> I have an issue with your terminology. When the target receives theDIO with route discovery option, what is discovered is a forward route ?
MG> Not necessarily, the discovered route could be backward/bidirectional as well. The origin router specifies what kind of route is desired. So, if forward route is desired, the metrics values recorded/aggregated by the routers inside the Metric Container are those in the forward direction. If backward route is desired, then the metrics values recorded/aggregated by the routers inside the Metric Container are those in the backward direction. I hope this point is clear.

JP> You may want to explain a bit more why you the origin routerwould be interested in receiving an ACK without the route itself (case6.3): hop-by-hop routes.
MG> There are 3 cases:
1. Discovery of backward source routes: In this case, the Target router sends an ACK (Discovery Reply message acting as an ACK) to the origin router telling it how may routes were discovered. Origin router does not need to know backward routes. They are for target routers use.
2. Discovery of forward/bidirectional source routes: In this case, the Target Router needs to send the routes themselves to the origin router (inside the Discovery Reply message).
3. Discovery and Establishment of Hop-by-hop routes: In this case, the Target Router sends a (per route) Discovery Reply message to the Origin Router. This message travels to the Origin Router along the discovered route and establishes appropriate forward/backward/bidirectional hop-by-hop state in the routers it passes through.
Hope this makes sense.

JP> Note that the algorithm for "best route" selection is outside the scopeof this document, so does the use of a timer on the target side to determinehow much time to wait before answering, ... 
MG> The draft does not require/specify the use of a timer. As the draft says, the Target Router can send a Discovery Reply message back as soon as it identifies a good enough route (which need not be the best). If the Target Router wants, it can monitor the good enough routes for a while and choose the best among them as the "discovered" routes. The draft allows both options. Please note that P2P mechanism does not aim to discover the "best" route; the aim is to discover "good enough" routes, i.e. the routes that meet the constraints listed in the Metric Container.

JP> New section to indicate how to clean-up the temporary DAG ?
MG> I guess it does not require a new section. I will make it explicit in the draft that a node SHOULD delete information about a temporary DAG once the duration of its membership in the DAG has exceeded the DAG's minimum life time.

Thanks
Mukul