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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 05 Nov 2009 16:42:07 -0000

#7: RPL bootstrap question: neighbor cache and DIOs dependency
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  pal@…              
     Type:  defect              |      Status:  new                
 Priority:  major               |   Milestone:                     
Component:  rpl                 |     Version:                     
 Severity:  Active WG Document  |    Keywords:                     
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * owner:  wintert@… => pal@…

-- 
Ticket URL: <http://tools.ietf.org/wg/roll/trac/ticket/7#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Nov 2009 09:56:31 -0800

On Oct 29, 2009, at 5:02 AM, roll issue tracker wrote:

> -------------------------------- 
> +-------------------------------------------
> Reporter:  jpv@…               |       Owner:  wintert@…
> -------------------------------- 
> +-------------------------------------------
> Email From Julien
>
> Hi all,
>
> as explained in section 5.4.2 of RPL, a DIO must not be processed if  
> the
> source is not in the neighbor cache. The question is how do we  
> expect the
> neighbor cache to be filled?

The current proposal is to change the direction of specification.

Rather than state a node MUST NOT process a DIO if the SRC is not a  
candidate neighbor, the document will state that a node MUST process a  
DIO if the SRC is a candidate neighbor. This rewording also removes  
the problem of a node ignoring DIOs.

Does anyone think this is not a good fix? What are people's opinions?

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 5 Nov 2009 10:48:42 -0800

On Nov 5, 2009, at 9:56 AM, Philip Levis wrote:

>> as explained in section 5.4.2 of RPL, a DIO must not be processed  
>> if the
> candidate neighbor, the document will state that a node MUST process  
> a DIO if the SRC is a candidate neighbor. This rewording also  
> removes the problem of a node ignoring DIOs.
>

I agree that Rule 2 of 5.4.2 is problematic.  Though, after your  
proposed fix, I'm not sure Rule 2 provides any value.  I would propose  
to simply strike Rule 2 from 5.4.2.

I think the real issue is with the "candidate neighbor" abstraction.   
Currently, as specified, candidate neighbor and DAG parent selection  
are independent processes.  These processes should be more coupled.   
For example, it is useful to also consider routing information  
contained within the DIO to determine if a neighbor should be a  
candidate neighbor.

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Nov 2009 11:24:58 -0800

On Nov 5, 2009, at 10:48 AM, Jonathan Hui wrote:

> proposed fix, I'm not sure Rule 2 provides any value.  I would  
> propose to simply strike Rule 2 from 5.4.2.
>
> I think the real issue is with the "candidate neighbor"  
> abstraction.  Currently, as specified, candidate neighbor and DAG  
> parent selection are independent processes.  These processes should  
> be more coupled.  For example, it is useful to also consider routing  
> information contained within the DIO to determine if a neighbor  
> should be a candidate neighbor.

I agree.

Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to know  
if implementers feel this makes things clearer. In this text, the  
neighbor set is an unconstrained set of L2 neighbors, the parent set  
is a subset of the neighbor set and is the set of candidate parents,  
and the parent is the element of the parent set that is the current  
next hop towards the DAG root. Note that this text discards the  
sibling notion for the simpler notion of limited local repair.

5.2 Neighbors, Parents, and Rank

  If Neighbor Unreachability Detection (NUD) determines that a
  neighbor is no longer reachable, then a RPL node
  MUST NOT consider this node a neighbor when calculating and
  advertising routes until the node determines it is reachable again.

  Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless
  it has  neighbors who have advertised that DAG ID.

  A RPL node that has issued a DIO for a DAGID I, DAG Instance N,
  and sequence number S MUST NOT consider neighbors for I,N whose
  last heard DIO for I,N had a sequence number < S.

  5.2.1 Parents

  By definition, DAG Roots do not have any DAG parents.

  RPL nodes that are not roots MAY maintain multiple candidate
  DAG parents for a single DAG Instance. The set of candidate DAG
  parents MUST be a subset of the set of neighbors. At any given
  moment, a node has a single DAG Parent, selected from the set
  of candidate DAG parents.

  5.2.2  DAG Rank

  DAG Rank is not a cost metric, although its value is derived from
  and influenced by route cost metrics. Rank is used to avoid and
  detect loops. A node's Rank MUST be higher than the Rank of its DAG
  Parent. The exact calculation of the Rank may depend on the set of
  candidate DAG parents, link metrics, node configuration, and the DAG
  Instance OF.

