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.'"

Comments

Sure, because...

[fahrbot-bot]

...SDN separates the data plane from the control plane, which allows the network to be controlled via software from an external server.

...nothing could go wrong with allowing the network to be software controlled from a remote/external server - right?

Re:Sure, because...

[jon3k]

Thank god for the ultra secure model we have now, where we have to secure the control plane on every device individually.

Re:Sure, because...

[ericloewe]

Let's all agree they're different philosophies, like RISC and CISC.

And we all know how that one ended.

Re:Sure, because...

[dgharmon]

"Thank god for the ultra secure model we have now, where we have to secure the control plane on every device individually."

:) haaa

Re:Sure, because...

[Anonymous Coward]

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:Sure, because...

[fahrbot-bot]

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:

1. Safe: Unplug the CAT-5 cable and/or disable that wireless card.
2. Safer: Power off the system and put it back in the box.
3. Safest: Nuke it from orbit - only way to be sure.

Note: Usability will decrease as security level increases.

Re:Sure, because...

[EdZ]

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:Sure, because...

[girlintraining]

...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:Sure, because...

[ultrasawblade]

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 an illusion is kept up. Interestingly, 6502 was built around that concept with its very limited number of general-purpose registers.

Re:Sure, because...

[Anonymous Coward]

That Vint Cerf has no idea what he is talking about. I mean what has he ever done?

Re:Sure, because...

[Anonymous Coward]

Such as with CALEA provisioning, built right into every service provider router on the market.... I hated seeing my VPN ACLs incrementing to our CALEA provider...cause it meant somebody was getting their giggly-bits sucked up into a Federal investigation.

Re:Sure, because...

[terjeber]

Yep, they both co-existed forever.

Re:Sure, because...

[Anonymous Coward]

no nothing.

http://hardware.slashdot.org/story/13/04/16/1350242/google-glass-specs-hit-the-web

It said do this in rememberance of me or else I'll disable your hardware.

Software said so.

SDN is circuit switching

[Anonymous Coward]

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.

Re:SDN is circuit switching

[ebno-10db]

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:SDN is circuit switching

[hamvil]

Core and backbone is circuit switched since 15 years. All the optical paths are basically circuit switched (they are usually called lightpaths) and on top of this fiber lines there is an overlay for the signalling and path setup. SDN is actually fantastic in datacenters because it makes a lot easier to have multiple path and to avoid loops (spanning tree protocol are slow and error prone). I have no idea about how the big guys (google, facebook, etc.) do it, but in common datacenters you have only one spanning tree active at the time. If something fails you rely on reactive protocols. In SDN you can actually have multiple spanning trees at the same time.

Re:SDN is circuit switching

[Anonymous Coward]

That's nice if you use it for managing the links in your network facilities, but Cerf is talking about making the internet use SDN in its core protocol.

The Economist article on SDN

[Beeftopia]

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."

Re:The Economist article on SDN

[girlintraining]

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

[CanHasDIY]

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:The Economist article on SDN

[SternisheFan]

Sounds to me like you could relate to this TheOnion article...

http://www.theonion.com/articles/boss-has-deft-touch-for-making-employees-feel-like,32084/

Re:The Economist article on SDN

[ebno-10db]

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:The Economist article on SDN

[Anonymous Coward]

The mistake was giving beans to count. It's 2013 let them count their own frigin beans, unless you were spending her beans in which case... look have far we've progressed, mens liberation has arrived. Well done.

Re:The Economist article on SDN

