>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.
[Pascal] Hi Erik: Thanks a bunch for helping here. The main requirement that the draft is addressing is scaling the LowPAN by merging multiple PANs over a backbone. This requirement comes from the industrial space but the topology appears in multiple other use cases, in building and home automation for instance. One specific aspect of this requirement is that a node can move from a LoWPAN to another LoWPAN attached to the same backbone link and keep its (set of) address(es). In particular it should be possible to own a link local address, connect to any LoWPAN or to the backbone with that address, and ping any other link local address connected to any LoWPAN or to the backbone with that address. This is where the proxy ND comes from. Very close to RFC 3775 (MIPv6) using the backbone link similarly to a home link, but a different flavor of registration because there is no CoA and no need for tunnel. ND on the backbone enables the cohabitation of MIP and BbR protocols so that a LoWPAN node can move locally or far far away. Once you have a registry you can use it for the purpose of DAD and NS lookup. Thus the discussion on proactive white board. This does not prevent the use of reactive white boarding through the registry or any other Backbone router so forwarding could be maintained upon registry failure if we make the necessary efforts in the protocol. As you see, the proxy ND function is the core of the draft, and the white board is a benefit. Yes, we do need to handle RAs efficiently and we do need a redundancy technique for the BbRs. >> 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. > [Pascal] I agree (almost) all the way through. I'd add that: - WRT SPoF: Distributing the white board is similar to distributing the HAs in MIP. They collectively own the table of all the registered addresses on the "home" backbone link. If one dies, there is an interruption of service for the nodes it serves till they register somewhere else. I've been trying to introduce a secondary registration to enable hot stand by, bicasting and uninterrupted service but I'm not sure it's a such a good idea. Maybe it's better to leave the redundancy up to the vendors as we do with MIP. - WRT DHCP relevancy: I talked to DHCP specialists in cisco and they felt that DHCP could do stateful registrations and lookups nicely using RFC 5007 for the lookup. I plan to publish a draft 01 with text from Benoit that proposes just that as a base for the discussion. Certainly I'm completely open to a new protocol if your approach prevails within the group. I just found that DHCP was way closer than MIP to the registration solution that we need and a good starting point. DHCP also enables the BbR to compute a SeND CGA address on behalf of the mote that might not want to spend half its battery in the process. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
