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

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

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: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of roll issue tracker
>Sent: jeudi 29 octobre 2009 13:02
>To: wintert at acm.org; jpv at cisco.com
>Cc: roll at ietf.org
>Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency
>
>#7: RPL bootstrap question: neighbor cache and DIOs dependency
>--------------------------------+-------------------------------------------
> Reporter:  jpv at …               |       Owner:  wintert at …
>     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/>
>
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll