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); wintert at acm.org;
jpv at cisco.com
>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: roll-bounces at ietf.org
[mailto:roll-bounces at ietf.org] On
>> Behalf Of Pascal Thubert
(pthubert)
>> Sent: jeudi 29 octobre 2009
15:46
>> To: wintert at acm.org;
jpv at cisco.com
>> 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?
>>
>> 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@…
| 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/>
>> >
>>
>_______________________________________________
>> >Roll mailing list
>> >Roll at ietf.org
>>
>https://www.ietf.org/mailman/listinfo/roll
>>
_______________________________________________
>> Roll mailing list
>> Roll at ietf.org
>>
https://www.ietf.org/mailman/listinfo/roll
>>
