Re: [6lowpan] [Roll] how does a node get an IP address

["Samita Chakrabarti" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll