On Oct 1, 2011, at 4:38 PM, Don Sturek wrote: > 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 am constantly amazed at the plethora of consumer-oriented standards groups/forums/logos/associations/etc... We've had decent uptake of RFC 6204 and other products of v6ops targeting the consumer space. I hope that continues. Of course, anyone with specific ties into any of the organizations that might want to use our work, please feel free to help make that happen. - Mark > > 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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
