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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 29 Oct 2009 12:02:16 -0000

#7: RPL bootstrap question: neighbor cache and DIOs dependency
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  wintert@…      
     Type:  defect              |      Status:  new            
 Priority:  major               |   Milestone:                 
Component:  rpl                 |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------
 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?
 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>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Oct 2009 15:45:37 +0100

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?

Pascal

>-----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
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Thu, 29 Oct 2009 07:51:50 -0700

On Oct 29, 2009, at 7:45 AM, Pascal Thubert (pthubert) wrote:

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

I think it should be left to implementations. Every time we specify  
something, we increase the complexity of the protocol and limit  
flexibility in future uses. We should only include something when we  
know for sure that there's one by-far-better way to do things  
(unlikely for almost anything in wireless), or when a property is  
needed for correctness.

Phil

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 29 Oct 2009 15:54:43 +0100

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: jeudi 29 octobre 2009 15:46
> Cc: roll
> Subject: Re: [Roll] [roll] #7: RPL bootstrap question: 
> neighbor cache andDIOs dependency
> 
> Hi:
> 
> 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?
> 
> Pascal
> 
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >roll issue tracker
> >Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor 
> cache and 
> >DIOs dependency
> >
> >--------------------------------+----------------------------
> ----------
> >--------------------------------+-----
> > 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?
> > topology:
> > A
> > |
> > B
> > 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
> > __________
> >
> >--

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Oct 2009 11:05:08 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    >> 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.
    >> 
    >> 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?

    Philip> I think it should be left to implementations. Every time we
    Philip> specify something, we increase the complexity of the
    Philip> protocol and limit flexibility in future uses. We should

Everytime you do not specify something, you leave things open to
interoperability issues.  If interoperability is not important to you,
then just implement a proprietary protocol.

As I understand the validation here, it is to assure a child that the
parent that it selects will in fact be able to hear it?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 29 Oct 2009 16:12:24 +0100

Hi Michael, 

> Behalf Of Michael Richardson
> Sent: jeudi 29 octobre 2009 16:05
> To: roll
>     >> In fact a stale entry is not sufficient. We need an 
> entry that is
>     >> reachable.
>     >> 
> Everytime you do not specify something, you leave things open 
> to interoperability issues.
>  If interoperability is not 
> important to you, then just implement a proprietary protocol.
> 
> As I understand the validation here, it is to assure a child 
> that the parent that it selects will in fact be able to hear it?
> 
Correct. It could be as simple as reachable/unreachable (ND can do this)
but will be more granular. 

Julien
> ] [email-masked] 
> http://www.sandelman.ottawa.on.ca/ |device driver[
>    Kyoto Plus: watch the video 
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.

---

From: Philip Levis <[email-masked]>
Date: Thu, 29 Oct 2009 08:28:23 -0700

> then just implement a proprietary protocol.

Of course -- that's what I meant by "correctness." I'm sorry if I was  
too terse to be clear. You want to specify behavior sufficiently that  
an implementation can behave correctly and interoperate. I'm just  
trying to give a little push-back on adding more complexity to the  
draft unless it's necessary.

In this case, the problem seems to stem from the fact that -04  
specifies that a node MUST NOT process a DIO. If we remove that  
restriction, doesn't it solve the problem? I guess I'm not sure why  
this requires any new mechanisms or specification. An implementation  
may wish to use NS/NA to check how lossy communication with a  
particular neighbor is, but the original issue raised was one of  
discovery, right?

Phil

---

From: [email-masked]
Date: Fri, 30 Oct 2009 13:39:42 -0500

HiPhil,

Leaving Neighbor Cache building and maintenance to the discretion of the 
implementer seems to open the door toward non-interoperable 
implementations on multi-vendor systems.  How one builds and maintains its 
neighbor cache seems to me to be a very important primitive operation of a 
mesh system. 

If all implementations must all support the full suite of messages and the 
implementation is just deciding which message it will use to build its 
cache, that's ok.  However, if implementer A picks message X to build its 
neighbor cache while implementer B picks message Y and elects not to 
support message X; that would not be a good thing.

The point of all this babble is to please keep in mind nonhomogeneous 
networks composed of many vendors' implementations.

Regards,

Jerry

Philip Levis <[email-masked]> 
Sent by: [email-masked]
10/29/2009 09:52 AM

To
Pascal Thubert (pthubert) <[email-masked]>
cc
roll <[email-masked]>
Subject
Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs 
dependency

Phil