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

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, May 12, 2010 10:16 AM
> To: Samita Chakrabarti; Pascal Thubert (pthubert)
> Cc: [e-mail]; [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Samita Chakrabarti
> > Sent: Wednesday, May 12, 2010 02:52
> > To: [e-mail]; 'Pascal Thubert (pthubert)'; 'Erik Nordmark';
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> >
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6lowpan
> >