5.3.  DAG Discovery and Maintenance

  DAG discovery forms a Directed Acyclic Graph towards a DAG Root
  by identifying a set of candidate DAG parents and selecting a member
  of the set as its DAG parent. DAG discovery also discovers neighbors,
  which may be used to provide additional path diversity when a node
  needs to move downward in the DAG. DAG discovery avoids
  loops by constraining when and how nodes can increase their Rank.
  RPL uses an IPv6 optional header in data packets to detect loops.

5.3.1.  DAGs

  1.  A node MAY belong to multiple DAG Instances.

  2.  A DAGID, InstanceID, and DAGSequence number uniquely defines
      a DAG iteration. All of a node's candidate parents within a DAG
      instance MUST belong to the same DAG iteration: the last heard
      DIO from candidate parents must be for the same DAG iteration.

  3.  Within a given DAG instance, a node that is a not a root MUST NOT
      advertise a DAGSequenceNumber higher than the highest
      DAGSequenceNumber it has heard.

  4.  The DAGSequenceNumbers a node advertises for a DAG instance MUST
      monotonically increase, barring wrap-around as covered in X.

  5.  DAG Roots MAY increment the sequence number they advertise.

  6.  A node MUST advertise the same DAGSequenceNumber as its
      DAG Parent.

5.3.2.  DAG Roots

  1.  A DAG Root that does not have Internet connectivity to nodes
      outside the DAG MUST NOT set the Grounded bit.

  2.  A DAG Root MUST advertise a rank of ROOT_RANK.

5.3.3.  Rank and DAG Movement

  1.  A node MUST NOT advertise a Rank less than or equal to
      its DAG parent.

  2.  A node MAY advertise a Rank lower than its prior advertisement.

  3.  A node MAY advertise a Rank higher than its prior advertisement.
      If the lowest prior Rank advertised for a DAG iteration is L, a
      node MUST NOT advertise a Rank > L + DAGMaxRankIncrease.

  4.  A node MAY, at any time, choose to join a different DAG within
      a DAG Instance. Such a join has no Rank restrictions. Until a
      node transmits a DIO indicating its new position, it MUST forward
      packets along the previous DAG.

  5.  Joining different DAGs does not preclude rule 3. A node that  
leaves
      a DAG iteration and rejoins it later must still obey rule 3 for  
that
      DAG iteration.

5.3.4 Parent Set Depletion

  1.  If a node has no candidate parents, it MAY leave the DAG  
iteration and
      advertise itself as the root of a floating DAG. Such a DIO
      MUST have the same DAG InstanceID as the DAG iteration and a  
cleared
      Grounded flag.

  2.  If a node does not form a floating DAG, then the node MUST  
advertise
      a rank of INFINITE_RANK within the DAG iteration.

  3.  If a node that receives a DIO from one of its DAG parents
      indicating that the parent has left the DAG, it may either follow
      that parent or stay in its current DAG through an alternate DAG
      parent if that is possible.

5.4.  DIO Message Communication

  When an DIO message is received from a source device named SRC, the
  receiving node must first determine whether or not the DIO message
  should be accepted for further processing, and subsequently present
  the DIO message for further processing if eligible.

5.4.1.  Determination of Eligibility for DIO Processing

  If the DIO source is a member of the candidate neighbor set,
  the node MUST process it.

5.4.2.  DIO Message Processing

  When a node processes a DIO from a member of its candidate neighbor
  set, it MUST update all relevant state maintained on that neighbor.
  For example, if a node receives a DIO advertising a different Rank,
  it must update its state to denote the neighbor's new Rank.

