At 6/20/2010 04:10 PM, Clint Ricker wrote: >Inline >... >My opinion is that the major work that is done on routing / network >hardware by the companies with deep pockets is also done for companies >with deep pockets. So, what you get is stuff designed to solve >"national" problems, not "small town needs Internet", and then, if >needed, is just scaled down--with varying degrees of success.
You're giving them too much credit. The IETF/Cisco world is going down ratholes, spinning wheels, getting nowhere. LISP? Gimme a break... it didn't even get the IETF blessing but Cisco's pushing it. IP is dead and they just don't know it. It still carries traffic, of course, but the zombie's corpse is starting to smell. And you're absolutely right that the big players don't care about little guys like WISPs. But you guys don't buy CSRs and 7600s. >It's >not just a matter of wireless running 10 years behind >wireline--wireless really doesn't have anyone with deep pockets >addressing these sorts of issues. Large-scale mesh from hard-core >networking companies doesn't exist: the major service providers that >do wireless pretty much all universally backhaul over wireline and >avoid these issues. Right. They service the large, easy, well-heeled markets. They leave the tough, but smaller-volume, jobs to others. >Unless the trajectory changes, I'd say that these >issues aren't on a path to ever being solved, let alone inside of 10 >years ;). So, it's probably a matter of roll your own or push back on >the wireless vendors (Ubiquiti, Mikrotek), although I'm sure that they >run on ridiculously thin margins and would need enough of a coalition >to convince them that they could see any ROI by bringing this to >maturity; it's also complicated by the fact that a lot of the vendors >core expertise is RF, not IP. To be sure, one of the advantages of the MT Routerboards is that they'll run third-party code. And Vyatta, etc., but not the big guys. There is some startup activity I'm involved in that may address some of these issues. Hence sticking to layer 2 for now, since IP is part of the problem, not the solution. >For what it's worth Fred, I somewhat disagreed with your assertion of >"IP is just another layer two protocol" that made in a previous post. >In the end, the power of IP is in its hierarchical nature which lets >you summarize, which is critical to the amount of processing that it >takes to process network decisions on a network of non-trivial size. IP is a big bucket of fail, which we are so used to using that we don't even look. Think naked emperor. It doesn't summarize well. This is one of the things that I did in RSPF, btw -- it did "level 1 routing", meaning SPF routing within the "subnet", which became in RSPF a "node group" since "subnet" implied the IETF norms. Not my idea, btw -- I just adapted it from DECnet! And RSPF addressed nodes, not interfaces. Boy did that get the IP Fundamentalists upset. They worship IP's bugs without knowing why they're there. Yes, I do know the origin of interface addressing, and why the IP address is inside FTP. My article "Moving Beyond TCP/IP" (see my web site or the Pouzin Society's) explains it. Sort of like Google's "spec" for VP8, which in parts just gives reference Unix code, which has known old bugs that were in VP3. >That said, as long as you route, not bridge customers onto your mesh >network, then the mesh network itself will remain small enough that >layer two is perfectly reasonable. If you do HMWPplus, then I'd >assume that you'd at some point need to scale by splitting mesh into >multiple meshes; OLSRD is probably going to handle a large number of >nodes more gracefully. However, as has been pointed out, having >link-quality information as part of the routing decision is critical >and, in the end, it is a lot more elegant to put that on layer two >than on layer 3 like OLSRD does. The idea here is that the local mesh (a rural county-scale service area) will be one domain; other areas will be separate meshes, with separate injection points. So it's dozens, but not hundreds, of nodes. And thus it will look fully connected at the IP layer, which IP wants, for the IP traffic. >You nailed a fundamental problem which is the lack of any sort of >carrier / metro Ethernet style setup. For most traditional wireline >vendors in this space, there are two basic components to making this >work--classes of services / QOS (router side) and then the >provisioning system which actually knows what's provisioned and what >the remaining capacity on various spans is. The missing piece in >this puzzle for wireless is the provisioning system, although the >algorithms for doing route/bandwidth capacity calculations in a >many-to-many mesh architecture are non-trivial to develop, to say the >least. If you limited yourself to a ring-architecture, it would be >much more doable. Well, rings per se are not flexible enough; a more complex topology (ring plus extra links) is more resilient. But it does make provisioning tricky. I don't know how much help The Dude will be for HWPMplus, but it's one of those things I hope are handled in the long term by some development that's not yet done, but sort of planned. Which leads back to my original question -- how much field experience is there with HWMPplus? I'd be happy to look at Wili's stuff too, but their web site doesn't seem to have a lot of details. And I'm not sure what pole-mountable multi-radio processors it can run on. -- Fred Goldstein k1io fgoldstein "at" ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701 -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
