Re: [6lowpan] "Advertize on Behalf" flag in ARO

Hi Erik:

RPL does not have an assumption on this ND operation in particular nor
on 4861. But then, the interworking of ND and RPL is left to further
work.
I hope this work happens somewhere someday. In particular, RPL is
prepared to redistribute external routes and that could include host
routes learnt from registration.
But then, RPL, like the backbone router draft operation, needs the TID
that is now gone from ND, to recognize the update from the stale when
the LBR states are distributed and clean up.

Cheers;

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
> Behalf Of Erik Nordmark
> Sent: Tuesday, March 29, 2011 1:14 PM
> To: Mukul Goyal
> Cc: 6lowpan
> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO
> 
> On 3/3/11 5:07 AM, Mukul Goyal wrote:
> > Hi all
> >
> > Recently Anders pointed out the need for the "Advertize on Behalf"
> > flag in an Address Registration Option (ARO).
> >
> > We would not have needed this flag if only a host could send a
unicast
> > NS containing an ARO. However, the way I read Section 6.5.5 in
nd-15,
> > a 6lowpan router (6LR) can also send a unicast NS to another 6lowpan
> > router. This means that a registered neighbor cache entry (NCE) in a
> > 6LR could refer to either a host or another 6LR. So, how does a 6LR
> > know that a registered NCE belongs to an attached host and it should
> > advertize reachability to this host in the routing protocol, such as
> > RPL, it is running?
> >
> > The proposed flag will solve this problem. A host would set
"Advertize
> > on behalf" flag when it sends an ARO inside a unicast NS message,
> > whereas a 6LR wont.
> >
> > I was wondering if ND authors could comment on this.
> 
> I didn't see anybody else comment, so let me try.
> 
> I don't know what assumptions RPL makes in particular, but if we are
talking
> about a general case of a routing protocol, I don't see why there
would be a
> need to tell a difference between a host sending an ARO and a router
(which
> might be initializing and haven't yet enabled routing and forwarding)
sending
> an ARO.
> 
> In both cases I'd assume that the unicast address that is registered
is
> something that should be reachable, hence it makes sense advertising
> reachability to that address.
> 
> If this isn't the case, then a routing protocol would typically find
out about its
> neighboring routers IP addresses, and from that it can decide to treat
those
> IP addresses differently than the addresses assigned to hosts.
> 
>     Erik
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan