Enterprise, Service Provider, Cloud Data Centre. Who’s first to ride the SDN revolution? (And where’s it taking them?)
Date: Mon, 12/03/2012 - 19:02
With massive and successful deployments by Google, NTT, Genesis Hosting and others, there is little doubt about SDN as a workable and effective system, so the next question is: which sector will be first to reap the benefits?
Ian Keene, Vice President, Gartner, at NetEvents EMEA Press and Analyst Summit, Algarve, Portugal
PHOTO / telecomkh.com
We’ve selected speakers with specialist insight into the requirements of enterprises, service providers and cloud data centres utilising SDN to summarize their specific needs and objectives.
Who can make the best offer for which sector? And what immediate and long term benefits are being promised? Our analyst panel at NetEvents EMEA Press and Analyst Summit, Algarve, Portugal, will then provide their views on the vendor pitches and open up to the audience who will be the final judge of this session.
Arpit Joshipura, Vice President of Product Marketing, Dell
Markus Nispel, Chief Technology Strategist, Enterasys
Shehzad Merchant, VP of Technology, Extreme Networks
Mike Banic, VP Global Marketing, Networking, HP
Charles Ferland, Business Unit Executive, IBM
Emir Halilovic, Networking & Infrastructure EMEA, IDC
Pim Bilderbeek, Analyst, the METIS files
We are going to be looking at software defined networking today. Really as a background to the way it is going to work, I am going to say a few words, then the panel, not all of the panel, but five of the panel, are going to give an elevated pitch about what they think of software defined networking and where their company fits in. They are short pitches, do not worry too much. Then we are going to -- Pim is going to say a few words in the perspective of an analyst and then we are going to ask some questions.
So, right first of all, if we can go to -- sorry I did not realise I had to do it, lazy. I see I was pushing the wrong button.
Right, who is first to ride the SDN revolution and where has it taken them? That is a question that we want to answer, and one of the things I will be posing to the panel here.
But I think first of all a little bit of background on software defined networking. It is something that has been really rising up the hype cycle in 2012. Back in early 2012 it was actually at a NetEvents event that there was a discussion on SDN, software defined networking, and it was fairly new to most people. And it is something people started to think about.
I remember at that NetEvents there was a service provider, Deutsche Telecom in fact, who was very interested in the possibilities of software defined networking for their network. Which is really quite something different than data centre applications, where most people just think of software defined networking as data centres, isn't it? Well, it's more than that.
And really we have seen an awful lot of interest grow over quite a lot of different user types during this year, and it really has expanded. And it also follows the current fashion for reinventing old ideas. Like, you can think of cloud computing, really it has got hints of mainframe computing in there. As computing needs change then maybe distributed computing is not such a great idea after all, and centralising it in a different way than the old mainframes, but nevertheless centralising it, makes sense again.
And here we are going to software defined networking. In the very beginning of networking, of Ethernet networking, a [token ring] come to that I suppose, we had bridges and we had routers and we had gateway products and different levels of the OSI stack, they did different things. Then people invented switches, which was really quite a different thing. That is going back about 25 years ago. Then, not only can you just switch at layer two, but you can integrate some routing intelligence at layer three.
All of a sudden, all of these different products that did different things in networks you could just go out and buy a layer three switch and it did the whole darn lot for you. You plug it in, and off it goes; you have a network.
So now we are starting to look at that again. And we are looking at, well maybe the needs of networking have changed. And maybe that idea of just sticking it all in one layer three switch/router box is not the best way forward any more.
I am not answering that question today. It is my position to host the debate here. But maybe that is a question you can think of. Do we really need to change the way we do networking. Or are last year's boxes good enough next year? I do not know, that is one of the questions I think we would like to try and answer today.
So, software defined network, it was an idea out of Stamford University. So, strictly speaking it was not born in the data centre, I learnt this morning, but in the campus environment. But most people thought, that is a great idea for data centres. Probably the main reason they did that was because that was the sort of thing Google were doing. Because, Google were not going out and buying these vendors' boxes, or Cisco boxes or anything like that, they were doing it a different way, and potentially a lot lower cost way. Although, I am sure, our panel will argue against that.
But it was really a new way, it is an idea that first of all started to see real applications in the data centre. And then a standard started to emerge, because if you have a technology you have got to have a standard, at least one. So the Open Network Foundation was a group of industry bodies ranging from the Googles and Microsofts of this world to the Verizons and Deutsche Telecoms and Singtels of this world and to the equipment vendors such as Cisco and Fujitsu. But, not just the people who traditionally would make networking gear, but also the carrier network infrastructure people as well got interested, like Alcatel Lucent and [Coari] to just to name, a couple as examples. I am not particularly singling these vendors out because they are the best, but it is just an example.
So, we are getting a standard but there are lots of proprietary solutions as well, as I am sure the panel will go. And another question I will have is, do we really need a standard here? Is it just the idea of software defined networking good enough to follow? So that is something they have an opinion on.
And who is interested? As I say, it started off real interest data centres, it could make things more flexible, easier to control, more efficient in terms of the volume of data in a network and lots of different features we could put in. But it has also grown into enterprise local area networks. And, as I say, a lot of interest from very little interest at the beginning of 2012 to a lot of interest in carrier networks; communication service provider networks.
Now, if I talk to a company like Coari or Alcatel Lucent they will say, if they are going in to pitch with a leading service provider out there, they have got to have a software defined networking story. They don't have to have a product yet, but they have got to have a story.
Slide two, what are the benefits here? Write it yourself controller software is certainly possible. Because essentially what software defined networking allows you to do is to take a lot of the control functions away from a box, and it is actually a piece of software running on a server. This is a very crude description of course. And so you can add new features and functions when you want to. You can write your own code and whatever. The idea is, the essence was, that you do not have to put in a request to your vendor, your equipment vendor and say I need this function. And they go away and say, okay and six months they come back, okay we have written the code for you now; you could go and do it yourself.
Quick service deployment; enables you to deploy new services, because you could do policy based control here. So you could say according to this policy, this is how you treat traffic on the network. And you can analyse also what is going on and make changes as necessary. You can provide infrastructure as a service much easier. And basically, you can provide the quality of service needed, on demand. It is not something that is set in routing tables on 500 different boxes in your network that takes quite a bit of time to change.
Some vendors, and none of the vendors on the panel today I have seen say this, so I purposely chose a quote from someone else, claim a 50% reduction in operating costs. Now, that is a big claim. I have not seen exactly how that could be substantiated. But that again is a question we are going to ask the panel. Is this going to save anyone money, or does it just make it easier to run your network.
And, in theory, following a full standard, open flow, it will make a multi-vendor switch environment much more of a practical reality. But vendors are good at locking customers in, and I am sure they will carry on doing so.
So this is my dumb down and I mean really dumb down definition of what software defined networking is. I made a typo there, I put in open flow, I did not mean open flow, sorry, I meant software defined networking, a bit of a slip.
And as we were talking about at breakfast today, people think software defined networking, that is open flow isn't it? And I must admit I was guilty of that at the beginning of this year too. No, it isn't. It is a flavour perhaps of software defined networking, but it isn't the be all and end all of software defined networking.
So, you have got your classic these days, sit in your network a layer three switch, it does the switching and routing functions. Software defined networking says get rid of all that clever stuff that needs thought and policy management, the layer three stuff, the routing stuff, and put it somewhere else. And so your switch basically becomes a layer two switch, it is told what to do by another entity and it just does it; so it is dumb down, at potentially much lower cost, potentially. And then you have got some controlling software sitting on the server that essentially manages the whole thing. So, instead of one box now, you need at least two boxes.
So that is the result. And that is really a very, very basic, my idea, of what software defined networking is. Because, talking to people I find there is still a lot of confusion about what is it, really what does it do. And there are quite a few different peoples' versions of really what software defined networking is. This is, I think, the dumb down simplest explanation.
So the thing is, along has come an idea, I suppose you could call it a technology, software defined networking, and it is rocking a very large boat; a $20b sales a year boat. If you include all the data centre switches, all the enterprise switches and all the service provider switches and routers out there, it is one hell of a big boat, and big boats can sink. Look at the Titantic. But it is not often it happens.
So really, are the established switch vendors, are they going down a path when they are selling pretty dumb layer two switches with very little added value. And are you going to see a large part of the market go off to other vendors, is that going to happen? Well, I very much doubt it really. All vendors now have a migration story. If they don't have a software defined networking product right now, they certainly have a migration path and a story ahead of it.
And there is great opportunity here to build interim solutions, particularly when you look at very large networks that take a long time, five/ten years more likely, to replace. You need an interim solution. So, you have your solution now. End goal in 10 years or whatever, software defined networking throughout my network. You need an interim solution. What does that mean? You need to buy new equipment. And, what does that mean? Probably your equipment replacement cycles will go down, which for vendors could be very good news of course.
So product replacement could accelerate. So this could actually grow the market, instead of shrink the market. Because, all we need now is a server, with some software, and some dumb layer two switches. I don't think, even though that was my initial thoughts at the beginning of this year that could be a real issue for equipment vendors, I am not so sure it will be.
Will organisations embrace do-it-yourself routing control? The Googles of this world, I am sure they would. Large communication service providers, quite possibly, yes they would. But then, when you get down to a large enterprise or a medium sized data centre, do really people want to do it themselves? So, that's another question we will be asking.
And, of course, as in the title, who is going to deploy it first? And also, add to that, who is going to benefit from it first? So, that is the pitch.
Now I am going to ask the panel to their elevated pitches. It is in the order of your brochure. So, Arpit it is you first. Do you want to come up here, or do you want to do it from there?
Good morning guys. Ian that is a good definition, however, in the spirit of debate, I don't agree. And here's why.
There are effectively three solutions available to customers today. So, what I want to start off with is showing you the three drastic choices.
The first choice is what we are calling overlay hypervisors. These are the VM Ware's of the world, the Microsoft's of the world saying network is a pipe I will manage from the outside. Even in that scenario an extensive layered three network is required, so it is not a dumb layer two switch in the middle. So we need to be aware of that. That is one direction that a bunch of vendors are pushing.
Then there are the legacy vendors that will drag their feet, clearly because they have got the most to lose. A lot of the deployments today with all 1,500 features running in the network are predominantly a factor of 20 years of what we have done.
And then the third choice, which is a pure green field, mostly in the academic university kind of environments, maybe some in urban environments, where there is no incumbency and you can take a more radical approach to SDN.
What I want to lay out is each of these directions has challenges. I think from my perspective, as a former Force Ten employee and now part of Dell; we see limitations of all three. So if a customer chooses an overlay view of the world then you are back to a single vendor hypervisor; I wouldn't say proprietary but you are either VM Ware or Microsoft and if you want to inter-operate you go with gateways. Then there are more complexities in the other part of the network.
The key here is they only address the virtual part of the world. You know there is the physical layer of infrastructure and then there is the V switch or the virtual layer. These guys only address the virtual layer. They do not touch the physical layer, specifically the way the standards are going, VX LAN and VGRE etc. So that's the limitations on the overlay side.
On the legacy side, they are not architected for the new work loads, specifically the ones that require more automation, more east/west traffic, more real time modifications if you may. They are not architected for virtualisation. The concept of a virtual machine moving between servers and between data centres is not something that a legacy network will fathom very easily. So there are big problems here.
Then, if you go with green field, the inter-operability with the existing install base is a challenge. And, of course, there are a whole set of standards that have not yet evolved, specifically towards the higher layers of the stack on SDN, not just the data path, which is really the open flow. So there is a whole set of debates and discussions that happen. It is a small area or a small market where people are trying these things out for specific use cases.
So, from our point of view, as part of Dell, what we want to do is bridge the gap between the past and the future. We want to create the inter-operability with the various hypervisors, both at the physical and the virtual level. Because, both are needed, otherwise you do not get the actual policies and the controls, and the user experience that is needed for full network awareness.
As well as the inter-operability, with a legacy using hybrid switches, which again practically is not a CapEx thing, because silicone today, they are not optimised for open flow, they do contain both legacy as well as the open flow inter-operability. But, most of that focus will be on automation and simplicity. So that with VM movements and things like that we can manage and transfer that.
Here, whether it is a cloud offering with open stack or with any set of controllers that keep coming out, you build on standards. So that's the general direction we are heading as Dell. And I just wanted to set the context in terms of the choices available to the customers and what our approach has been.
So, I'll hand it off to the next colleague.
Thank you. So, it is a dangerous place there, so we have to be careful. I figured out, based on just the three to five minutes, lights don't make too much sense. So I prepared a nice presentation, which we will skip. I just want to give you our perspective of SDN and the market itself.
Just a word which is important, to Enterasys itself, we are focused on the enterprise market. That is important, because SDN can be applied in various flavours to different infrastructures and types of customers. So we at Enterasys, we have 1,000 employees, we focus on the traditional enterprise market, anywhere between 1,000 and 100,000 systems attached to these enterprise infrastructures. So, typically large healthcare, manufacturing and government network infrastructures, and you have to keep that in mind as well.
You also have to keep in mind that from our perspective, from my perspective, SDN is here to stay. So, it is not something that is just following the Gartner hype cycle here and will disappear over time. That is also very important, because a lot of the paradigms and also the goals that you can achieve using SDN are really bringing sustainable value to the enterprise that is important as well.
I also disagree with SDN has been invented by Stamford. It is a very old paradigm. If you look back into the '90s there were a few vendors, even in the Ethernet market already looking at SDN like architectures, including ourselves. At this point in time we were running named cable [trans] systems and we were experimenting with a centralised connection and flow controller for an Ethernet based infrastructure. But, we trashed it, based on scalability challenges, which I will talk about later on.
But also other vendors, like Ipsilon, going down the path of providing MPLS switching capabilities. That is basically also SDN. So from our perspective, from my perspective, SDN is really about providing a programmatic interface into the infrastructure to modify the network infrastructure behaviour and basically delegate the capability of modifying that to other IT systems. So, that's what from our perspective it is all about.
So you want to enable other IT applications, management systems, IT departments to provision services as they need to. And that's a key component here. And it goes beyond automation, which is just the ability to automate basically processes or tasks that you do on an ongoing base, more towards orchestration, which is more, as the name suggests, the orchestration of different IT services including the network infrastructure to quickly deploy new services on the infrastructure, and so enable really an agile business and IT infrastructure at the very end of the day.
Open flow, as far as we are concerned, is one component that could be used underneath. But for example, what open flow is trying to do, like write your own controller, we don't see that for our market.
It is interesting, for service providers, large data centres and operators like Google who want and see themselves as being a key -- would see their IT as a key asset and a differentiator for themselves. For our customers IT is just a mechanism to deliver business services. And that's a clear distinction here.
So, we do see SDN being a very viable approach for carriers, based also on how open flow sees the architecture. We see that as well for very large data centre operators as well. And we do see SDN very valuable for enterprises, but in a different fashion.
So, focusing on the north bound APIs that's very important to us. And in fact, looking back on what we achieved with our architecture today, we provide that programmatic interface today to our customers. So, customers using our management paradigm, where we provide a set of open, typically XML based APIs to provision network services, they are in fact able to achieve up to 50% operational savings. Although that was not our statement, but we get feedback from our customers as they deploy our SDN solutions today, 50% reduction in operational cost is not out of sight, it can be reality, compared to how they did manage and operate their infrastructure in the past.
Last word on that, I'm not quite sure how I am on timing. But from an infrastructure perspective in the enterprise we do see that SDN can be applied to both the access layer to solve certain problems around mobility. But, it can also be applied, as my colleague said before from Dell, inside the enterprise data centre to automate and orchestrate the provisioning of services for virtual machines, for virtual storage and things like that. And that's what we basically do. So we have a single architecture that can be used inside of the enterprise data centre as well as the campus edge to achieve these goals.
That's it from my perspective. And who is next?
Good morning everyone. Thank you all for being here and part of this discussion. My name is Shehzad Merchant and I am with Extreme Networks. Extreme Networks makes Ethernet switch equipment for the data centre and cloud for the enterprise campus and for the carrier backhaul infrastructure as well.
I want to kick this discussion off with a couple of thoughts on why SDN, why the buzz around SDN today? Has something fundamentally changed? Why is everybody talking about SDN? And then, talk a little bit about how we can participate in that.
So, something has changed, clearly there are several new trends, several new inflection points that we find ourselves in today, and these are all relatively recent. Mobility of users, devices, and applications is a relatively recent trend, virtual machine mobility in the data centre, users moving around in the campus or network environment.
Cloud sourcing is a relatively recent trend as well. The very nature of the workforce is changing. Today the workforce has not just employees, it has consultants, contractors, outsourced contractors and they are all first class citizens of the enterprise workforce. And these are all relatively recent trends, but they are causing stresses today that were not there five/ten years ago, in terms of the sheer scale, in terms of the sheer dynamism, in terms of the cost, in terms of the complexity.
This is really why people are talking about a new paradigm, which is, is there a better way to deal with the network infrastructure than used to five or ten years ago? And that's where the whole SDN paradigm comes in.
So, by and large I do agree with some of the things Ian talked about in terms of what is SDN. A couple of additional points, the first one clearly is this notion of separation of control plane and data plane. Yes, centralisation of certain aspects of the control plane. This is important to understand, what we are talking about here is not just taking all of the intelligence out of the switches. But, it is taking elements of the intelligence that you need to centralise to go solve your problem. It is a surgical knife; it is not a peanut butter/jelly knife.
The third key aspect, and we don't talk about this often enough, but this is very critical to the success of SDN is this notion on network abstraction. The example I will give here is that of the android operating system. Today you can have android running on a device from Motorola, Samsung, different type classes of devices, set-top boxes, cell phones. But yet, if I pull up Google Maps and Google Navigation, independent of the device, it functions just the same. That is because of the abstraction that the underlying OS provides. So this notion of abstraction is a critical abstraction making the whole SDN model very successful.
The last piece is around the programmability aspects. Which is, now that you have centralised the intelligence, now that you have provided a certain amount of abstraction, if you can make it programmable then you can break this vendor user dependence model, where a customer always goes back to their vendors and says, I need these problems fixed. Now you can actually [live with] a broader based community that can develop applications, that can solve problems far more quickly than just a single vendor solving those particular problems. So these are all critical aspects of the SDN model.
However in order to deliver this model there is a certain framework required, and that framework starts with what is the N in SDN, which is the network, that does not change.
So the question was asked, does a network become commoditised just with layer two switches, cheap switches, we don't believe that is the case. In fact, SDN only emphasises the fact that the network has to be far more higher performance, higher capacity, lower latency. So there is a fair amount of innovation to be required at the networking layer itself.
The second layer on top, this is the critical layer, which is the network operating system. This is where the APIs come in, this is where the programmability comes in, this is where the network abstraction comes in. And this is where the bulk of the network vendors have to put the investment to go deliver on the promise of software defined networking.
The third layer on top of that is where the action [inaudible] the buzzes around controllers, they are open. Controllers being the area of interest in many peoples' minds. But it is not just open flow. There are other paradigms as well. You can use orchestration platforms like open stack and you can use traditional platforms, and network management platforms for also delivering SDN services. So, all of these are part of your SDN solution.
And lastly the real work is actually going to get done here, which is the applications layer. So, if you want to go solve network virtualisation you will have a set of applications to go solve network virtualisation. If you want to solve your BYOD problem you will have a set of applications that go address things like BYOD in an SDN manner. But that is where all the problems will get solved.
To deliver the promise of SDN you require all four. Not just one of these, not just a combination of these, but all four are required. For a company like Extreme Networks this is exactly where our investment is. We invest in very high performance infrastructure. We have got a fantastic story in terms of programmability, APIs as well as open flow interfaces. We work with multiple open flow controllers providing interfaces into orchestration platforms like open stack. And, we work with traditional network management platforms as well. And on the applications, we are already developing a set of applications for network virtualisation, BYOD identity management.
Just a quick last slide, we recently made several announcements to extend our SDN strategy. We believe we have been in the SDN space for a while, because we have had these paradigms in place. But we are adding open flow capability across our portfolio of switches. We do not see SDN as applicable just to data centre or just to the carrier or just to the enterprise space. We see the benefits of this applying across all these segments. And so we are making available our open flow capabilities across all these segments.
We are also announcing support for open stack, which is another aspect; it is another manifestation of our SDN strategy. Open stack is an orchestration platform and we are bringing the network within the orchestration of our framework as well.
Lastly, the one I want to point out over here, is this notion of [ex kit]. Just like with android, you have a market place for applications. We are launching our own market place for SDN applications, which you can go to a website, download their SDKs available there are APIs available there are applications that are put available on that website. Developers can put their own applications, and we are building this market place out to really take the SDN market to its next level.
So, in summary, for us SDN is not a new space. We have been investing in it for quite a while and we are furthering our SDN investment with some of these new announcements. Thank you.
Hi everybody. My name is Mike Banic from HP from the networking business. I need to stand near the microphone so you can hear me.
So I want to start by addressing what the first question was, that we were given, which was who is going to benefit from SDN. And the answer is simple, it is the market place.
What do we hear from customers? Customers tell us well the big value in SDN is going to be the applications that allow them to do things in a much more simpler, scalable and automated way than they were before. But when we think about the word application, let's just think about what people do in IT today.
Enterprise IT does not write their own applications for the most part. Very, very few companies have the luxury of doing that. HP is a 300,000 plus person organisation, we do write some of our own applications, but most of our clients want to buy complete solutions. That is going to be one of the things that is going to be critical as we see this SDN market develop.
What I want to share with you is what our vision is here around SDN. So I want to start with a model that everybody is going to see a lot more of that has been defined by the Open Networking Forum, this SDN architectural model; infrastructure layer, control layer, application layer. And there are some things that are pretty important when you look at, how do we deliver on the customer's expectation of having a complete solution? Making it simpler for them in a way that scales and that is automated. Because, when we look at where this topic lands on the Gartner hype cycle for communications and networks, it is on the technology trigger. Right now it is forecasted that we are about 18 to 24 months away from people deploying it in some level of scale. Right now we are seeing the early adopters embracing that.
Right now we're seeing the early adopters embracing that. And I'll talk a little bit more about some of our experience with some of those early adopters. But the fundamental thing that has to get done first is that we use a standard to make the network programmable. That standard that everybody's been talking about so far to date is OpenFlow. And that's something that HP and a number of the other people today on the panel have been furthering in the marketplace. And the important thing that does is it gets away from the opaque interfaces that devices have, that opaque interfaces is a vendor's CLI or a vendor's own management app. And then once you do that at the control there, you can create that abstraction that Ian talked about. You can separate the intelligence out of the packet forwarding layer.
But the real value comes in delivering applications, applications that deliver network services. The big topic everybody's focused on so far in the datacentre has been virtualising the network. Well what about doing other things in the network, like automating security or providing other network services like load balancing or [WEM] optimisation that are delivered today through dedicated appliances. And the dedicated appliances themselves present limits in terms of scale.
Now one thing that's also valuable in looking at this, with this layered approach and what are the mandates of each one of these layers is there's a lot of SDN washing that's going on in the market. As a matter of fact I saw a Tweet from somebody on a news story where Oracle bought a company called Xsigo. And everybody was saying it was an SDN acquisition. And the Tweet was a dog dies every time somebody writes that this was an SDN acquisition because it was the furthest thing from it, because it was just software functionality normally performed in a network device, or was a network device functionality implemented in software on an appliance in the rack attaching servers. That's not what SDN is about. It can be one function in an SDN architecture, but it is not what SDN is.
Another thing that SDN is not is just simply providing a set of proprietary programmable interfaces to existing legacy infrastructure. There's somebody who made an announcement around that in June and wasn't all too popular because all it does is move the mess that exists for businesses, whether you're enterprise or service provider, from the problem of programming the CLI, to the problem of programming the APIs and writing your own apps. No business has the ability to do that.
And that mess that's been associated with the command line interface, well there's a neat name that one of Ian's colleagues has given to that. Mark Fabbi calls that human middleware. There's so many people that you have to throw at that problem in order to solve it. And we've got a pretty clean way to articulate well what does that look like. I was working with the folks in HP cloud services because they have to worry about the needs, the provisioning needs for thousands of clients. We have thousands of clients. And every one of them may have one requirement for provisioning a day that may require 20 CLI comments. That would require 3,333 man hours if you had 1,000 clients that put in those requests. And that would require 420 admins. That's untenable. And in a cloud model, one admin is untenable because we want automated self services.
So the other thing that Shehzad said that I agree with that SDN is not, it's not the end of hardware innovation. We will see continued hardware innovation because models for that have been similar in the past. Think about wireless LANs. When wireless LANs became popular and we had lots of access points, what did the market do? What did we as vendors do? We introduced a controller. So you managed hundreds of access points from one place. Did hardware innovation stop at access points? It hasn't. We've seen advances around 802.11 and 802.11ac, 802.11n, 802.11ac, and things continue onward.
We're also going to have a hybrid model. You had the conversation from Arpit about legacy and greenfield. Everybody's going to have a hybrid environment. You're going to still require hardware innovation to support that. Well HP's been driving this for quite a long time.
Ian mentioned the innovations from Stamford around OpenFlow. That actually started as a program called Ethane. And when they started that program, they needed somebody to provide hardware that they could actually program from their software. And that's something we did in 2007. And then we developed our own engineering team to start working on this back in 2008 and we started developing a group of lighthouse customers to figure out how do we operationalize this so we can actually deliver a complete solution for somebody instead of making it their mess? And that was ten in 2009. It grew to 60 the year later. And we then delivered OpenFlow-available software on 16 product lines. It now represents over 10 million ports in the marketplace.
And we've been working with that set of growing lighthouse customers to understand what are the applications that we can build and operationalize and make useful for other clients. We've got one, Indiana University, who's presented at events where they've talked about how they've used our infrastructure. And the open programmable interfaces and some software that we've provided on top of all that so they can build on applications for a self-service interface to researchers so they can form their own virtual private network between locations that they operate in multiple campuses. That's the value of SDN. It unlocks the potential, the business potential of the network by making is simple, scalable and automated. And those are the kinds of additional applications we're going to see across lots of enterprise functions, not just in the datacentre but across campuses in terms of security and across wide area networks in terms of quality service and other services in the network that are delivered with appliances.
Okay. Thank you very much. Charles, you're last.
I am, which is not easy. Everything has been said. So the question was who's going to benefit the most out of SDN. And I think that we need to forget about hardware. We need to forget about the switches. We need to forget about the network. It's about the software. This is really software is the key word in that SDN environment.
Now who's going to benefit the most out of it I think is going to be the cloud people, people trying to set up, as a little bit was explained, workloads on the fly, automatically, without having any - I don't remember how many man hours to program this, and then more complicated, that workload, we want that workload to be mobile. We want to have that database available in the datacentre in Europe but at night move that database over to Asia where it can serve other customers. So having that automatic workload and that mobile workload move seamlessly is very hard.
We're stuck in a networking environment with protocols that were developed in the '60s, '70s, in the DARPA project where the main requirement was your network needs to survive a nuclear explosion, right. So having dynamic workload moving from Asia to Europe to satisfy some customer latency was not part of the protocol that were used, Spanning Tree, OSPF, BGB, all of these ones. So we need to have a new way of doing networking. And this is where software-defined networking has that potential to serve utmost the cloud service provider.
I think the second people who are going to benefit out of this is really the service provider. And for them the potential is absolutely huge. From now on they no longer just provide the pipe, but they have a view on every single flow going on. So if you're smart enough and you have some software that is able to detect fraud detection, security threat, trends in the market. Hey, hold on, that traffic pattern every time of year is recurrent for that sort of business. You can develop some business model that will approach these companies and say well you know what, I can sell you more bandwidth. I can sell you more security. I can sell you - distribute your content slightly different at that time of year because I've noticed in your trends of flows, year over year, that you have that sort of pattern established.
And I take this as an example is what I use often the taxi versus GPS example, where if I take a taxi outside here today to go to the airport, I'll tell the taxi driver please bring me to the airport and based on his knowledge what is the weather conditions, what is the traffic, road construction, what is the best route at this time of day and all that. Based on that information, that taxi driver will select a route over another. Now we have - most of us have GPS in our car, a navigation system. And we take that intelligence outside of the taxi driver's head and brought this to a central point. And say well that central point now has real-time update of traffic flow, has full knowledge of all the construction happening all around, the traffic around Faro and all of that and can advise back the quickest, the fastest route to the airport.
So with taking that control plane, if you want, that intelligence out of taxi driver's head and brought it to a centralised location that has a global view and has a better view. Now what a service provider can do with this, they say well hold on, along the way I can point you out to a restaurant. You're going to miss out of gas, I can point you out to a gas station. You can add some services because you have that information and you have that knowledge.
Finally I think that the enterprises are going to benefit as well from this OpenFlow or this SDN wave specifically in the pod sort of topology. I'm not saying that we're going to replace the entire infrastructure. I think that we're going to be deploying some financial services application or big data application or analytics application that will require dynamic movement of workload and resources within that contained environment. And the better way to do this is to use OpenFlow or using SDN software to address this part while connecting to a legacy infrastructure.
So I hope this is in three to five minutes what I wanted to cover. Thank you.
Thank you very much. And finally but not least we have - I have an advisor. It's Pim Bilderbeek. He's got his own company now called the METIS files. Well why don't you just introduce yourself, Pim?
Yes. Hi. I'll just stay here because it's very dangerous walking [inaudible]. So I'm not going to delve into another definition of [inaudible]. Is it working? Yes. What I think is interesting, I didn’t hear any information about - push it once, okay. Sorry. So I didn't hear any information about, let's say, savings or hard data in terms of what people achieve from software-defined networking. I know I read an interview with Google who says we've built our own stuff and we've been able to go from 30% to 40% utilisation of our network resources to virtually 100%. So I think one of the questions I would ask the panel is is that something that they see themselves as well with the customers that they have, because I think that's very interesting.
Second thing I would say is that I agree with software-defined networking is something for an IT shops that's very sophisticated, that has web-based datacentres, that's scientific or university-based or finance. But your average IT guy might be thinking about, he might have a datacentre, but he might be thinking about I'm not going to build out a datacentre, I'm going to go to the public cloud. So for those guys, software-defined networking is actually not on their roadmap at all. It's about outsourcing stuff. It's about getting infrastructure from those players that themselves have software-defined networking.
So my advice to your average IT shop would be stay informed with these guys. Ask them what they're doing. While I don't think it will impact you very big in the next couple of years. Actually I would say, and maybe the panel would hate me for saying this, maybe these guys should think about good enough networking rather than software-defined networking because if you're thinking about outsourcing stuff anyway, if you're a small or medium-sized IT shop, we're probably worried - you're probably more thinking about maintaining the stuff that you have for a longer lifetime cycle. When you're moving your stuff, you're outsourcing it to the cloud. So that's, in a short nutshell, my position on software-defined networking.
And last but not least, I didn't realise I was sitting here with, I guess, five legacy vendors in terms of software-defined networking.
I agree with Arpit on that one. Yes, on the cost savings piece, that's where eliminating the human middleware generates the cost savings. If you just think about all the people that are necessary to operate a network today, that's where the expense is because these are not cheap individuals in terms of the salaries that they earn. And yet we need more functionality from them. We need them to actually deliver more. And by automating things and simplifying and scaling them, that's when we actually are able to take the five or ten certified and trained people that we have and enable them to do that because they build interfaces that are self service on top of a software-defined network and they create that level of automation, it takes the human being out of the process.
Human beings are the single biggest growth of any cost. There's no Moore's law for human beings, right. We all have computers that are faster than the one we had two years ago and it's the same or cheaper. But all of us have an increase in our income and we have an increase in our intellect and we're able to do more, but that comes at a cost.
And the point you mentioned about Google, Google's in a really unique position because they have a very finite set of applications that they have to deliver at scale. And there's some definitely interesting lessons that we all learn from Google. But one of the things that we've learnt through working with all of our lighthouse customers is the breadth of the applications that they have to work with every day means that they've got a very diverse set of requirements. And so they're being selective. It's almost like which workloads do I virtualise? Which network services actually do I want to automate through software-defined networking and what's the pragmatic path forward? And actually one of the things I learnt from talking to our services organisation is that's a big part of the professional services consulting that they deliver.
So Mike sees saving in people power as a big benefit to software-defined networking. What are other people's thoughts?
So to answer your first question on resource utilisation, it's not about resource utilisation. Being deployed in seven of the top 10 web companies, we get the statistics. Most of the web companies are non-virtualised. They architect their networks to run over 70%, 80% utilisation. So given that scenario, it's fully utilised, fully resourced and they architect it well. If you take the other extreme where an enterprise datacentre is virtualised, well the very fact that [AVM] is moving around creates a lot more traffic. Or if you're running big data or applications like that generates 3X the amount of traffic. So from a resource utilisation it's not that big a deal. What is a big deal is the operational aspects, which is the automation aspects that we just talked about.
Yes. I would tend to agree with that, which is all too often we tend to throw the word SDN and we talk about resource utilisation and simplifying and all the buzzwords in it. But the reality is if you really look at how SDN will eventually get deployed, it's going to be a surgical knife. You're going to pick your specific problem and apply an SDN approach to solve that problem, gain success with it then move to the next one and gain success with it. And so for some people that may be better capacity utilisation. For others it's automation of policies. For some others it'll be addressing challenges associated with BYOD, which is not a capacity utilisation problem at all. For yet others it'll be addressing challenges around network virtualisation, which is addressing issues around multi-tenancy and so on and so forth. And so I think it really depends on what is the problem you're trying to solve and being able to solve that very efficiently rather than just dealing with capacity utilisation.
But will it save money or will it improve services or will it do both or what?
Will it save money? For sure. If you implement it right from an operational perspective there are clear advantages. But you obviously have to also scope your problem and apply the appropriate SDN architecture to it, like, as you mentioned, like Google. That's an exception. It's not what you will typically find out there in the market. Google has a predictable infrastructure, single application or a handful of applications. It's easy. But for a typical enterprise where you have new applications coming in on an ongoing basis and these applications are also reallocated during runtime, it's much harder to find the appropriate architecture. So that's why I also see that these large single app providers, like Google, Salesforce, Facebook, they all just have a single application and a predictable traffic pattern. They will be first adopters followed, as Charles said, by service providers which can get the biggest benefit. And then enterprises, whereby enterprises can benefit from that today, but much differently than Google or the service providers benefit from SDN today. And that's, I think, important to keep in mind.
Okay. So datacentres, service providers and then possibly enterprise. Does anyone disagree with that? Do you think it should be -?
I don't think it has to be in that order at all. I actually think we're going to see - just think about where we are, this is landing on the technology trigger of the life cycle, right? It's going to be - we're going to see the leading implementers be in various different places in the market. Actually I know for a fact from working with the lighthouse customers we have, they represent a cross section of all those industries. They're government entities. They're enterprise businesses and other service providers.
Yes. I would actually completely agree with that. I don't think, if you're looking for a killer app, I don't think you're going to find a single killer app. You're just going to find a bunch of different applications across the different sectors.
I do want to go back to the resource utilisation point because there's something we haven't talked about that I want to draw out, because we did talk about it at breakfast, which is the notion of overlay only as an SDN approach, because when you mentioned utilisation, if somebody uses an overlay to all of a sudden enable workload mobility and fluidity in a datacentre but they planned for the network to be X and then all of a sudden they make these changes, it can have a dramatic impact on how the network is used. And there's this decoupling that exists between this overlay and the physical infrastructure that does cause danger.
I think overlay doesn't work with high utilisation anyway because you lost visibility. So you always have to orchestrate between physical and virtual to provide the appropriate services and highest utilisation and overlay.
Where software-defined network is going to start first, quite often where you see the great benefits that can be achieved with a full software-defined network, the ability to move to that quickly isn't there and therefore it's organisation that have got to move slowly really possibly benefit the most. And so yes, it could be the faster-moving leaner maybe greenfield-type opportunities where we could see it happening sooner.
So also one aspect that we didn't talk about yet is the scale of the problem as well, so depending on where you deploy it you might hit several barriers in terms of scale, managing on the controller level what is the data plane able to do and things like that. And I think that goes back to the deployment model you are going to choose and the environment you are implementing SDN. And so if you have a predictable environment like, again, Google, Facebook, you have a set of flows that you are managing so the number of virtualised instances and slices are obviously manageable. If you go to a service provider, it's much more. And depending on what you're trying to achieve in an enterprise, that can be significantly higher than what you see on a carrier and datacentre side of the house because carriers and datacentre providers just want to provide connectivity and nothing more. But if you want to provide security on a very granular base and do in a per-application base, suddenly the number of flows and connections that you're going to manage are significantly higher.
Just to give you an example, so we are probably the only, not sure yet, but probably the longest term flow-based switch router providers in the market. So our ASICs2 are flow-aware, so we manage flows in our infrastructure. And if you look at what the OpenFlow guys are trying to do with commodity ASICs, there's a magnitude of scale in between. So to give you an example, today's commodity ASICs, there is a port up to 4,000 flows on a per-chip base. Our system today scale to a million flows per chip. And our systems themselves go up to more than 60 million flows per system. So you cannot really centralise that flow management so you have to have a different paradigm here as well.
And to a degree, what the market is talking about on the control plane, you don't really see that on the infrastructure layer being supported by the ASIC development community. So there's a little bit - there's something out of sync at this point in time.
So I'll, if I may real quick, I'll perhaps defer a little bit. I don't think other vendors are implementing 4,000 flows. We've done hundreds of thousands of flows as well. So I think just need to do that research a little better. That's not a problem at all.
But I do want to mention something else that perhaps, since the topic of Google came out, is I think it's worth mentioning that it did take Google a couple of years and a lot of software engineers and system engineers to go make this successful. Most enterprises don't have those kind of resources. And so I think what enterprises are really looking at over here is for solutions that they can deploy, not solutions that they can build.
Yes, because one issue I had, what sort of organisation would want to have own control of software. And you have the large database providers and maybe the communication and service providers will have a go at it or they'd outsource it to someone who'd have a go at it. But beyond that, people still need packaged solutions.
Absolutely. And what we're seeing definitely with our customers at IBM is that a lot of these applications, if I look at SAP or a specific big data analytics, they're looking at a bundle at a closed environment that is optimised for that application and that has storage server networking in there and then OpenFlow can become one of - or software-defined networking can become one of the key elements within that pod or within that cluster to optimise the application performance.
Yes. And maybe we'll see software-defined networking possibly have an impact on the vendor landscape and we might see some change in the vendor landscape. This is, to be honest, from an analyst point of view can be a very boring vendor landscape. You've got about four players controlling about 80% of the market and it makes you want to go to sleep sometimes. So it'd be good if we saw a bit of a shake up perhaps.
But we're running out of time. So I'd like to open it up to any questions that any of the audience might have now. Yes, we have one at the back. Sorry Steve, yes.
Steve Broadhead - Broadband Test Labs
You've just been talking about network management for the last 40 minutes. We had these debates 22 years ago. The only element that makes sense at the moment is actually to reduce the administrative cost, right? And that's purely based around adds and changes. That's what costs in network management because not only does it cost to make the adds and the changes, but that's when problems occur when people try to make changes.
So I think two elements. One either has to be a focus purely on what will actually save money, so adds, changes, and there's nothing new there either, or for it to really, really move forward a step, where we have - we need basically some kind of profiling that takes per user, per application and sub-application and knows exactly what element of the network and the network is LAN, WAN, wireless, mobile, and creates a one-time policy for all of that, is it actually possible?
Yes. If you're looking at that typical profile, you'll see an application will have layer 2 requirement, will have layer 3 routing capability, will have load balancing, perhaps it will have firewalling. And the problem with that sort of topology is that you need to have somebody that will go and physically add these firewall load balancers instead of that topology. And if you want to change this, that's even more work. You need to physically change everything around. Now the possibility of SDN is that you have these appliances hanging on your network. And since you see the flows coming from the server, if now that customer or that application requires load balancing or firewalling, you have a very easy way to take that flow and direct it towards the appliance you want, security appliance or whatever. You no longer need to go physically in the data path, let's say, and connect the firewall in front of the servers you can to protect. You can take and steer these flows towards the right appliance when and as needed. You don't need it any more, you take it off. So that, I think, is a big saving from a management perspective.
Just one or two quick comments because we're a bit short of time.
Real quick, I think what you're really seeing is is there a way to do a single definition multiple enforcement, and centralised definition, localised enforcement. And I think that's the end goal. Certainly that's the direction that everybody would like it to go. I think we'll get there, but it's going to be a slow road. It's going to take time to use the new paradigm to get there. And the age-old adage is very true. You cannot manage what you cannot monitor. And so the first step of that is getting that visibility. So I think step one will be visibility. Second thing will be the analytics from that visibility. And the third thing will be that control and it will go in that order necessarily.
So Steve, I think that you're making a good point about getting everybody to remember about network management, the FCAPS function. What SDN does do though is it goes way beyond that. It allows you to use existing network devices, like a switch, and actually have that switch start to implement packet forwarding decisions between somewhere centralised the intelligence has been put in place to make decisions about things like load balancing, like Charles mentioned. And so you remove the need for a dedicated appliance to do that.
That goes way beyond what a typical management platform does. However, you're making a really important point that these applications and the changes that they're imposing upon the underlying infrastructure need to be linked into management. The legacy vendor that's created human middleware, this mess we’ve got, has got 36 management applications just for routine, switching and wireless. And management's been a huge part of HP strategy in terms of providing not just management, one tool for all of our stuff, but we support all these guys too with a single pane of glass. And so as you make these intelligence decisions at the SDN application and then you program the network from the controller, if it thereby requires config changes in the network, you can, through those programmable interfaces, tell the management app, hey, there's stuff that you need to physically change in the configured advice and the monitoring that Shehzad mentioned that is important so you have that closed loop gets fed back from the management app that's doing that.
So I guess this is a call to action for everybody who's in the media and the analyst business is that's one thing that's an important piece of advice to clients is that's what they need to look for. That's part of their criteria.
Yes. Actually it's really moving away from network management to managing applications and users on the network, using outside of the network paradigm IT applications to do so. So traditional network management doesn't really get you anywhere.
Steve Broadhead – Broadband Test Labs
There's a fundamental difference between what network management has become and what it was set out to do. And what it set out to do in 1989 when I looked at my first network management product at Cabletron was exactly what SDN is supposed to do now, it's just that it didn't happen. And even from a HP perspective with OpenView, the plan was we did things like automation, pre-programming of multi vendor devices, etc. So it's very much a case of what I'm trying to say is this is what network management was supposed to be, it just never happened. So will it happen this time?
Who says it's going to happen this time? You'll have to wait and see.
We will get closer, for sure.
There was one more question, I believe, at the back.
Bob Anderson – Capacity Magazine
Bob Anderson, Capacity Magazine. I do have a question, but first a comment. We've had quite a few contradictory statements from the panel members, like the standard is very important, we don't need a standard. The infrastructure is going to go away, no, the infrastructure is going to be here for 10, 20 years. When it'll eventually be implemented, no, it's already been implemented. So I think when this kind of talk goes on, the market gets very, very confused. And I have a cliché of my own. A confused market doesn't buy in weights.
But anyway, my question is I wrote about this about a year ago. And one of the things I thought - I'm just a writer, I'm not an expert - is if you've, say, got three datacentres scattered around the world, this is a great concept because you just create your own private network and you connect up these switches through carrier Ethernet and there you are. And can it actually be that simple? That's the question. Can it be that simple?
Yes, it's not, because each of those datacentres has multiple networks inside it, because they're all supporting, well, probably a lot of virtual workloads. And you need a virtual private network for each one of them. And as you start to move those workloads around, that one single network needs to have secure separation of the traffic supporting each of those virtual datacentres inside the physical one. So you need to have a way to carve out virtual multitenant networks that provide for things like layer2 virtual machine mobility across that global network. It's just having one network connected between them with Ethernet and the datacentre and carrier Ethernet is not itself sufficient.
Yes. I would actually agree with Mike over that. But I'd add perhaps a little bit to that, which is again, there are two sides, as in the last panel, there are two sides of the coin over here. It's really - it's complex from the network IT administrator because you're trying to solve all these different things. So the end user it can be that simple, and I think that's the end goal. For me as an end user, if I'm trying to access a certain set of applications, whether it's in datacentre 1 or datacentre 2 or datacentre 3, I don't really care and I just get access to my applications. So the end user experience will be that simple.
That's because that end user is one of - he's in that virtual private [land]. He doesn't think about the other people.
And to your first question on standards or not, the thing - I think we can go round the table - but the thing we agree is SDN has one small element called OpenFlow, standardised between the control and the data plane, it's on 1.01.1, we all agree with that. I think where it's missing is on the [northbound] side. There is no standardisation between the controller and the orchestration automation and management. So there's work to be done there. That's where you might be getting conflicting perceptions. But just to lay the scene out.
And the on the second conflicting thing you pointed out on the infrastructure or network important or not, you can see, when I presented, there are three approaches. There's an overlay approach, there's a greenfield approach and there's a legacy approach. And there is no one answer to those approaches. And hence you will see early adoption you will see three to five years out and you will see different approaches coming from different vendors. That's just - any technology hype cycle, there are early adopters with different approaches using partial standardisation. This is no different.
Okay. Well I think there's one thing, one new question you can ask the vendors going forward, and that's how many flows can your system manage, which is a new way to measure how good their products are. But I'd like to thank the panel very much. They've done great work. Thank you very much. And please show them your appreciation. Thank you.