To add one more point to Fred's note: I think it is important to get a commercial group like Wi-Fi to participate in Homenet, adopt some or all of the drafts/RFCs then sponsor interoperability testing.
I agree with Fred that having individual CPE vendors cobbling together RFCs will not yield a bullet proof home networking solution and that will kill the work in Homenet if customer support is needed. Don On 9/30/11 11:26 AM, "Fred Baker" <[email protected]> wrote: >As I understand it, we have made the case that there is a place for >routing in at least some homes and in SOHO networks, and we should say >what protocols manufacturers should consider implementing in equipment >they sell. Two significant parts of the issue there, as you know, are >operational expense and cost of goods. Margins in residential routers are >thin enough that manufacturers (one of which you know from the inside) >essentially lose their entire profit margin if they pick up the phone for >a trouble call, and in addition the memory to store the code and data, >and the code itself, cost money on a COGS basis. Manufacturers want to be >able to buy trouble-free code for a predictable price, put it in the >system, and forget the system. > >Which argues for proven specifications and implementations that have been >field proven to interoperate when used in anger. > >To my knowledge, this doesn't automatically imply "give me that old time >religion". It does call for proven (and preferably documented) >interoperability between numerous independent complete implementations, >or proven interoperability of a common profile of a protocol, an exercise >I have suggested to some proponents of your favorite protocol is good for >the soul. RFC 1246 comes to mind. > >By the way, let me clarify a point that you may be confused on. There are >detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I >think IPv4/IS-IS. To my knowledge, there has been interoperability >testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are >in use in production networks, but the test documentation is a trifle >thin. So I'm not asking of your favorite protocol or a dozen others that >one could discuss something I think should let slide for the traditional >ones. I am simply asking that the claims for the protocols be backed with >interoperability testing, RFCs, Security Directorate reviews, and so on. > >On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote: > >> 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 >> >> >> > >_______________________________________________ >manet mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/manet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
