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

From: Mukul Goyal <[email-masked]>
Date: Mon, 21 Jun 2010 00:40:09 -0500 (CDT)

Hi JP

Here is response to some of the comments you had on Section 5. The other comments are editorial and I will take care of them in the next version of the draft.

Thanks
Mukul 

A DIO, that contains a Route Discovery option with O flag set, MUST
   also contain a Metric Container option immediately following the
   Route Discovery option.  This Metric Container option carries the
   values for the routing metrics as well as the constraints
   (constituting the "good enough" criteria) used for route selection.

JP> This is confusing: the metric and constraint carried within the MetricContainer are used for the DODAG formation. Do you want to use themfor a different purpose ? At this point, you have not yet defined the use of the good enough criteria but one can guess that you would use the good enough metrics to control the flooding and the metric/OF to effectively build the temporary DAG and discover the routes. If so, the good enough metrics are of different use.

MG> In case the metrics/constraints being used for temporary DAG formation are not same as the ones being used for route discovery, there will be two Metric Containers - one carrying metrics/constraints for DAG formation and other for route discovery. The good enough criteria is not used to control flooding. It is used by the target router to determine if a discovered route is good enough.

Maintaining membership in the DAG implies remembering:

   o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
      temporary DAG;

   o  The router's rank in the temporary DAG;

   o  The best Metric Container, 
JP> you mean the best path cost?
MG> The Metric Container associated with route discovery will consist of the constraints (the good enough criteria) and the aggregated/recorded values of the metrics being used in these constraints. If a router can compare Metric Containers, it will keep in memory the best Metric Container it has to advertise. Otherwise, it will simply reset the trickle timer on receiving a new DIO (unless the reset trickle timer is already running) and include the latest Metric Container it has received in the DIO generated on the firing of the trickle timer.

along with the associated source route
      from the initiator of route discovery till this router (carried in
      a Record Route IPv6 Extension Header proposed in
      [I-D.thubert-6man-reverse-routing-header]), for the Route
      Discovery option being propagated by the temporary DAG.  If the
      router can not compare Metric Containers, it MUST remember the
      latest Metric Container it has received, along with the associated
      source route.
JP> Requires clarification on what you mean by "compare"
MG> Some times, the Metric Containers will be easy to compare. E.g. if the good enough criteria (specified as a constraint) is that ETX must be less than 10, the Metric Container will contain two objects: one constraint (ETX must be less than 10) and one aggregated value for the ETX so far. Here, comparing the Metric Container simply means comparing the aggregated ETX values. In case of Metric Containers carrying multiple metrics, comparison will not be possible. I will make this clear in the text.

A router belonging to a temporary DAG need not remember the identity
   of its DAG parents since the temporary DAG is not used for routing.
JP> Are you sure ? What is a hop-by-hop route is needed ? Don't youneed to remember your parent, or do you still record the route ?
MG> Hop-by-hop routes are established by Discovery Reply messages traveling towards the origin router (along the source-route accumulated by the corresponding Discovery message).

The router does not process a Route Discovery option, contained in
   the received DIO, any further if any of the following conditions are
   true:

   o  The router does not support the objective function 
JP> and/or metrics
MG> Well, this text would change now since I dont think we need any OF at all in the Route Discovery option. As I mentioned in a previous email, the good enough criteria is a bunch of constraints and dont need any OF.

The target router then checks the Metric Container to
   determine if the aggregated values for the routing metrics meet all
   the constraints listed in the Metric Container.  
JP> See previous comments.

If not, the Route
   Discovery option is discarded without further processing.  Otherwise,
   the router MAY select the source route accumulated by the received
   DIO as one of the discovered routes.  
JP> "MAY" ? When ?
MG> This is an implementation detail. The target router may want to select the first "n" routes that meet the good enough criteria or it may want to wait over a time window and select the best routes (that meet the good enough criteria) discovered during this window.