100% agreeing with you Don. 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 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 > > > _______________________________________________ > manet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/manet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
