Slashdot Mirror
Inventor of OpenFlow SDN Admits Most SDN Today Is Hype
darthcamaro writes "Every networking vendor today is talking about Software Defined Networking (SDN). The basic idea is that the control of the underlying networking hardware is abstracted by software. Martin Casado helped to come up with the whole topic with his 2005 Stanford thesis (PDF). Eight years later after selling his startup Nicira to VMware for $1.2 Billion, Casado sees the term SDN meaning everything and nothing to all people. From the article: '"I actually don't know what SDN means anymore, to be honest," Casado said. Casado noted that the term SDN was coined in 2009 and at the time it did mean something fairly specific. "Now it is just being used as a general term for networking, like all networking is SDN," Casado said. "SDN is now just an umbrella term for, cool stuff in networking."'"
I need to build a business around some new buzzword and sell it to VMware. Cloud and everything related to it has really stagnated development of other areas of IT in my opinion. Companies try and figure out WTF SDN is or how to integrate their networking stack with AWS instead of focusing on what's really happening in the IT world.
It's the way of the future.
...all the fiber optic cables with software? We aren't going to move everything to the cloud, including the cloud?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
...no reason not to be honest.
I am very small, utmostly microscopic.
So the only benefit to "SDN" whatever it is that I can tell is that it will could possibly allow source routing. The existing protocols basically will route your packet the shortest hop way or another under guidance of some other metric, unless you set up the router to do some hacks (I hear). The setting up part is done by a human, a network engineer, and the SDN folks think that it shouldn't be done by a network engineer, it should be done by end point software because the network engineer is a human so he is slow and therefore a lesser being than the software engineer, who thinks he knows better. The other reason is that the router vendors are slow in making features available (who needs testing) or fixing bugs in the routers, so the SDN guys think they can write software that does the same thing better and faster.
One application of being able to source route is to trunk over multiple slow links, which normally won't happen with typical routing protocols which will give you one of the routes, usually the lowest-latency link though that is purely up to configuration. Trunking would give you the whole net's bisection bandwidth. Until someone else wants to do the same thing at the same time. "What, there's other software engineers who have machines connected to the Internet?"
Another is on-demand QoS. The killer app is probably to build a DDoS infrastructure foothold into nation states' critical systems. Imagine having wire-rate SDN routers being able to reflect and replicate from within the network.
I'm glad he's laughing all the way to the bank. Gives me room for my new buzz-word compliant technology: Hardware Optimized for Software Systems (HOSS)
Shhhh, it's just ASIC in sheep's clothing.
If you wanted your new buzzword to have a real meaning perhaps you should have named it something that actually means something. The words Software Defined Network have a generic, non-specific meaning, that's why they are being applied to everything that even remotely fits their definitions. Whatever happened to real names with specifics, like "Carrier sense multiple access with collision detection"
From what I can tell it is the idea of having all of the routing centralized at one location with nodes which just accept the commands to route certain src and dst streams. It is different because the software defines the routing on a server in a logical representation for centralized management while the nodes are just really hardware appliances.
It is a nice idea to reduce cost, but in my opinion this is where you would never want to do something like this because it allows way too much power in a central authority.
It would be a Chinese government dream network though and the NSA/CIA would piss themselves that ever happened.
(i.e. In such a system the distributed BGP internet would just go away.)
I am totally against it, and I think everyone will be after they see what the real intent is: To bring network layer control through software to a central authority, which isn't possible right now, and once done, shut it down whoever isn't in the 1%.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Marketing does not kill innovation
What really kills innovation is the management's blind push to squeeze the last penny out of existing products
Instead of making improvement, instead of thinking out of the box, instead of innovating --- the bottom-line minded management prefer to "squeez another drop of blood out of what we are producing" instead of pumping money into more R & D, or give the "crazy ideas" a try
Muchas Gracias, Señor Edward Snowden !
OpenFlow is basically a way to turn a packet network into a rather dumb virtual circuit network. It works something like Tymnet, circa 1971. In Tymnet, all the virtual circuits were set up by a "supervisor" computer, which told each node where each flow was supposed to be forwarded. The supervisor also handled authentication, but data packets didn't have to pass through the supervisor once the connection was set up. That's what OpenFlow does, mostly. The first packet of each new "flow" (IP/port/IP/port set, usually) is sent to Master Control, which decides whether that flow will be allowed. Master Control can also choose to monitor the flow. The implications are obvious.
DOCSIS 3, the cable modem traffic control architecture, can potentially do most of the same things, and offers better control over bandwidth. DOCSIS 3 tends to be run more to control users than to maximize throughput, but that's a marketing issue. (If your cable connection is throttling something, the commands to do it were probably sent to a DOCSIS node.) There's good QoS and fair queuing stuff in DOCSIS 3, but it's not always used intelligently. DOCSIS is less intrusive than OpenFlow; the nodes are sent rules to enforce, but there's no need to get permission of Master Control for every new flow.
The rest of "software defined networking" seems to involve adding another layer of indirection to Ethernet addresses so they can be moved around within the data center. ("There is no problem in computer science that cannot be solved by adding another layer of indirection.") That's a reasonable network management tool, but it's not exactly a profound concept.
Yes, SDN hardware will definitely help with your cloud problem. It works with all cloud software stacks and is the final piece of the puzzle to make it all work together.
We can start shipping hardware to your data center and all your offices today, just sign here. And yes, we will have engineers at all your sites to properly install and configure the hardware and train your IT personnel. They will stay on-site until all issues are resolved.
Sleep your way to a whiter smile...date a dentist!
It is used (without knowing they are using it) by people that avoided legacy one router/cable per task Cisco mentality.
Remember Cisco 1700/2600/3600 and how doing ANYTHING on them cost you ass load of money? It was never a question of what should we do, it was always a question what thingamajiggy we should buy to do this one specific thing we want.
Never generation stopped to give a shit about Cisco/Agere/Lucent/Juniper and started deploying all manner of embedded Linux/BSD with software routing. Sure it is slower than dedicated silicon, but it is also much cheaper and more flexible.
Who logs in to gdm? Not I, said the duck.