Slashdot Mirror
Vint Cerf: SDN Is a Model For a Better Internet
Nerval's Lobster writes "Vint Cerf, one of the 'founders of the Internet,' told an audience April 16 that if he could do it all over again, he would construct the Internet in the mold of Software-Defined Networking (SDN). Cerf, who co-designed the TCP/IP protocol suite with Bob Kahn, said that he admired how SDN separates the data plane from the control plane, which allows the network to be controlled via software from an external server. One of the hazards of conjoining the two, he added, was the attack risk. 'I wish we had done [the separation] in the Internet design, but we didn't,' Cerf told the audience for his keynote address at the Open Networking Summit in Santa Clara, Calif. 'In a very interesting way you have an opportunity to reinvent this whole notion of networking.'"
...SDN separates the data plane from the control plane, which allows the network to be controlled via software from an external server.
It must have been something you assimilated. . . .
The Economist, December 15th, 2012:
"“The technology is riding the fine line between promise and hype,” says Rick Tinsley, the boss of Silver Peak Systems, a networking firm. Sceptics fret that cost savings could easily be eaten up by the expense of new SDN controllers and software.
Better still, SDN makes it easier to reconfigure a network to, say, launch a new application for employees or customers. Its boosters liken it to a mobile-phone operating system onto which new apps can be loaded quickly and seamlessly. Small wonder, then, that companies such as Facebook and Google have been studying SDN carefully. Google runs two vast networks—one that links its huge data centres together and another that delivers its services to the outside world. The company has already deployed SDN across its data-centre network (which was not involved in this week’s snafu) and says that extending it to the external network is “inevitable”. Many big financial institutions and telecoms firms are also experimenting with the technology."
Vint's talk is on Youtube here (14mins in): https://www.youtube.com/watch?v=ZrUGythq9TI#t=844s
It's funny how great inventions were invented by chance. If the supposedly "great" inventors would re-do it today, they'd do it wrong and ruin it.
We attach too much credit to the people. It is the situation which led to the invention.
I think we are lucky that Cerf didn't see that "opportunity" when he worked on TCP/IP, because modifying the paths where data flows is essentially circuit switching. The routing protocol of the internet is so successful because it doesn't rely on switched circuits.
You could look at it that way, but why is that so awful? It seems you can reconfigure the "virtual circuits" dynamically, and it doesn't suffer from circuit switching's big limitation of fixed bandwidth
I'll take the "attack risk" every day that ends in Y far sooner than I'll accept the "corporate control" risk, thank you very much.
Putting the smarts in the network means cable tv and POTS.
More like cellular. At least on POTS the telco doesn't do anything with what you're sending.
The internet would be nothing more than the home shopping channel had they gone that route.
Yes. And those of us who were there at the beginning were against that. Centralized "software defined networks" already existed. Tymnet, Telenet, and X.25 were all centrally controlled, along with Prestel (UK), Minitel (France), and Qube (Columbus, Ohio). We knew what that world looked like, and rejected it.
The model for "software defined networking" is that users talk mostly to a limited number of sites (Google, Facebook, Youtube, Comcast, etc.) In that model, the service provider would like to control where their users connect to the many locations of the service. Google previously was pushing for a non-cached non-anonymous DNS system, so that the identity of the user determined where a DNS reference resolved. Nobody liked that much.
As much as I try I don't understand why people are interested in adding soo much complexity to what should just be dumbass pipes backed by a distributed topology optimization problem. The physical layout of the network is not software defined so why pretend otherwise? The answer is the same reason why virtual machines are soo popular...The OS stack vendors are too stupid to develop an operating system with the management characteristics required so rather than fixing the problem they just add another layer of indirection.
People are constantly doing shit at the wrong layer and refusing to comphrend why what they are doing is wrong. With each iteration global complexity skyrockets.
For example I tried to understand LISP but behind every bullet point of why it is better all I saw was the same problems BGP faces just shifted into different systems with new terminology and problems. For example how does multi-homing in LISP scale any better than BGP? The answer is tunnels!! Logical overlays on top of physical networks is a receipt for complex failure, security nightmares and poor quality of service but hey thats one less route in the DFZ.
Mobile IP are great and all but to do it on metal you need redirect which is the biggest single idiotic networking concept in the history of the universe so PPL invent all of this shit to do traveling tunnels which is fine I suppose until you ask the question why can't the protocol stack just deal with that?
Firewalls and "network" security are equally fundementally nonsensical concepts. Don't secure the network secure the peers!! Securing the network is a complete waste of time and resources especially since most damaging attacks are inside jobs but this does not stop people from adding layers upon layers of security gunk which either does not work without a "signature" or actually increase attack surface of the overall system.
SDN seems to be about control capwap/openflow type thing and are complex systems in their own right. There are a million different ways to manage the shit you have if more options helps solve anything then I'm supportive.. however it seems to me starting with the right configuration and dynamic protocols stands to minimize necessity for central management (and accompanying potential for catastrophic failure) of everything.
One big problem with SDN APIs including OpenFlow is that they ignore Layer 2 Quality of Service.
For example, there is no way to implement Ethernet Data Center Bridging (DCB) or Audio Video Bridging (AVB) with OpenFlow because there is no feedback about Ethernet frame buffer fullness between the data plane and the control frame.
It would not be rocket science to provide this awareness to the control plane, but I hope someone with the spare time can look into this!
As more time-sensitive flows such as audio and video (and drop-sensitive flows like FCoE) move onto Ethernet and IP, QoS will become more important!