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