5.4.3.  DIO Transmission

  Each node maintains a timer that governs when to multicast DIO
  messages.  This timer is a trickle timer, as detailed in Section 5.X.
  The DIO Configuration Option describes the configuration of a DAG  
Instance's
  trickle timer.

  o  When a node chooses a DAG parent that changes its DAG iteration,
     it MUST reset the trickle timer to its minimum value.

  o  When a node receives a packet to forward from a node with a lower  
or
     equal rank, it has detected an inconsistency in the DAG. In this
     case, the node MUST reset the trickle timer to its minimum value.
     Section Y describes how a node can detect this.

  o  When a node receives a DIS, it MUST reset the trickle timer to
     the minimum value.

  o  If a node is not a member of a DAG, it MAY suppress transmitting
     DIO messages.

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Thu, 5 Nov 2009 12:17:50 -0800

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)

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".

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.

Thanks,
Steve

On Thu, Nov 5, 2009 at 11:24 AM, Philip Levis <[email-masked]> wrote:
>> I agree that Rule 2 of 5.4.2 is problematic.  Though, after your proposed
>> fix, I'm not sure Rule 2 provides any value.  I would propose to simply
>> strike Rule 2 from 5.4.2.
>>
>>  Currently, as specified, candidate neighbor and DAG parent selection are
>> independent processes.  These processes should be more coupled.  For
>> example, it is useful to also consider routing information contained within
>> the DIO to determine if a neighbor should be a candidate neighbor.
>
> I agree.
>
> Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to know if
> implementers feel this makes things clearer. In this text, the neighbor set
> is an unconstrained set of L2 neighbors, the parent set is a subset of the
> neighbor set and is the set of candidate parents, and the parent is the
> element of the parent set that is the current next hop towards the DAG root.
> Note that this text discards the sibling notion for the simpler notion of
> limited local repair.
>
>  5.  Joining different DAGs does not preclude rule 3. A node that leaves
>     a DAG iteration and rejoins it later must still obey rule 3 for that
>     DAG iteration.
>
>  1.  If a node has no candidate parents, it MAY leave the DAG iteration and
>     MUST have the same DAG InstanceID as the DAG iteration and a cleared
>     Grounded flag.
>
>  2.  If a node does not form a floating DAG, then the node MUST advertise
>  o  When a node receives a packet to forward from a node with a lower or
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 5 Nov 2009 12:31:07 -0800

On Nov 5, 2009, at 11:24 AM, Philip Levis wrote:

> Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to  
> know if implementers feel this makes things clearer. In this text,  
> the neighbor set is an unconstrained set of L2 neighbors, the parent  
> set is a subset of the neighbor set and is the set of candidate  
> parents, and the parent is the element of the parent set that is the  
> current next hop towards the DAG root. Note that this text discards  
> the sibling notion for the simpler notion of limited local repair.

This text is definitely moving in the right direction.

> last heard DIO for I,N had a sequence number < S.

I'd change "MUST NOT consider neighbors" to "MUST NOT consider nodes  
as neighbors", or some other wording that cannot be misinterpreted as  
"MUST NOT process messages from neighbors".

> of candidate DAG parents.

Not sure why we have to single out THE DAG parent.  The DAG is a DAG  
because a node can maintain more than one candidate parent.  Choosing  
a candidate parent is what defines the forwarding (not routing)  
topology.  More related to this subject below.

> candidate DAG parents, link metrics, node configuration, and the DAG

I'd say that the advertised Rank MUST be higher than the Rank of its  
candidate DAG parents, not just the a chosen DAG parent.  We use the  
DAG to identify assign nodes relative position within the network.  It  
doesn't make sense to have a candidate DAG parent that has a higher  
Rank.

>     DIO from candidate parents must be for the same DAG iteration.

Why not allow a node advertising DAG sequence N forward to a node with  
DAG sequence N+1?  Communication delays means that we can't guarantee  
that this won't happen.  So why restrict it even when we know this is  
true?

