Good Afternoon, Zach: I still think that splitting the registration mechanism and the diffusion mechanism in 2 drafts would help speed up the registration piece. Which is a corner stone for the whole work, not only at 6LoWPAN.
I have a number of other issues on the registration piece. To start with: - the sequence number that was present in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01#sect ion-4.1 is gone from the http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-4.1 . MIPv6 showed us that this sequence is a useful tool for resynchronization and to defeat replay attacks. The sequence number will also play a role in the movement resolution over the backbone. I suggest you place it back. - http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-8.2 discusses the use of the white board for DAD in more complex topologies. But the group does not seem to want to see it in this spec. So is it in or out of scope? If in scope (which I definitely support), then there's no point restricting it to route over. A mesh under without a backbone must have one LBR and a number of LR that will do the exact same operation as described in that section. And I'll be happy that the spec stands on its own 2 feet. We'll not that a backbone is by definition a link between LBRs, and out of scope. Would you agree? Thanks for all the sweat! Pascal > -----Original Message----- > From: Zach Shelby [mailto:[email protected]] > Sent: Wednesday, May 12, 2010 1:50 PM > To: Pascal Thubert (pthubert) > Cc: 6lowpan > Subject: Re: [6lowpan] [Roll] how does a node get an IP address > > Hi Pascal, > > Great to see we are converging here. So I think the best next actions would > be the following: > > 1. Write an I-D examining the different topologies for connecting LoWPANs > to other networks, and the issues/solutions for dealing with that. I think it > would be useful to explore both how it works when a routing protocol is run > over the backbone, as well as proxy ND. This should reference and use nd-09 > as-is so we see if anything is broken or needs better explaining. > > 2. We should do a better job of defining the assumptions for the topologies > this works for (and doesn't), in particular the optional DAD to the 6LBR. We > have a pretty clear picture in our heads, but it could be more concrete the > draft. I propose making a ticket for that and fixing it for nd-10. > > Now, it would be great to go back to reviewing nd-09 for technical > correctness and nits, which would be a big help. So far I have one ticket from > Pascal plus comments from Robert Cragie, so I guess everyone else is happy? > > Thanks, > Zach > > On May 12, 2010, at 14:31 , Pascal Thubert (pthubert) wrote: > > > 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 . > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
