Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor

["Julien Abeille (jabeille)" <jabeille at cisco.com>]

Hi Jonathan,

NUD is probably not appropriate for RPL neighboring concept. So we just
should use other means, which could by the way make use of NUD, plus
other things. Reachability as far as ND is concerned can also be updated
by external protocols (e.g. a reliable transport, this is from 4861)

Julien

> -----Original Message-----
> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On 
> Behalf Of Jonathan Hui
> Sent: vendredi 20 novembre 2009 20:48
> To: Pascal Thubert (pthubert)
> Cc: roll at ietf.org
> Subject: Re: [Roll] [roll] #3: Need Clarification on 
> Candidate Neighbor
> 
> 
> Hi Pascal,
> 
> On Nov 20, 2009, at 11:24 AM, Pascal Thubert (pthubert) wrote:
> 
> >> I think the criteria for choosing as well as the maintenance of 
> >> neighbors and candidate neighbors should be left out of 
> scope of the 
> >> core RPL specification.  While we could say that candidate 
> neighbors 
> >> are based on the set of REACHABLE neighbors, I don't think that 
> >> really clarifies much since it doesn't define what a REACHABLE 
> >> neighbor is and/or implies that it is defined by RFC 4861 
> which may 
> >> not be the definition we want.
> >
> > REACHABLE is a good starting point as long as we base our neighbor 
> > loss detection on NUD.
> > At least it is consistent. But we do want to be able to use other 
> > neighboring mechanisms, in that case the goal would be to have the 
> > equivalent of REACHABLE with that mechanism as opposed to stick to 
> > 4861's REACHABLE, of course.
> 
> My point is that 4861 NUD is most likely not what we want to 
> maintain the neighbor set.  Just because a single RFC 4861 
> NUD fails doesn't mean we should remove the node as a 
> candidate neighbor, and thus, candidate parent.  At the very 
> least, we will need to better define what NUD really means in 
> this space.
> 
> >> That being said, it might be appropriate to provide some 
> suggestions 
> >> or implementation guidelines within the appendix to identify 
> >> important parameters to consider.  For example, some 
> versions of the 
> >> draft had words saying that both the link quality metric *and* 
> >> confidence in the link quality metric should be considered when 
> >> choosing candidate neighbors.  Confidence is important since link 
> >> qualities are statistical values based on discrete samples 
> over time.
> >
> > We started discussing a companion Informational spec with 
> > recommendation such as FSM.
> > We figure a number of things today that might be wrong. We made the 
> > draft pretty Elastic to enable a large capability of tuning and 
> > adaptations to the needs.
> >
> > The risk of being too elastic and not enough specific being 
> a lack of 
> > interoperability and the possibility to make an implementation that 
> > plain does not work.
> > We are trying
> > to avoid that of course and I expect that the next rounds of review 
> > like IESG will be sensitive to that aspect.
> 
> 
> A large open hole I see today (which I have raised before) is 
> that we lack a standard mechanism to estimate link qualities 
> to neighboring nodes.  I think it is needed and the 
> discussion hasn't even started yet.  But this mechanism 
> should not be specified in the core RPL spec.
> 
> --
> Jonathan Hui
> 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>