Hi Jonathan, I fully agree with you. Thanks for summarizing the points so well! Best, Mathilde
-----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
