Vint Cerf: SDN Is a Model For a Better Internet 69
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.'"
Sure, because... (Score:5, Funny)
...SDN separates the data plane from the control plane, which allows the network to be controlled via software from an external server.
Re:Sure, because... (Score:5, Funny)
Re: (Score:3)
Let's all agree they're different philosophies, like RISC and CISC.
And we all know how that one ended.
Re: (Score:1)
Let's all agree they're different philosophies, like RISC and CISC.
And we all know how that one ended.
Obviously CISC won. Except when I use my cell phone, tablet, or portable gaming system
Re: (Score:3)
And we all know how that one ended.
Yes we do. RISC accrued 'useful' instruction sets (e.g. NEON), whilst CISC simplified internally to a more limited set of instructions with an interpreter to turn the full instruction-set (usually x86) into ones the CPU can process, thus turning 'RISC vs CISC' into a decision as to where you want your last arbiter of instruction set simplification to lie: in the compiler (requiring you to recompile all your x86 code), or on the processor die (requiring a small hit to processor cost and complexity).
Re: (Score:2)
RISC also had a shitload of registers, far before amd64 architecture decided to tack some on to various registers all blessed for specific purposes by various instructions.
RISC has been about treating RAM as an I/O device instead of another set of registers, as much as it has been about simplifying the ISA. x86 goes back to that archaic time when RAM was as fast as storing things in a local register. With layer upon layer of cache, instruction reordering, register renaming, branch prediction, etc. quite a
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Thank god for the ultra secure model we have now, where we have to secure the control plane on every device individually.
If you want your system to be secure, do the following - in order of desired security level:
Note: Usability will decrease as security level increases.
Re: (Score:2)
...nothing could go wrong with allowing the network to be software controlled from a remote/external server - right?
What he's talking about doesn't necessarily mean the server is remote; It could reside on the same system. But by separating the roles, you could move it to another system within the same administrative domain, and it also reduces the vulnerability profile, if only because of KISS... fewer things for the software to do means fewer bugs and bugs that are found are easier to troubleshoot.
Re: (Score:1)
That Vint Cerf has no idea what he is talking about. I mean what has he ever done?
Re: (Score:3)
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
Re: (Score:1)
The Economist article on SDN (Score:5, Informative)
The Economist, December 15th, 2012: [economist.com]
"“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."
Re:The Economist article on SDN (Score:4, Insightful)
Once again, bean counters chime in with the usual rhetoric. "It's impossible. It can't work! It'll be too expensive! Implimentation will be difficult! The benefits aren't enough!"
Sorry, with an attitude like that, the Internet wouldn't exist. Let me tell you something about IT: Never listen to the bean counters. If you think you can do it, go for it. Nothing pisses people off more than saying it's impossible and then being shoved out of the way by the person doing it. And I'm all for pissing off the mediocre... any day of the week.
Re:The Economist article on SDN (Score:5, Funny)
Let me tell you something about IT: Never listen to the bean counters.
Caveat: Unless you marry one.
In which case, not only do you listen, you never, ever call them a bean counter to their face.
Had to learn that one the hard way myself...
Re: (Score:2)
not only do you listen, you never, ever call them a bean counter to their face
No offense, but an obvious inference is that bean counters have no sense of humor. One thing you can say for most engineers and programmers is they have a sense of humor about it. From what I understand "geek" and "nerd" are not universally considered complimentary.
Re: (Score:2)
Re: (Score:3)
Once again, bean counters chime in with the usual rhetoric. "It's impossible. It can't work! It'll be too expensive! Implimentation will be difficult! The benefits aren't enough!"
Sorry, with an attitude like that, the Internet wouldn't exist. Let me tell you something about IT: Never listen to the bean counters. If you think you can do it, go for it. Nothing pisses people off more than saying it's impossible and then being shoved out of the way by the person doing it. And I'm all for pissing off the mediocre... any day of the week.
You seem to have confused IT with R&D -- it's not Corporate IT's job to invent new technologies like the Internet. It's IT's job to implement business solutions that meet the needs of the business -- and that includes satisfying the bean counters that there's a good return on investment.
The reason the bean counters are counting beans is to make sure there's enough beans to keep the company running.
Installing the latest and greatest bleeding edge technology is rarely the best option unless you have speci
Re: (Score:2)
You seem to have confused IT with R&D -- it's not Corporate IT's job to invent new technologies like the Internet.
Dude, I work in "Corporate IT", and yes, my job is to invent new technologies. Amusingly, most of the new stuff I write is to fix the broken old stuff they haphazardly implimented because the bean counters said we didn't need a budget as big as originally specified to get the job done.
The reason the bean counters are counting beans is to make sure there's enough beans to keep the company running.
The reason us engineers refer to them as bean counters is due to the old proverb "penny wise and pound foolish." Bean counters cut corners wherever they can. The bean counter says if we use this kind of concrete instead of tha
Re: (Score:2)
You seem to have confused IT with R&D -- it's not Corporate IT's job to invent new technologies like the Internet.
Dude, I work in "Corporate IT", and yes, my job is to invent new technologies. Amusingly, most of the new stuff I write is to fix the broken old stuff they haphazardly implimented because the bean counters said we didn't need a budget as big as originally specified to get the job done.
Sounds like you have a failure in IT Management, not bad Bean Counters. If there's not adequate budget to do the project, then it's the manager's job to either cancel the project, or scale it back to fit withing budget. Pretending to do the project but doing a half-assed job that requires fixing up later doesn't do anyone any good.
The reason the bean counters are counting beans is to make sure there's enough beans to keep the company running.
The reason us engineers refer to them as bean counters is due to the old proverb "penny wise and pound foolish." Bean counters cut corners wherever they can. The bean counter says if we use this kind of concrete instead of that kind, it'll cure faster and we'll save on labor. The engineer knows that the concrete was chosen because it has less fracturing risk. So the bean counter saves the project $30,000 now, but then the bridge needs an additional $350,000 in materials and labor over the service life. That's why we hate bean counters -- they only thing of the "now". They rarely look at the big picture.
Again, that's a management failure - in my company, bean counters aren't giving line item veto power over the project budget. They may ask for a 10% cut in budget, but it's the bu
I am glad he got this "wrong" (Score:2)
Putting the smarts in the network means cable tv and POTS.
The internet would be nothing more than the home shopping channel had they gone that route.
Me too, and I was around back then (Score:5, Insightful)
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.
Re: (Score:2)
What "software defined networking" really does (Score:2)
There's the part about managing network address space in one's own internal network, which is reasonable enough. Then there's the part that says A can't talk to B unless Master Control says it can. That's what the misnamed "OpenFlow" [openflow.org] is about. This is OpenFlow in a nutshell:
Each flow-entry has a simple action associated with it; the three basic ones (that all dedicated OpenFlow switches must support) are:
Re: (Score:2)
Re: (Score:2)
The model for "software defined networking" is that users talk mostly to a limited number of sites (Google, Facebook, Youtube, Comcast, etc.)
And while Vint lead the charge on SOPA and PIPA, I haven't seen anything from him on CISPA since last May, when he was stridently against it. Isn't CISPA up for a vote today or tomorrow? Way to change the subject...
SDN is mostly a data center LAN technology (Score:2)
There's a lot of different and vague stuff running around under the name SDN lately, but a lot of it seems to be a replacement for the complex networks of expensive Cisco switches are used in data centers, instead of all of the different Spanning Tree Protocol variants that lead to inefficiency and long convergence delays when equipment breaks ("long" being defined as "more than a few seconds", often accompanied by a couple of minutes of BGP reconvergence.)
Telephone networks in the US had Signalling System
video (Score:2)
Great inventors invent by chance (Score:5, Insightful)
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.
Re: (Score:1)
Throw Steve Wozniak in the same camp. Lightning doesn't always strike twice.
Re: (Score:3)
Re: (Score:3)
CC.
Re: (Score:1)
silliness (Score:1, Funny)
This is just silly. We all know Al Gore invented the internet so what does this Vent Cerf guy have to do with "doing it all over again"?
Re: (Score:2)
Worth the risk (Score:5, Insightful)
Interesting... (Score:1)
Re: (Score:2)
I can't tell.. (Score:2)
Is Cerf getting senile? Or does he have large amounts of stock in an SDN company?
Google OpenFlow (Score:2)
Re: (Score:1)
Also during his presentation Vint Cert raved about the taste of his company's dog food.
Pep rally at the pet food company.
The boss asked whose dog food has the most lean red meat? Ours does boss.
Which has the most vitamins? Ours does boss.
Which has the most minerals? Ours does boss.
It went on like this, and finally at a high point in the ceremony, he asked:
Why isn't it selling? From the back of the room, someone said, "the damn dogs don't like it boss."
There already is a store and forward technology su (Score:1)
Re: (Score:2)
Vint Who? (Score:2)
Oh right, this guy: http://www.icann.org/en/groups/board/cerf.htm [icann.org]
The guy who spent 8 years as Chairman of the Board of ICANN, one of the most corrupt organizations on the Internet.
Please stop trying to make the Internet better (Score:3, Insightful)
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.
Re: (Score:2)
An insightful rant.
We have only been building multitasking OSes for what, 50+ years, and yet people feel the need to instantiate a full VM just to run an additional instance of an application. Of course, the fact that many apps run on well known TCP ports (instead of using DNS service names) makes it difficult to demultiplex to multiple instances of the same app, unless each instance is running in a VM with a virtualized NIC address. IPv6 could fix this problem without the overhead of virtualization (give
Re: (Score:2)
break the Cisco strangle-hold
This is the aspect of it that astounds me. Cisco does a solid enough job and all, but in terms of manageability, they aren't untouchable. They are largely untouched by many of the competitors who fail to grasp why Cisco is so entrenched, but if they had a hint of vision and understanding, they'd be comparable to Cisco in short order. True, Cisco has a lot of momentum, but deliver comparable manageability at an attractive price, and Cisco's special hold will dilute more easily than many would guess. Part
SDN and QoS (Score:5, Interesting)
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!
Re:SDN and QoS (Score:4, Informative)
It is kind of problematic to add it to a detachable control plane. The flow controllers can only be divorced from the 'data plane' only because there is a modest amount of traffic to set up the fairly 'dumb' flows. If the flow controller had to get enough data to competently do QoS, it would be a scalability nightmare for a large fabric. For a small fabric, doable, but at that point the flow controller concept kind of loses a lot of the promise of value. I suppose you can add nearly one flow controller per switching device, but you get nearly back where you started. There is some remaining value in the flexibility of the system, but that could have been achieved through more open firmware without the distinction being created between data and control plane.
Re: (Score:2)
I see what you mean. To do QoS you need to "un-dumb" the data plane a bit. Perhaps there could be something minimal such as priority queues and bandwidth reservation between ports on a single switch, with the data plane handing bandwidth reservation across multiple switches/routers.
Re: (Score:2)
e.g. that's the way infiniband works. QoS and flow control are done by the switches, but routing decisions are left up to the subnet manager. It's really analagous to the concepts put fourth in SDN.
state (Score:1)
you know, vint knows alot better
the problem with the 'external agent' is that in involves stateful decisions about flows in the networks
10-20 years ago, that was anethema to network designers, and you know, they were rights. stateless
machines are inherently more robust, and the central controller doesn't really buy you jack.