 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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 >> |
Attachment:
oledata.mso
Description: oledata.mso
