Hi Jonathan, I could not have said it better.
Best, Julien > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jonathan Hui > Sent: mercredi 18 novembre 2009 20:53 > To: Carsten Bormann > Cc: 6lowpan > Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call > > > Splitting off the host-router portion into its own WG > document is a good thing to do. > > The question for me is what to do with the other half - > specifically the DAD portion. > > First, I do believe that having a completely separate > mechanism solely for detecting duplicate addresses is > unnecessary overhead in real production deployments. In some > cases, applications will accept the extremely low probability > that a duplicate address will exist in the network. In other > cases, networks will have other mechanisms in place that can > (and will) be used to assign unique identifiers (e.g. through > commissioning, strong security associations, DHCPv6, etc.) > within the proper scope which may be used to form unique IPv6 > addresses. If the identifiers are *assigned* in such a way > to be unique, the added benefit of *detecting* failures in > the assignment mechanism is marginal. For these reasons, I > think there is consensus in this working group that DAD > should be optional at best. > > Second, I'm not yet comfortable with the whiteboard > mechanism, as specified in nd-07, becoming a WG document. > There is consensus in this WG that the whiteboard mechanism > does not work in all scenarios and should be optional at > best. Given that, I think this WG needs to think more about > the broader effects of specifying a particular way to do DAD > while making it optional. Having an option (or multiple > options) could cause interoperability issues and confusion > down the line. > > Third, I'm not sure, frankly, that the whiteboard mechanism > is something of broad interest to members of the WG. Looking > through the mailing lists, I haven't found much (any?) > support for the whiteboard outside of the authors. In fact, > I have found more comments of concern. I also don't think > we've even polled the WG about whether the whiteboard > mechanism should be taken up in a WG document. > > -- > Jonathan Hui > > > On Nov 11, 2009, at 6:50 PM, Carsten Bormann wrote: > > > After the 6LoWPAN meeting, there have been some hallway > conversations > > on the need for DAD vs. the expense of DAD. Clearly, the > 4861 way of > > involving potentially all hosts in that process is not > applicable in > > most interesting 6LoWPAN configurations. More generally speaking, > > whatever we do here, it should not involve the hosts. > > > > The remaining discussions essentially were about how the "fabric" > > (please excuse me using that term, which I'll use for the > set of nodes > > that are not just hosts) might achieve proper address allocation > > and/or validation (DAD). The right answer seems to depend on the > > specific areas of application, network configurations, and > > characteristics of that fabric. For some cases, the centralized > > approach with one or more edge routers is the right way to do this; > > for others, the additional messages needed for a > distributed approach > > may be justified by the increased flexibility possible with that. > > > > But the important point is that whatever the fabric does here, the > > hosts do not care. They want to register their addresses with the > > fabric (not just for allocation/DAD, but foremost to get > routed to), > > and couldn't care less how that oracle comes up with "yes" > or "no", or > > how it derives any allocations requested. 6LoWPAN-ND differs from > > 4861 in that the host-router interface is fully > node-initiated, which > > is the only appropriate way to do this with potentially sleeping > > nodes. > > > > Keeping that host-router interface simple and interoperable is the > > most important concern: There will be billions of these > 6LoWPAN host > > nodes, and their interface to the network should be based > on a stable > > specification and isolated from the specifics of the intra-fabric > > algorithms. > > > > So the (in hindsight very obvious) way forward is: > > -- split off the host-router interface part of 6LoWPAN-ND into one > > document of its own. This document will contain the router > > discovery and node registration protocol components of > > draft-ietf-6lowpan-nd-07.txt (NR/NC with code != 1, the RA > > parameters/options). Based on the input from 6man, the > ADs and the > > IAB, this will also now make use of the terminology in > > draft-ietf-autoconf-adhoc-addr-model-00.txt that is quickly > > becoming the new consensus for this kind of network. This part of > > the split is the document that will update RFC 4944 in the way > > envisioned by RFC 4861 section 1. > > -- rename the rest of draft-ietf-6lowpan-nd-07.txt, i.e. the > > fabric-side part (relayed NR/NC, Edge Router operation, OIIO) into > > "6LoWPAN Edge Router backend", as a draft separate from the > > above common router discovery/node registration protocol. > > -- go ahead and define other backends for those cases that merit it. > > > > Three types of backends beyond the existing Edge-Router > based backend > > have been mulled over in various hallways so far: > > > > -- a multicast-based backend where all 6LoWPAN routers announce and > > defend their client hosts' addresses between themselves (without > > involving the hosts). A degenerate case is the simple star > > network, where the single hub node can do all this all by itself. > > -- a routing-system based backend, where the management of addresses > > is integrated into the routing protocol (e.g., in RPL by adding > > information to DAO type messages and processing rules). > > -- a DHCP-based backend (which could use either of the > above for DAD). > > > > This is not saying that we want to actually standardize all > three of > > these backends. But we should at least do proof-of-concept > ("napkin") > > versions of all three to ensure the host-router interface > works well > > with either of them. > > > > Many thanks to Geoff Mulligan and Thomas Clausen for their help in > > identifying this approach, and to Ralph Droms, Jari Arkko, and Dave > > Thaler for supplying the missing links. > > > > Geoff Mulligan, who is acting as the chair for this > document (because > > I'm a co-author), has requested me to announce this and ask the > > working group for consensus on this approach. Please reply by > > > > November 18, 24:00 UTC > > > > with your concerns, comments, or just plain support that this is > > indeed the way forward. > > > > Gruesse, Carsten > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
