> 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