> 6.  A node MUST advertise the same DAGSequenceNumber as its

Or at least what it thinks the DAGSequenceNumber is for its DAG  
Parent.  This comes back to my previous point - when a new sequence  
number is propagating, nodes will (temporarily) have parents in one  
iteration, and others in another iteration.  I don't think we should  
restrict implementations from waiting for some time to wait for its  
DAG parents to catch up to the current iteration - but I don't think  
we should recommend it either.

The rest looks good to me.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 5 Nov 2009 12:37:58 -0800

Hi Stephen,

Your observations reflect a current debate on how much to specify.  On  
one hand, we want to specify a minimial architecture that will provide  
the flexibility to incorporate and evaluate new mechanisms.  On the  
other hand, we want something that will work "well" out of the box.   
The issues permeate the entire document (use of hold-up/hold-down  
timers, backtracking on DA errors, utilization of sibling links,  
selecting neighbors, selecting candidates, etc.).  The issue of "what  
is enough" is fairly deep and I hope we can come to some common ground  
on this issue in Hiroshima.

--
Jonathan Hui

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

>>> proposed
>> know if

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Nov 2009 21:02:24 -0800

On Nov 5, 2009, at 12:31 PM, Jonathan Hui wrote:

>> the neighbor set is an unconstrained set of L2 neighbors, the  
>> parent set is a subset of the neighbor set and is the set of  
>> candidate parents, and the parent is the element of the parent set  
>> that is the current next hop towards the DAG root. Note that this  
>> text discards the sibling notion for the simpler notion of limited  
>> local repair.
>
> as neighbors", or some other wording that cannot be misinterpreted  
> as "MUST NOT process messages from neighbors".

I agree.

> because a node can maintain more than one candidate parent.   
> Choosing a candidate parent is what defines the forwarding (not  
> routing) topology.  More related to this subject below.

I agree. I was trying to distinguish the parent of the moment from the  
set of candidate parents. Does that make sense? Do you have a  
suggestion on how to reword this?

> DAG to identify assign nodes relative position within the network.   
> It doesn't make sense to have a candidate DAG parent that has a  
> higher Rank.

Makes sense.

> Why not allow a node advertising DAG sequence N forward to a node  
> with DAG sequence N+1?  Communication delays means that we can't  
> guarantee that this won't happen.  So why restrict it even when we  
> know this is true?

I don't think rule 2 restricts this -- rule 6 does. Let me explain  
where this rule was going -- it's trying to enforce that a node can't  
perpetually avoid incrementing its sequence number. The rule you  
suggested -- a node MUST NOT advertise a sequence number lower than  
all of its candidate parents -- can have issues when DIOs are lost.  
The goal of this rule is that a node can observe candidate parents  
increasing their sequence numbers, but continue to use ones that  
haven't. Then, at some point, it makes the decision to switch to the  
subset with the newer sequence number, and increments its own.

> we should recommend it either.

Yeah -- I think this text needs to distinguish "the last sequence  
number it heard from its a candidate parent" and "the candidate  
parent's sequence number."

Phil

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Nov 2009 21:53:14 -0800

> 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.

> 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.

> 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

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Fri, 6 Nov 2009 01:49:42 -0800

On Thu, Nov 5, 2009 at 9:53 PM, Philip Levis <[email-masked]> wrote:
> 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.

Point taken, although your text is fairly clear here.  If I hear a DIO
with a new sequence number from a neighbor, I MUST update his
information in my table.  Furthermore, I MUST only keep parents with
the same instance ID in my feasible parents set, so I must either
remove the guy with the new sequence number from the set or else
remove everyone else (at least until they too update their sequence
number).  At some point, I switch over to the new sequence number;
when I do, I will have heard a updated DIO message from each of the
guys in the new candidate parent set.  For this reason, I think it
would be fair to say that the effect of incrementing the sequence
number at the root is to force a refresh of all candidate parent sets
within the dag-- doesn't seem up for interpretation.

