Subject: Re: [Roll] An alternative to RPL

From: Mukul Goyal <[email-masked]>
Date: Thu, 30 Jul 2009 07:50:32 -0500 (CDT)

Hi Jerry,

Thanks for your comments. Please see the response inline.

>Attached are my comments on your submission.  In total, I like the approach.  The idea of monitoring and repairing loops rather than architecturally disallowing loops is simple and seems effective.   

>I can't say I completely understood the entire draft.  I think a few well placed examples would help.

I will add examples to the draft.

>Also there seems to be cases (see p7) where you temporally eliminate route discovery requests.  Not sure why this is needed.   

Not sure what you mean. There seems to be some misunderstanding. The route discovery requests are never eliminated.
  
>Following are my detailed comments. 

>p4: Routing domains 

>I am not sure why we would want to define routing domains.  This is extra configuration effort that doesn't necessarily add any value.  I wouldn't know a priori how to define the logical entities. 

The routing domains are required to limit the scope of route discovery. We do not want all 10K nodes in the network to know that A wants to find a route to B. The idea is that if we could define routing domains such that most source-destination pairs lie in the same domain, route discovery can be restricted to nodes within the domain. Ofcourse, some destinations can be universal, i.e. route discovery for these destinations have network-wide scope. Also, for small networks, it may be OK to not have routing domains at all. My hope is that, most of the times, routing domains can be defined using natural divisions in the network.

>p5:#4:Routing Table 

>The neighbor discovery process is different than 6LoWPANs.  Can't we build the neighbor lists using 6LoWPAN ND algorithms? 

Yes, we should be able to do that.

>p7:bullet 6 

>I don't understand why we would build a list of all unreachable destinations. 

When a router sends an RA listing a bunch of destinations for which route discovery is desired, the receiving router should enter the destinations, for which it does not yet know the routes, to its route discovery and maintenance tables so that it can advertise the need to find routes to these destinations further in its own RAs. Ofcourse, the local policy can always be enforced to decide whether to create new entries in the route discovery and maintenance tables or not.

Thanks
Mukul

---

From: Umair Bussi <[email-masked]>
Date: Thu, 30 Jul 2009 06:42:28 -0700 (PDT)

Regards,
Umair

--- On Thu, 7/30/09, Mukul Goyal <[email-masked]> wrote:

> From: Mukul Goyal <[email-masked]>
> Subject: Re: [Roll] An alternative to RPL
> To: "Jerald P Martocci" <[email-masked]>
> Cc: "roll" <[email-masked]>, [email-masked]
> Date: Thursday, July 30, 2009, 12:50 PM
> Hi Jerry,
> 
> >Attached are my comments on your submission.  In
> total, I like the approach.  The idea of monitoring and
> repairing loops rather than architecturally disallowing
> loops is simple and seems effective.   
> 
> >I can't say I completely understood the entire draft.
>  I think a few well placed examples would help.
> 
> >Also there seems to be cases (see p7) where you
> temporally eliminate route discovery requests.  Not sure
> why this is needed.   
> 
> Not sure what you mean. There seems to be some
> misunderstanding. The route discovery requests are never
> eliminated.
>   
> >I am not sure why we would want to define routing
> domains.  This is extra configuration effort that doesn't
> necessarily add any value.  I wouldn't know a priori how to
> define the logical entities. 
> 
> The routing domains are required to limit the scope of
> route discovery. We do not want all 10K nodes in the network
> to know that A wants to find a route to B. The idea is that
> if we could define routing domains such that most
> source-destination pairs lie in the same domain, route
> discovery can be restricted to nodes within the domain.
> Ofcourse, some destinations can be universal, i.e. route
> discovery for these destinations have network-wide scope.
> Also, for small networks, it may be OK to not have routing
> domains at all. My hope is that, most of the times, routing
> domains can be defined using natural divisions in the
> network.

I am unable to realize the idea. What logic is going to be used. Will it be dependent on physical arrangemnet and going to be configured after deployment.

> 
> >p5:#4:Routing Table 
> 
> >The neighbor discovery process is different than
> 6LoWPANs.  Can't we build the neighbor lists using 6LoWPAN
> ND algorithms? 
> 
> When a router sends an RA listing a bunch of destinations
> for which route discovery is desired, the receiving router
> should enter the destinations, for which it does not yet
> know the routes, to its route discovery and maintenance
> tables so that it can advertise the need to find routes to
> these destinations further in its own RAs. Ofcourse, the
> local policy can always be enforced to decide whether to
> create new entries in the route discovery and maintenance
> tables or not.
> 
> Thanks
> Mukul
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: [email-masked]
Date: Thu, 30 Jul 2009 09:42:22 -0500

Comments on comments below...

Mukul Goyal <[email-masked]> 
07/30/2009 07:50 AM

To
Jerald P Martocci <[email-masked]>
cc
roll <[email-masked]>, [email-masked]
Subject
Re: [Roll] An alternative to RPL

Hi Jerry,

>Attached are my comments on your submission.  In total, I like the 
approach.  The idea of monitoring and repairing loops rather than 
architecturally disallowing loops is simple and seems effective.   

>Also there seems to be cases (see p7) where you temporally eliminate 
route discovery requests.  Not sure why this is needed.   

Not sure what you mean. There seems to be some misunderstanding. The route 
discovery requests are never eliminated.

I'm probably misreading the text.  Here's the paragraph...

   o  An existing route discovery table entry is refreshed, i.e. allowed
      to exist for a certain additional time duration, if it was created
      in response to an RA from this router and the current RA includes
      in its route discovery list the destination corresponding to this
      entry.
 
The phrase "allowed to exist for a certain additional time duration" 
implies to me that route discovery entries are temporal.  I would think 
that as long as the route is valid, it would be kept.

>I am not sure why we would want to define routing domains.  This is extra 
configuration effort that doesn't necessarily add any value.  I wouldn't 
know a priori how to define the logical entities. 

The routing domains are required to limit the scope of route discovery. We 
do not want all 10K nodes in the network to know that A wants to find a 
route to B. The idea is that if we could define routing domains such that 
most source-destination pairs lie in the same domain, route discovery can 
be restricted to nodes within the domain. Ofcourse, some destinations can 
be universal, i.e. route discovery for these destinations have 
network-wide scope. Also, for small networks, it may be OK to not have 
routing domains at all. My hope is that, most of the times, routing 
domains can be defined using natural divisions in the network.

Ah!!!  ok.  I wasn't thinking about 10K LLN deployments.  In the building 
market we have maybe 250 nodes in the LLN.  I'm fine with defining domains 
so that the default is the entire LLN.  This way for small LLNs, there 
would be no additional work.

>The neighbor discovery process is different than 6LoWPANs.  Can't we 
build the neighbor lists using 6LoWPAN ND algorithms? 

Good.  We should leverage other work whenever possible.

>I don't understand why we would build a list of all unreachable 
destinations. 

When a router sends an RA listing a bunch of destinations for which route 
discovery is desired, the receiving router should enter the destinations, 
for which it does not yet know the routes, to its route discovery and 
maintenance tables so that it can advertise the need to find routes to 
these destinations further in its own RAs. Ofcourse, the local policy can 
always be enforced to decide whether to create new entries in the route 
discovery and maintenance tables or not.

ok.  Makes sense now.

Thanks
Mukul