Hi Anders; The current ND draft has a white board, though it calls it a neighbor cache. Sometimes, renaming things is good. In this instance, I do not know. Clearly, standard neighbor cache entries must not be confused with the ones gleaned for the registration process, because only the latter can be fed into the backbone mechanism, be it route over or mesh under.
The White Board conceptually differs from the traditional Neighbor Cache: - The WB is a table as opposed to a cache. A neighbor cache entry can stay STALE for a very long time after the node is gone. A neighbor cache entry can be flushed to make room anytime. So a neighbor cache entry does not represent the node accurately enough to be redistributed in a routing protocol or proxied over a backbone. - It is fed proactively using a registration as opposed to reactively to traffic. The registration and timely reregistration guarantees the presence of the node proactively. NUD is reactive, depends on traffic. It is nice to have but not mandatory as long as you have a registration. In a very constrained node, I'm not sure you really want to implement the additional 10 pages of specs that this represents. You should tell us. The original backbone router draft has the exact same white board as the current ND-09, and uses ND proxy over a backbone to allow for multiple routers in the subnet. For more complex topologies that include route over and complex meshes with no backbone, the WG doc evolved the concept to add a centralized registrar for the purpose of DAD and such. I got the message loud and clear that the group does not want that latter piece in the base spec: - which works if the spec is specific in which topologies it supports and which topologies it does not. That was clear in ND 08 section 2.2 but is gone from 09. - which is good to speed up adoption of the registration, which is a great progress for ND at large . Cheers, Pascal > -----Original Message----- > From: Anders Brandt [mailto:[email protected]] > Sent: Wednesday, May 12, 2010 10:16 AM > To: Samita Chakrabarti; Pascal Thubert (pthubert) > Cc: [email protected]; [email protected] > Subject: RE: [6lowpan] [Roll] how does a node get an IP address > > > > The white-boarding , backbone and extended lowpans etc. are not part > > of basic necessity in most applications in 6LoWPAN. > > The best way to handle them is to write a separate draft on them and > > move forward. > > +1 > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Samita Chakrabarti > > Sent: Wednesday, May 12, 2010 02:52 > > To: [email protected]; 'Pascal Thubert (pthubert)'; 'Erik Nordmark'; > > [email protected] > > Cc: [email protected]; [email protected] > > Subject: Re: [6lowpan] [Roll] how does a node get an IP address > > > > Hi Pascal, > > > > > > > > The expectation of the 6LoWPAN WG when we elected the > > backbone router > > draft > > > over Samita's draft was to radically eliminate multicast. > > The backbone > > [SC>] > > For the fact check and remembering the 6lowpan-ipv6-nd evolution: > > > > draft-chakrabarti-6lowpan-ipv6-nd-00 was published in Feb, > > 2006 co-authored by Erik and I. This draft introduced the concept > > optimization of IPv6 multicast signaling into unicast ones for IEEE > > 802.15.4 in mesh-under configuration. > > At Dublin, 2008, authors/chairs decided to merge v05 of this draft, > > draft-hui-6lowpan-nd, > > draft-thubert-backbone-router,draft-nordmark-6lowpan-reg-00 > > to add route-over and registration mechanism and produced > > draft-shelby-6lowpan-nd-* which was then adopted as wg draft. > > > > So no draft was particularly chosen over another draft. IMHO, that was > > the beginning of all-purpose (aka. Kitchen sink) 6lowpan-ND protocol > > which has had trouble in the wg as folks needed to implement > > unnecessary code for corner cases and unwanted usage. 6lowpan working > > group decided to split nd-07 to have a base draft. > > > > Nd-simple in Anaheim was an attempt to fix that problem. Wg welcomed > > the draft and ND-09 was created on the base idea of ND-simple and part > > of ND-08. > > > > > > ND-09 is not broken as claimed below. ND-09 is developed to address > > basic auto-configuration, minimal multicast and neighbor discovery > > with reliability while staying as close to RFC 4861 as possible for > > minimal code change. > > The white-boarding , backbone and extended lowpans etc. are not part > > of basic necessity in most applications in 6LoWPAN. > > The best way to handle them is to write a separate draft on them and > > move forward. > > > > Regards, > > -Samita > > > > > router draft takes a number of measures to get there. The > > most obvious > > > is the use of NS/NA as a registration mechanism, and I'm very happy > > > that this core idea is still present in the current draft, > > though the > > > original > > author > > > somewhat disappeared by some black magic that's quite > > unusual to the IETF. > > > > > > I claim that the current proposed solution still does not > > work on mesh > > under > > > because it does not fulfill that expectation. For instance, > > I do not > > > see > > how > > > multicast is avoided in mesh under when there are more than > > one router > > > in the subnet, without involving routing protocols, which would be > > route-over. > > > From the backbone router draft till ND-07, we answered that > > question > > > at > > the > > > ND level using a whiteboard registrar as a backend to the > > registration. > > > Please do not confuse that question with the use of a > > backbone where > > > admittedly, either an SGP or ND proxy could work. > > > > > > I'll add that it is pretty hard to complete the > > registration mechanism > > > before we know what the registration bask end is. You demonstrated > > > that > > > ND-08 could not be used to front end DHCP. I demonstrated that it > > > cannot > > be > > > used to front end RPL either. And it's broken for mesh > > under because > > > it is incomplete. I cannot see how the whole picture works > > from either > > > this > > draft > > > alone, or any combination of drafts on the works today. > > > > > > For all I know ND 09 is broken while ND 07 was not. My suggestion to > > resolve > > > the issues I see: > > > > > > - put the whiteboard interaction back in the base spec so > > the spec is > > > standing on its own 2 feet. > > > - let the route over problem propagation to RPL (that's the PIO/RIO > > > propagation) > > > - make a separate spec for the ND proxy piece. We have already text > > > from Zach, Carsten and I that can be used > > > > > > Cheers, > > > > > > Pascal > > > _______________________________________________ > > > Roll mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > > Roll mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
