Pascal Thubert (pthubert) wrote:
> The focus of this doc is to illustrate the white board approach and the
> use of proxy ND over the backbone to scale up the LoWPAN.
Pascal,
can you explain how using proxy ND makes things more efficient and/or
more robust? Mapping the IPv6-all routers multicast address to a
functional/anycast Lowpan address combined with VRRP seems to be
sufficient to handle finding the routers including failover. Thus to me
ND proxy seems like nothing but a distraction here.
> If the group
> agrees that this is the direction then we can dig further and merging
> with draft-chakrabarti would be an excellent idea. It is clear to me
> that my Draft 00 falls short in a number of occasions which were not the
> focus at the time.
>
> - registration mechanism. DHCP formats make more sense than NS/NA that I
> used. I asked Benoit Lourdelet to join as a coauthor to rework that. I
> also got comments that a totally new format could be welcome, along the
> lines of RFC 3775 Binding Update (though the BU as it stands is not fit
> for the job) but for the time being I'd rather stick to DHCPv6 and see
> the feedback from the group.
But you'd also need to handle a distributed whiteboard so you whiteboard
doesn't become a SPoF. And if you use (unicast) NS as the way to do
lookups from the whiteboard, then there is a strong reason to co-locate
the whiteboard with the entity handling the NS; it might make sense to
have a common protocol for registrations and lookups. Neither current ND
nor current DHCP is a good fit for a combined registration and lookup
protocol. Furthermore, if we want to add key distribution to the fix,
then the requirements on the registration and lookup protocol (or
protocols) changes.
> - NS lookup. There can be 2 ways, proactive and reactive. My draft
> reflects proactive using unicast NS/NA with the white board (and it will
> be based on DHCP RFC 5007 in the next release). It's good because it
> woorks for any type of address, link local, unique local and global.
> draft-chakrabarti proposes a reactive version where the backbone router
> does the lookup for you with an implicit request that comes with the
> packet to be forwarded. This saves the NS/NA flow but causes all packets
> to flow via the BbR.
Not necessarily. The router can unicast a redirect which tells host A
which L2 address to use to reach host B directly.
Whether or not to do that might depend on the stability of the L2
topology. If it is more stable to always go to and from the router than
that might make more sense than finding a direct path that might be less
stable.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