Also, in 5.3.1, #3 and #6 seem more-or-less redundant-- if I must
advertise my parent's sequence number, it will not be higher then any
number I have heard.

Thanks.
Steve

> 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
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 12:02:47 +0100

>suggestion on how to reword this?

We need the concept of 'preferred' parent to inherit a number of metrics
from, and to compute self's rank. So we have a set of current parents
and sibling and in that set, there's the preferred one.

>> It doesn't make sense to have a candidate DAG parent that has a

We took great care in the current wording. Can be simplified and Phil is
very goo d at it. But I suggest we do not make too many changes in one
thread. Can we take it rule by rule?

>subset with the newer sequence number, and increments its own.

We have the concept of future parent; same DODAG, future instance; the
text says that you can forward to a future parent but you must set the
rank to infinite to avoid false positives in loop detection.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 13:12:46 +0100

Hi Julien:

For me a validation is at least a bidir. NUD is a revalidation.

What do you think?

Pascal

>-----Original Message-----

>From: Julien Abeille (jabeille)

>Sent: jeudi 29 octobre 2009 15:55

>To: Pascal Thubert (pthubert); [email-masked]; [email-masked]

>Cc: roll

>Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor cache
andDIOs dependency

>Hi Pascal,

>What I was trying to achieve is the validation. I was trying to see if
standard ND (let's not diverge) can

>achieve this. With a LLAO, the entry would be created (STALE), then the
first time you want to route a packet

>through the router that originated the DIO, you would send the packet,
arm a delay timer... do NUD as usual.

>Comment on this:

>- depends on 6lowpan discussions...

>questions:

>- do we think this is enough?

>- otherwise do we need to specify a custom mechanism inside RPL?

>Best,

>Julien

>> -----Original Message-----

>> From: [email-masked] [mailto:[email-masked]] On

>> Behalf Of Pascal Thubert (pthubert)

>> Sent: jeudi 29 octobre 2009 15:46

>> To: [email-masked]; [email-masked]

>> Cc: roll

>> Subject: Re: [Roll] [roll] #7: RPL bootstrap question:

>> neighbor cache andDIOs dependency

>> Hi:

>> In fact a stale entry is not sufficient. We need an entry

>> that is reachable.

>> That is the minimum validation process that comes with the

>> fact that the draft as it stands today depends on NS/NA flows

>> to ensure bidir connectivity with the neighbor. The way I see

>> it, the node should at least unicast NS to the candidate to

>> assert that. In the same fashion as NUD allows the node to

>> remove the parent. But if a stronger validation mechanism is

>> in place, then that should supersede the NS/NA.

>> Soon enough we might need to elaborate a bit on the

>> validation process. In some environments, it can be done as

>> part of metrics computation, like using srcr results for

>> instance. Things like that cannot be in the base spec but

>> then, do that belong to metrics, a new draft, or should

>> validation above and beyond NS/NA be left to implementation?

>> >-----Original Message-----

>> >From: [email-masked] [mailto:[email-masked]]

>> On Behalf Of

>> >roll issue tracker

>> >Sent: jeudi 29 octobre 2009 13:02

>> >To: [email-masked]; [email-masked]

>> >Cc: [email-masked]

>> >Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor

>> cache and

>> >DIOs dependency

>> >--------------------------------+----------------------------

>> ----------

>> >--------------------------------+-----

>> > Reporter:  jpv@...               |       Owner:  wintert@...

>> >--------------------------------+----------------------------

>> ----------

>> >--------------------------------+-----

>> > as explained in section 5.4.2 of RPL, a DIO must not be

>> processed if

>> > the source is not in the neighbor cache. The question is how do we

>> > expect the neighbor cache to be filled?

>> > topology:

>> > A

>> > |

>> > B

>> > B receives a DIO from A, A is not in B's neighbor cache:

>> > NS/NA exchanges will probably not occur, as B has no good reason to

>> > send packets to A (A is not a router for B, B has most of

>> the time no

>> > data to send to A) RS/RA exchanges: do we expect to send RAs in RPL

>> > environments? Would this be enough?

>> > If there are no frequent RAs, or unsolicited NAs, then A

>> will likely

>> > never be in B's neighbor cache.

>> > One way to solve this would be to allow SLLAO option in DIOs.

>> > Processing this option in ICMP messages (NS, RS, RA) is a

>> well known

>> > process, and would create an entry in the neighbor cache,

>> state STALE.

>> > what do you think?

>> > Julien

>> > __________

>> >Ticket URL: <http://rsync.tools.ietf.org/wg/roll/trac/ticket/7>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 13:50:51 +0100

Hi Pascal,
 
NUD is not always done after validation. It is also done when there is a
certain probability of validity. this is what the LLAO option in
RS/RA/NS do, e.g.:
- node A has no entry for node B
- node B sends RS/RA/NS with SLLAO -> node A creates entry in stale
(reachability is not confirmed)
- node A has a packet to send to B, sends the packet then does NUD after
5s.
In this case node B was never in reachable state before NUD. This is
what is being dond in every IPv6 implementation since a decade with
RS/RA/NS.
 
questions:
- are we ok to accept a parent if it is just STALE (because the LLAO
option was there) but bidirectionality is not sure?
- if no, what is the proposed way to populate the neighbor cache? In
real life this will not happen by magic: 
if i do not have a packet to send to a neighbor, i do NOT do address
resolution. But if i do not have a parent entry for this node, there is
in many cases NO reason to send a packet to this node (chicken egg),
because this node is just a router for me. E.g in a MP2P application,
all nodes want to send to the sink. Only nodes that are within reach of
the sink will try to send a packet to the sink, which will be their
parent. They will try to send data, it will trigger creation of the
neighbor entry, DIOs will be accepted. All other nodes will never have
an entry for their neighbors/potential parents.
 
Best,
Julien 

________________________________

	From: Pascal Thubert (pthubert) 
	Sent: lundi 9 novembre 2009 13:13
	To: Julien Abeille (jabeille); [email-masked]';
[email-masked]'
	Cc: 'roll'
	Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor
cache andDIOs dependency

	Hi Julien:

	 

	What do you think?

	Pascal

	>Subject: RE: [Roll] [roll] #7: RPL bootstrap question: neighbor
cache andDIOs dependency

	>What I was trying to achieve is the validation. I was trying to
see if standard ND (let's not diverge) can

	>achieve this. With a LLAO, the entry would be created (STALE),
then the first time you want to route a packet

	>through the router that originated the DIO, you would send the
packet, arm a delay timer... do NUD as usual.

	>> >Ticket URL:
<http://rsync.tools.ietf.org/wg/roll/trac/ticket/7>

---

From: Philip Levis <[email-masked]>
Date: Mon, 9 Nov 2009 09:01:55 -0800

> For me a validation is at least a bidir. NUD is a revalidation.

There are no Held-up or Held-down states in -04. So this figure is  
incorrect.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 11 Nov 2009 08:32:30 -0800

> Does anyone think this is not a good fix? What are people's opinions?

Are there any objections to this fix for -05? If not, we'll apply it.

Phil

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 12 Nov 2009 19:56:46 -0000

#7: RPL bootstrap question: neighbor cache and DIOs dependency
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  pal@…              
     Type:  defect              |       Status:  closed             
 Priority:  major               |    Milestone:                     
Component:  rpl                 |      Version:                     
 Severity:  Active WG Document  |   Resolution:  fixed              
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by pal@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 The text in -05 will change from

 "If SRC is not a member of the candidate neighbor set, then the DIO
  is not eligible for further processing.  (Further evaluation/
  confidence of this neighbor is necessary)"

 to

 "If SRC is a member of the candidate neighbor set, then the node MUST
 process the DIO."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/7#comment:2>
roll <http://tools.ietf.org/wg/roll/>