You're taking the term too literally. Yeah, the protocols are in software, but the operator doesn't get to change them. There's a lot that you're not allowed to do with your network. SDN aims to free that up -- to unlock the network, in a sense.
About standards -- OpenFlow is trying hard to not be one, actually. Yes, there'll be a base set of specifications and definitions. Call that a standard if you want. But beyond that, the Open Networking Foundation wants to keep things in a more open-source mode, if I understand correctly. (Actually, maybe I should write that up as a separate story.)
What they're trying to avoid is the standards-body process of honing every last detail down to a consensus. They want to be more like the mobile apps world: Here's the platform, go do whatever you want with it. You might think there are problems with that (the multiple-vendor problem that you mention, for instance) -- and that's fine. I really don't know if this approach will pay off or not.
To your final paragraph -- good points. It will be interesting to see how viable a third-party software industry would be in SDN. Separately, I think a lot of people are hoping that those hardware optimizations go away -- i.e., that something more commodity-looking starts to replace the switches and routers of today, so that your reference to the PC model would become reality. That would be a long way off, of course.
To take Larry Ellison's rant on Cloud computing (Youtube it), what do you mean software defined networking: All the networking protocols run in software. Hardware is used only to optimise certain functionality (either fast data path routing, session actions, lookup, some security). Everything is written in software. Infact software is what makes the exisiting networking products useful.
Having got that out, I think moving away from standards would be good. But, it would only work for green field, one vendor solutions. OpenFlow is still a standard with specifications. Whenever you need to deal with multiple vendors you will always need standardization (even though I am not in favor of the current standards process, which is more political rather than working towards a solution). And in networking you will always deal with multiple vendors (It's not just an app on the user's phone).
Concept of a programmable network is good. Currently that programming is static using CLI/SNMP etc. Making the system dynamically programmable will definitely improve the flexibility. Instead of vendor's software configuring all the hardware components you could have 3rd party software running on a different server/appliance manipulating the hardware components (IO/fabric/ASIC/backplane). But there is always performance hit for these solutions. Unless all the network equipments run on the off the shelf products with well-known/public internal details (like a PC), a 3rd party writing a software on a different hardware will always be inefficient. There are so many intricate details of the hardware that is used for optimizing the processing, and all of them might not be exposed using APIs.
Thanks, NetworkOptimizer - a story like this one cries out for a devil's advocate opinion, so I'm glad for the input.
I do like your picture of the future ecosystem. It's probably going to be a long-long-term future. But I'd bet there are people at all these companies that have been expecting this transition for a long time -- and, at least for now, everyone else has to actually listen to them! :)
I was just being a devil's advocate. I tried using the OpenvSwitch and am exploring different applications on it, but this is too early (or I don't have enough contacts in the service provider industry to know that they are already bought into it).
One more aspect of this is that it would drive the router/switches/load balancers into PC style market. What I mean by that is there will be one or two (CISCO/HP/DELL) or some chinese vendor (Huawei) who optimize the supply chain and use volume pricing to drive any other hardware networking company out of the market.
The eco-system would be built such a way that you have hardware from a few companies and OS from few (Microsoft/Linux => Linux + Open Flow) and applications from everyone else. That would definetly revolutionize the industry. It will cannibalize some companies, but provides opportunities for others.
New software applications will be provided by ALU/Ericsson/Juniper/Riverbed/F5/Brocade/Aruba/Citrix(Netscalar)/Checkpoint/fortinet/netgear/palo alto/sonicwall or their replacements.
The apps consume entire industries - l2/l3 datacenter fabric, firewalls, load balancers, network security, application accelerators and wan optimization!
Dell/HP/IBM are the common links in the supply-chain for both PC and switch platforms. The assumption here is that the datacenter will converge and the server, storage and network hardware platforms will all be consolidated together as hardware commodities.
Sorry - I could'nt find a good place for cisco/juniper in the datacenter. They can play in the app space but their current business model will get battered in that scenario.
I remember the cute notion of running a JVM on your network processor so anyone could download the "appropriate" software and have a configurable network element.
OK, I'll admit that networking is moving so fast that we hardly have time to do the science that should come before the engineering. But there's gold in them thar hills, so we (engineers) skip the abstract stuff.
I think the challenge for academia as described by Scott Shenker is the right one: they need to run slightly ahead of us, with an academic basis for networking, rather than teaching what the engineers built, which may work, but is hardly scientific discipline, and usually not even worthy of mention.
MPLS-TP is a case in point. Please don't teach it in schools.
So, what do we think here? Is software-defined networking the long-term future of the industry, or just an academics' dream?