Hello Cedric: I have the same questions. Furthermore, I'd wish to understand better:
*** whether the goal is limited to provide a best practice based on "established" ICT technologies There are other "established" technologies. For instance there is extensive networking experience in industrial networks, solving different problems under different constraints. Same goes in AMI/AMR networks, and to a lesser extent in Home, commercial and building automation. Some groups in the IETF have finally started to pay attention and build on that experience. Even if the resulting technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale is such that over a few years we have seen unprecedented amounts of implementations, interop and compliance tests (e.g. under IPSO and WCI). Also, if we map home use cases with the routing technologies that applied today, we see that at the moment the traditional IGPs do not play much role, at least from the home standpoint: - Internet to Home (Content consumption) is not a Home problem - Home to Internet (metering, P2P) is a default route - Home to Home (Content and Access sharing) is dominated by OLSR. - Inside Home (Content and Device sharing) is single subnet, solved reactively by ARP or ND. - Inside Home (Command & Control, Automation) meshing is proprietary though going 6LoWPAN and RPL. In any fashion, we can solve an additional problem of our own making that would require our beloved ICT IGPs to be injected in the Home network with always-on routers in each room or we can start producing best practices on how the above can to be done with the technologies that are already in place. Or both? *** whether we have an assumption of a plethora of power Year over year, we've seen the simplest devices migrate from a totally-switched-off mode to some more and more power greedy sleeping and always-on modes. Always-on displays and LEDs appears fancy to the consumer but are of consequence on the family budget and at the scale of a city, result in measurable pollution. And we've been connecting more and more devices to the home power distribution, devices that would not exist 10-20 years ago. We know how power-greedy traditional ICT technologies are; people do not want a new heating system that they cannot even stop in summer. My take is that whatever this group produces has to be justified in terms of power budget as it has to be justified in other terms like usability and security. *** if HOMENET is targeting home gateways and large home cinema gear only, and whether we have an assumption of cat 5/6 cabling This case is probably the low hanging fruit and that there is an immediate need to solve a number of problems there. If that's what the group is pursuing for the time being, well, that's fine as long as it's very clear to everybody. But the rest of the world is low power and lossy. Apart from certain ecological niches (that's datacenter mostly) about all Internet-connected devices have evolved the wireless trait, even if the most traditional devices can still use wires. The new trait has lowered dramatically the cost and complexity of accessing the Internet, which in turn allowed the introduction of new species of internet-connected devices that now thrive under the name of Things. At some point we'll have to address that too. I do not know how that converts into cents at the current rate... Pascal -----Original Message----- From: C Chauvenet [mailto:[email protected]] Sent: jeudi 29 septembre 2011 17:23 To: Acee Lindem; Fred Baker (fred) Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; [email protected]; [email protected] Subject: RE: [homenet] Question for you Hi, " I don't think my wife would want a lossy network in our house ;^)" : Nobody wants a lossy network, but the technology you are using may create lossy links... I may have miss something in the Homenet scope. In the scope of Homenet, is every device in the house runing over a *robust* link (Bit Error Rate below 1 % at the PHY level) ? Furthermore do these devices could have some high Power/Computation/Size/Cost constraints ? I fail to see the kind of technologies and devices that are targeting. Thanks for the clarification. Cédric . -----Message d'origine----- De : Acee Lindem [mailto:[email protected]] Envoyé : jeudi 29 septembre 2011 16:44 À : Fred Baker Cc : Mark Townsley; C Chauvenet; Pascal Thubert (pthubert); MANET IETF; [email protected]; [email protected] Objet : Re: [homenet] Question for you I'm in complete agreement with Fred. The areas where the existing link-state protocols may need to be extended are auto-configuration and, potentially, inter-area policies. I don't think my wife would want a lossy network in our house ;^) Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote: > > On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote: > >> Since you asked, *I* think that a homenet has functional overlap (what I >> called "at least a smaller and slightly different subset" in my email) in >> terms of requirements to LLNs. At first blush, it looks like RPL has lots of >> functionality - perhaps more than we really need for homenet, and by your >> own admission more than you need for LLN's - but will hold reservation on >> what I think best fits the bill until we see Fred's analysis, hear from >> others, etc. > > My two yen, which may be all it's worth... > > If I were a Linksys/D-Link/NetGear/* product manager asking about what > protocols to put in, I wouldn't be asking about what still exists in Internet > Drafts and is thought by the engineers designing it to be better than sliced > bread, but about what was inexpensive to implement, likely to be close to > bug-free, and definitively accomplished the goal. I note that most routers > for the IPv4 residential routing marketplace implement RIPv2; I know of one > that implements no routing protocol, one that implements RIPv2 and RIPv1 (!), > and one that implements RIPv2 and OSPF (don't ask which they are, I don't > remember). This is from a google search of residential routers a few months > ago and covered perhaps 20 products from half as many vendors. So my first > inclination is to say that for a residential IPv6 network, RIPng is probably > an image match for those vendors. > > I have a personal bias in the direction of OSPF or IS-IS; I think that once > the code is debugged, SPF-based protocols are more stable (no > count-to-infinity), given a reasonable set of defaults generate far more > stable networks, and definitively know when there is more than one router on > a LAN, which can be important in subnet distribution. > > My first choice would NOT be something that isn't proven in the field in > multiple interoperable implementations. > > As a person thinking about making a recommendation, I'd suggest that folks > read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why > that level of interoperability isn't mandatory. > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
