Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency

[Philip Levis <pal at cs.stanford.edu>]

On Nov 5, 2009, at 12:17 PM, Stephen Dawson-Haggerty wrote:

> In general it's a lot shorter and easier to understand, which is
> great.  Was is this a replacement or an addition?  A lot of mechanical
> text was removed and I don't know if it's intentional (like in 5.4.2,
> when it enumerated when you would discard a message)-- the new one
> seems a little more vague about who I'm supposed to store in my
> candidate parent sets (5.2)

Ah -- I think the intention is to keep that as an implementation  
detail, to leave flexibility.

The enumeration of discard cases were, I thought, a bit backwards. Of  
course you discard malformed messages. Following the response I had to  
one of the open tickets, it seems to make more sense to state when RPL  
MUST process a message rather than when it MUST NOT, in part because  
the MUST NOT introduces bootstrapping problems.


> Also, we lost some of the text explaining why you might want to
> increment the dag sequence number (it's split between 5.4.3, 5.3.3,
> and 5.3.1).  I would have appreciated a sentence towards the beginning
> something like "The effect of incrementing the DAG sequence number is
> to trigger additional DIO transmissions.  This serves as an
> implementation-controlled mechanism to rebuild forwarding tables among
> members of a DAG instance".

The term used is "global repair." I might be OK saying "this can serve  
as an implementation-controlled mechanism," but stating the total  
purpose of a mechanism is problematic. If someone later down the line  
starts using it for something else... does that make sense.

> Neither document does a great job of explaining the role of the
> neighbor set in forwarding, in particular I couldn't find a place
> where it said that you might try multiple parents for the same packet.

Agreed. I didn't get to forwarding yet. Clearly it needs to be there.  
The text would be simple: you forward packets to your parent, which  
MUST be a member of the candidate parent set. A node MAY change which  
element of its candidate parent set is its parent at any time. A given  
implementation might apply certain heuristics (e.g., for stability),  
but we don't want to constrain the parent selection process. We do  
want to constrain the set of nodes that can be candidate parents.

Phil