Hi Carsten: I think this is a brilliant proposal, and I'm strongly in favor. It makes things a lot clearer to the users, and distributes the roles better.
I understand that the overall content that we agreed to standardize in Dublin and as currently expressed in ND 07 will not change during the reorganization. I'd support additional drafts that explain how this gets mapped onto a DHCP-based infrastructure. Also how this gets mapped onto a TRILL or a routing based infra. Cheers, Pascal >-----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
