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 > > > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
