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

From: Mukul Goyal <[email-masked]>
Date: Sun, 20 Jun 2010 23:02:32 -0500 (CDT)

Hi JP

Here are the responses to your comments on Section 4 of the draft. I guess I should make it clear in the beginning of the section that it is a high level description of the mechanisms proposed in the draft. I am opening a new thread to discuss your last comment.

Thanks
Mukul

4.  Functional Overview

   Router A originates a "Discovery" message listing router B as the
   target.  Node A also indicates in the message:

   o  The nature of the routing cost, the method for accumulating the
      end-to-end cost 

JP> This may de detailed hereafter but I guess that you will point to the metric-ID for the metric used?
MG> This section is a high level description. The implementation in terms of ROLL is specified in the later sections. I guess I should make it clear in the beginning of this section.

and the criteria used to determine if a route is
      "good enough";

   o  The direction (forward: router A to router B; backward: router B
      to router A; or both) of the route being discovered;

   o  The desired number of routes;

   o  Whether the route is a source-route or a hop-by-hop one; and

   o  A limit on the "distance" the Discovery message may travel.

JP> Need to define the term "distance": is it a max path cost, number ofhops, ... ?

MG> Again, this is high level description. The concept of distance is elaborated later in the section, whereas its implementation (in terms of max rank) is specified in the next section.

The Discovery message propagates via link-local multicast 
JP> Indicate "IPv6"
MG> I can, but is it OK to do so in high level description?

with each
   receiving router making the decision regarding whether to forward the
   message further based on the "distance" (from router A) that this
   particular copy of the message has already traveled.  Note that this
   document does not require a receiving router to use the "good enough"
   criteria to make the forwarding decision.  This is because the
   evaluation of such criteria may be too complex for a constrained
   intermediate router to perform for each received copy of the
   Discovery message.  

JP> So I guess that you define later what to do in both cases (the nodecannot process the "good enough" criteria or it can process it) ?
MG> As specified later in the section, using the good enough criteria is optional for making the discovery message forwarding decision.

The calculation of the "distance" that a copy of
   the Discovery message has already travelled should be simple enough
   for a constrained router to perform.  
JP> Again it is hard to tell from what you wrote if this can reasonably beachieved; it depends on the definition of the term "distance".
MG> Yes. Again, this is high level description. The definition comes later.

A router may optionally decide
   not to forward a copy of the Discovery message further because the
   aggregated cost of the route so far fails the "good enough" criteria.

JP> You will nee to be more specific here. Is it a "may" or a "MAY". Define what happens in this case. You may provide more details laterin the document.
MG> Do we use MAY etc. in high level description? I will change the text accordingly.

The underlying mechanism being used to propagate the Discovery
   message may put further restrictions on its propagation.  A router
   should not propagate the Discovery message further if hop-by-hop
   routes are desired and the router can not store state for this route.

   As a copy of the Discovery message travels towards router B, it
   accumulates the relevant forward/backward costs as well as the route
   it takes.  When router B receives a copy of the Discovery message, it
   determines whether the route traveled by the message meets the "good
   enough" criteria.
JP> I think that you already mentioned this.

   If router A had requested the discovery of backward source-routes,
JP> Didn't you mean "forward" ?
MG> No, "backward". The mechanism allows discovery of forward, backward as well as bidirectional source and hop-by-hop routes.

router B caches one or more good enough source-routes it identifies.
   Additionally, router B sends one or more "Discovery Reply" message to
   router A to acknowledge the discovery of these routes.  These
   acknowledgements allow router A to judge the success of the route
   discovery.  The Discovery Reply messages can travel towards router A
   in any manner chosen by router B. For example, router B may source-
   route the messages or send them towards router A along a DAG.

   If router A had requested the discovery of "n" forward source-routes,
   router B sends the "n" good enough source-routes it identifies to
   router A in one or more Discovery Reply messages.  Again, these
   Discovery Reply messages can travel towards router A in any manner
   chosen by router B.
JP> What if the DAG is "broken": retry from A after expiration of a localtimer ?
MG> Discovery Reply messages can travel towards the origin router in _any_ manner. So, these messages MAY travel along a source route or along a pre-existing DAG or along the temporary DAG. There is no ack for Discovery Reply messages, so there is no attempt to retransmit them.

If router A had requested the discovery of "n" bidirectional source-
   routes, router B caches the "n" good enough source-routes it
   identifies and also sends these routes to router A in one or more
   Discovery Reply messages.  These Discovery Reply messages can travel
   towards router A in any manner chosen by router B.

   If router A had requested the discovery of "n" forward/backward/
   bidirectional hop-by-hop routes, router B sends out a Discovery Reply
   message to router A for each one of the "n" good enough routes it
   identifies.  
JP> Do you need one "Discovery Reply message" per route or next-hopin this case?
MG> To establish a hop-by-hop route, we need one Discovery Reply message per route. This message will travel from the target router to the origin router and establish the hop-by-hop path.

The Discovery Reply message travels towards router A
   using the source-route accumulated by the Discovery message.  
JP> In the case of hop-by-hop routes, source routes, both ?
MG> The Discovery Reply message needs to travel along the source-route accumulated by the Discovery message only in case of hop-by-hop routes. It is optional in case of source routes. I will make this explicit in the next version of the draft.

As this
   message travels towards router A, it establishes appropriate forward/
   backward routing state in the en-route routers.  This "non DAG"
   routing state should be specially marked to associate it with the
   routing metrics 
JP> Refer to metric ID ?
MG> OK.

used to discover the route and to distinguish such
   state from other DAG-specific routing state the router may have.
JP> Not sure that you need to distinguish the state. Suppose that you discover a hop-by-hop route (not a big fan of that terms as pointed outabove but let's continue to use it for the time being), a storing node may indeed have two routes for the same destination: do you want to state that it should always use the P2P routes discovered by this mechanism or let it choose the best one according to the metric inuse?

MG> As hopping from one DAG to another may lead to routing loops, hopping from a non-DAG route to a DAG may also lead to routing loops. So, I guess a packet should travel along a DAG only if a header in the packet requires it to travel along a particular DAG. 
Now, the other question is how does a packet, that wants to travel along a particular P2P hop-by-hop route, specify its preference for such a route? I guess we need some sort of labeling mechanism here. Any suggestions regarding how will it work? (I will open a separate thread for this issue).
  
JP> What if there are two routes using different metrics?
MG> Good question. I am opening a new thread for this discussion.

Thanks
Mukul