[hawguy]

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 special needs that can only be met by that product - you'll pay a premium to be an early adopter as well as becoming an unwitting beta tester, and then you'll find that it's almost, but not quite compatible with the standards based products that come out a year later. Like the "Draft-N" Wifi routers that couldn't be upgraded to the full 802.11N standard (or maybe they could but the vendor didn't bother since he wants to sell you all new equipment).

Re:The Economist article on SDN

[girlintraining]

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 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.

Installing the latest and greatest bleeding edge technology is rarely the best option unless...

Whoa there cowboy. Nobody said adopting the "latest and greatest". We're talking about packet-switched networks needing a redesign because they're costing us a fortune in security, labor, etc., because of a design decision made early on that turned out to be less than optimal. The argument here is that we can spend more up front, but save a lot more in maintenance down the road. It has nothing to do with "cutting edge" anything.

Re:The Economist article on SDN

[hawguy]

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 business unit and IT's job to decide what to cut out of the project to meet the new budget. And again, that doesn't mean doing a half-assed job at implementation.

In my experience, the Bean Counters do look at the big picture when it's presented to them. If a project costs $X to implement but saves $Y/year in labor and maintenance, it needs to be spelled out when getting project approval. But you can count on them coming back to you in a year for proof that you saved $Y/year so make sure your project proposal included the analytics to show the cost savings.

Installing the latest and greatest bleeding edge technology is rarely the best option unless...

Whoa there cowboy. Nobody said adopting the "latest and greatest". We're talking about packet-switched networks needing a redesign because they're costing us a fortune in security, labor, etc., because of a design decision made early on that turned out to be less than optimal. The argument here is that we can spend more up front, but save a lot more in maintenance down the road. It has nothing to do with "cutting edge" anything.

Sure, I'm not arguing against using current technology, just against using ignoring cost justifications and using bleeding edge technology just because "If you think you can do it, go for it." If you "think" you can do it, you probably didn't do enough research on the solution and probably shouldn't be doing it. What you're describing is a cost-justified implementation "we can spend more up front, but save a lot more in maintenance down the road". If you can write that up and present it to your Bean Counters, they may very well approve it. Or maybe not, maybe cash is tight and they don't want to spend $100,000 today to save $20,000/year over 5 years.

Re:The Economist article on SDN

[Anonymous Coward]

Your company is a subsidiary of Heaven on Earth.

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.

I'm currently in second in charge of IT for an entire country for a conglomerate and they always want the world and never want to pay the money to do it, but this is real life, you can't give them nothing so a half-assed solution it is. Obviously it doesn't do anyone any good but what are the choices? Do nothing, it goes to someone else and/or you get shafted. Throw a tantrum, it goes to someone else and/or you get shafted. Cancel it, if you can, it goes to someone else and/or you get shafted. Seeing a pattern here?

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 business unit and IT's job to decide what to cut out of the project to meet the new budget. And again, that doesn't mean doing a half-assed job at implementation.

IT Management can't fix the highest echelons of Management, if you're able to cut your budget and not have make an impact on meeting requirements then you were spending too much to begin with. My definition of half-assed is not being able to meet the requirements. If you don't have enough money then you are either not costing things up properly or you are not meeting requirements.
Problem is management are the bean-counters, and it's always easier to give in and do a half-assed solution because it gets them off your back and it can, in certain instances, still be better than nothing. The chain to the end-user is so long that the people making the decisions will never hear about the problems and will only notice unexpected costs/inefficiencies, then they'll complain about it or ignore until the next problem/project comes up, ad infinitum.

I am glad he got this "wrong"

[h4rr4r]

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.

video

[porjo]

Vint's talk is on Youtube here (14mins in): https://www.youtube.com/watch?v=ZrUGythq9TI#t=844s

Great inventors invent by chance

[loufoque]

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:Great inventors invent by chance

[Anonymous Coward]

Throw Steve Wozniak in the same camp. Lightning doesn't always strike twice.

Re:Great inventors invent by chance

[Attila Dimedici]

You are not entirely wrong, but often times it is the right person in the right situation which leads to a great invention. People who have made great inventions are generally great people. In many cases, if someone lesser had been in that situation something less would have been invented (or nothing at all).

Re:Great inventors invent by chance

[foobsr]

http://en.wikipedia.org/wiki/Serendipity

CC.

Re:Great inventors invent by chance

[datavirtue]

Indeed, I'm tired of hearing about people who invented a technology, it is a waste of dendrites for people learning about the tech because it doesn't matter in the least little bit. In fact, it barely amounts to something worth pleasure reading on Sunday, let alone countless space in text books. Professors still have test questions asking who invented such and such technology, makes me sick.

silliness

[Anonymous Coward]

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:silliness

[datavirtue]

Neckbeard alert! 20 year old neckbeard alert!! *whoooooooop* We have a teat-sucking college student code 7 alert folks!

Worth the risk

[FuzzNugget]

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.

Interesting...

[shaitand]

It's odd how anyone else saying they want to reinvent the network just goes in one ear and out the other but when this guy says it I suddenly pay attention.

Re:Interesting...

[CptNerd]

Someone who's accomplished something once has a leg up on someone who's talking about doing something. It's why the guy who jumped out of the high-altitude balloon paid attention to the guy who did it first.

I can't tell..

[stenvar]

Is Cerf getting senile? Or does he have large amounts of stock in an SDN company?

Me too, and I was around back then

[Animats]

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:Me too, and I was around back then

[mjwalshe]

wouldn't have called x121, x.25, x.400 and x.500 software defined networking - in the sense Vint is using it here.

Re:Me too, and I was around back then

[bill_mcgonigle]

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...

There already is a store and forward technology su

[DerekClarke]

It's called email...

Google OpenFlow

[nickmalthus]

Also during his presentation Vint Cert raved about the taste of his company's dog food.

Re:Google OpenFlow

[Anonymous Coward]

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."

Vint Who?

[rudy_wayne]

Oh right, this guy: http://www.icann.org/en/groups/board/cerf.htm

The guy who spent 8 years as Chairman of the Board of ICANN, one of the most corrupt organizations on the Internet.

Re:Vint Who?

[Anonymous Coward]

.LOL

Re:Vint Who?

[Anonymous Coward]

Yeah Vint who monitized his "founder" rep to sell his soul to... an broker. An an broker who bought a name for PR, in order to look good. Fuck off Vint. You are no longer relevant.

2600 capt'n crunch = control and data combined

[Anonymous Coward]

The telcos used to put control tones on the same wires as voice.

That worked out really well for them.

Not.

Re:There already is a store and forward technology

[techno-vampire]

Actually, there are two. The other one is Usenet.

Please stop trying to make the Internet better

[WaffleMonster]

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:Please stop trying to make the Internet better

[Steve Blake]

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 each app instance it's own IPv6 address).

Mobile IP and LISP are just bandaids trying to stem the bleeding from the poor design of TCP/IPv4, which ties application instance naming to a small port number plus a topology locator. ILNPv6 (RFC6740) or HIP (RFC 5201) fix the same problems in much more elegant ways.

SDN, properly conceived, has some valid technical use cases. Centralized, reactive, per-flow switching is not one of them (wait and see how the network behaves on a node-down). A lot of what has driven SDN to-date is not technical, but political: break the Cisco strangle-hold and provide something shiny for the VCs to pour money into.

Re:Please stop trying to make the Internet better

[Junta]

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. Particularly since Cisco hasn't been very competitive performance wise and especially not price performance wise in a long while (they don't need to be and to get that position would require investment they don't feel the need to make)

Re:Please stop trying to make the Internet better

[Anonymous Coward]

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.

I use to be like that, then I became an addict. Some benefits offhand for doing things technically inefficient like what you describe.

• Computing resources are becoming cheaper then the time it takes to manage processes which use them, this reduces the impact of the cost of overhead for things like virtualisation.
• VMs can be moved around, applications not so much. If I have multiple applications on one instance I'm reducing my flexibility and increasing required effort in situations where I want to move one but not the other(s).
• More software is being packaged as 'appliances'. If you can achieve what you need in a blackbox as opposed to a whitebox, why not? It usually makes diagnosing problems easier for yourself and if you need to escalate to the provider, they will be familiar with your environment (since they designed it) saving time and effort.
• Saves time in diagnosing problems, most niche/corporate software is trash, I can't count the number of times devhouses have tried to weasel out of liability by claiming conflicts with other software or the environment/configuration was unsupported or deviated from their strict guidelines. If there is nothing else on the system but their application it reduces the number of excuses and false leads.
• Security. Privilege escalation due to trashy software? Need to give remote access to software support personnel or specialist? It's much more isolated and contained.
• Backing up entire VMs is easier and has shorter recovery times as opposed to application-specific backup solutions or in-band backup solutions it can be worth the extra overhead.
• Some applications require strict OS configurations which don't place nicely with other applications, usually this is a design fault of the trashy software but in most cases you don't have a choice.

Sorry, but in most cases, I'll eat up the inefficiencies any day for the benefits above. As for SDN, I agree, but I think part of it is what I mentioned above. Specialists time is better put elsewhere, with computing resources becoming cheaper and cheaper it becomes cheaper to reduce time to manage all this technology at the cost of using more computing resources, even if it is not technologically efficient and elegant.

SDN and QoS

[TheSync]

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

[Junta]

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:SDN and QoS

[TheSync]

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:SDN and QoS

[Junta]

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.

Analogies

[Anonymous Coward]

Distract. And are rarely accurate.

state

[Anonymous Coward]

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.

What "software defined networking" really does

[Animats]

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" 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:

• 1. Forward this flow's packets to a given port (or ports). This allows packets to be routed through the network. In most switches this is expected to take place at line rate.
• 2. Encapsulate and forward this flow's packets to a controller. Packet is delivered to Secure Channel, where it is encapsulated and sent to a controller. Typically used for the first packet in a new flow, so a controller can decide if the flow should be added to the Flow Table. Or in some experiments, it could be used to forward all packets to a controller for processing.
• 3. Drop this flow's packets. Can be used for security, to curb denial of service attacks, or to reduce spurious broadcast discovery traffic from end-hosts.

So there it is - built in, scalable, universal wiretapping, connection monitoring, and censorship. It's what the RIAA, the MPAA, the FBI, and the Great Firewall of China operators all want.

Re:What "software defined networking" really does

[mjwalshe]

Nasty

Re:What "software defined networking" really does

[Anonymous Coward]

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" 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:

• 1. Forward this flow's packets to a given port (or ports). This allows packets to be routed through the network. In most switches this is expected to take place at line rate.
• 2. Encapsulate and forward this flow's packets to a controller. Packet is delivered to Secure Channel, where it is encapsulated and sent to a controller. Typically used for the first packet in a new flow, so a controller can decide if the flow should be added to the Flow Table. Or in some experiments, it could be used to forward all packets to a controller for processing.
• 3. Drop this flow's packets. Can be used for security, to curb denial of service attacks, or to reduce spurious broadcast discovery traffic from end-hosts.

So there it is - built in, scalable, universal wiretapping, connection monitoring, and censorship. It's what the RIAA, the MPAA, the FBI, and the Great Firewall of China operators all want.

Uh, wiretapping traffic on your own network? You don't need to define your routes in software to do that.

AIUI, SDN's big benefit is global QoS. Instead of injecting a packet on the backbone, only to have it dropped after it reaches the backed-up receiving edge, you can push back at the sending edge. That's the one thing that a centrally managed routing table buys you that a per-device view doesn't get you.

Or did you really think that SDN is all about company A issuing commands to company B's routers, and having company B's routers saying "doy, sounds good to me!".

SDN is mostly a data center LAN technology

[billstewart]

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 7, which ran over X.25 separate from the circuit-switched data, and one advantage of having a separate control plane for routing was that you could have a backup X.25-over-satellite network, so that the signalling system would work even if you lost the fiber or copper trunks between two or more sites.