Re: [Roll] [6lowpan] 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: 6lowpan-bounces@ietf.org 
> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Samita Chakrabarti
> Sent: Wednesday, May 12, 2010 02:52
> To: d.sturek@att.net; 'Pascal Thubert (pthubert)'; 'Erik 
> Nordmark'; zach.shelby@sensinode.com
> Cc: roll@ietf.org; 6lowpan@ietf.org
> 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
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> > 
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> 
> 
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>