Carsten, We have a strong disagreement on the rationale for the draft. Do you REALLY think splitting the draft in two drafts solves anything?
Julien > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Carsten Bormann > Sent: jeudi 12 novembre 2009 03:50 > To: 6lowpan > Subject: [6lowpan] Way forward for 6LoWPAN-ND, consensus call > > 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
