 Hi, this is Stu Miniman here with SiliconANGLE TVs live continuous coverage of HP Discover here in Las Vegas. I'm with wikibond.org, giving wall to wall coverage on all the trends, industry, discussions, and infrastructure. And joining me today is Sar Goli from HP Networking, is the CTO of the group. Sar, welcome to theCUBE. Thanks Stu, great to be here. So your first time on theCUBE, I believe. I think so. What we really try to do here, is try to find the smartest people we can find and really try to extract the signal from the noise. And there's a lot of interesting discussions going on in networking, kind of towards the top of the list on the buzz factor these days, is software defined networks or SDN. Your executive, Dave Donatelli, this morning said, HP is looking to transform the networking industry along with others and sees SDN and OpenFlow as one of those transformational technologies. So, as you and I were talking off camera, SDN is one of those things that most enterprise customers really don't really understand it yet. And it's really kind of new. So, can you set up for us a little bit, is what is this trend and what are we looking at? Sure, no, that's a great question. And I think SDN is definitely one of these subjects that a lot of people are talking about. But different people have different understanding of what the SDN is, and so then they have different understanding of what it's going to do. And I think what I can do a bit is try to simplify it a bit in the way we look at it and how we sort of approach the issue. First of all, I think what's important to understand is what is SDN? And a lot of people think, oh, SDN must mean network virtualization. SDN must be this. SDN means you're doing everything in software, SDN. Yeah. A lot of people said we're going to do for networking what VMware did for servers, right? So that's not it? Well, that's network virtualization, which is enabled by SDN. Okay. That's an application of an SDN. But let me sort of try to sort of set it up for you. So, look, the way we look at it as SDN is that you got to have three things that three key elements are important for an SDN. The first element in an SDN is that you want to be able to manipulate the forwarding of packets and apply policy. Okay, that's straightforward enough. The next thing you want to do is you want to do that, the first element, across a large scale of devices in a dynamic and coordinated fashion. And then the third key element is you want it to be programmable. So if you have all those three elements, now you have an SDN. Now, why is that interesting? Now, the reason it's interesting is because if you look at those factors, well, you know, Switzerland's already forward packets and you know, apply policy. And you can have network management systems that coordinate or at least configure devices. But what you're missing is the ability to do unique things and that's where programmable comes in. So, you know, historically in the last 10 years or so, if in a network you want to do something unique, some unique behavior related to the network ID or so forth, something beyond your standard ACL or standard policy, you usually have to have the dedicated hardware do that. Maybe you have an ADC, maybe you have a knack box and so forth. Then what SDN, the promise of SDN is no, now you can use your regular hardware to do this. Now, initially it says, okay, well, I need less hardware or I need less specialized hardware. But when you start to really think about it, now I have programmable access and a coordinated fashion across a multitude of capabilities at the edge of my network. And now, therefore, I can look at my network as a whole as opposed to just a bunch of separate elements. Now, once you have that capability and you can be programmable, I mean, the programmable part is very important because if it's not programmable, then you can't really do anything exciting with it. So, once you have that capability, then you say, okay, now what can I do with it? Network virtualization, which is what everyone's talking about and that's part of what we're doing was our VAN module is a network virtualization solution that leverages the capabilities of SDN because in order to do network virtualization you need to have those capabilities. You need to impact how you forward packets in a unique fashion. You need to coordinate that across multiple devices, right? And it has to be programmable, i.e. you're doing certain packet forwarding or certain policy that isn't normally programmed within the switch. However, there's lots of other things you can do with SDNs as well. A lot of people, you talk about the enterprise, some of the earlier applications that people are doing with SDN is they're doing some unique policy kind of stuff, which I would call glorified knack. But unlike maybe historical knack which kept everybody off the network, here they can program special rules so that when you get on your switch, the switch looks at it and says the payment device, I'll do different things, set up a different programming and eventually I can get a device in the network. Now you can do all that on your switch with a controller without having a separate knack device. Another interesting application for SDN that we see from service providers, for example, is what we call sort of a cut-through behavior where a lot of service providers they're running a lot of their streaming, for example, their video streams, through a lot of firewalls and IPSs and so forth. And what they would like to do is once the stream gets going, they already know what the source is, they're already validated, they don't want to do it for the entire movie. So all they want is really to do a simple reroute once the stream gets going. That may seem trivial, but today if you want to do that, there is no standardized programming interface at a high level primitive to do that. So you could use SDN for that. So, Sar, I wonder if we can just step back for a second. If we look at trends, networking, it seems even kind of simple transitions take a while. I think back, 10 gigabit ethernet took almost a decade from when the standard was ratified to when most enterprises were rolling it out in more than just kind of certain environments. I think today, if I remember right, it's actually IPv6 day. That's right, it's here. I think it was 13 years ago, the first time I talked about IPv6 and now it's kind of real. So we're talking usually decades for this networking to take. So my question to you is, SDN is this, because this is more than just a speed upgrade, and I mean it's complicated to do the cabling and everything that goes into 10 gig, but SDN seems like it's a big ecosystem, very much a thought change. Are we year one to 10 year journey or where do we think this goes? Well, I mean, you raise a very good point and what I like to talk about people about things, while people think there's a revolution going on, it's actually evolution, because there's installed base, nobody starts from zero and people need to run their business. I think what actually drives the speed of innovation or the speed of the adoption of innovation is need. And that's why you can see, for example, while we were trying to push a gig from 10 100 into the enterprise, maybe people didn't need it to do desktop and so the vendors were pushing it, but there wasn't a big need. However, 10 gig is going pretty fast now because there's this big need in the data center. So the same goes with SDN. I think some of the unique applications people are doing can be applied on existing boxes. For example, boxes like ours that already export things like OpenFlow is one of the enablers for SDN. And so you're going to see people start to deploy applications that leverage SDN. One of the nice things of things like OpenFlow is that it co-exists with existing systems. You don't have to throw out what you have. You can run an overlay, you can have part of your system run an SDN and the rest of your system run your normal thing. This is what we call a hybrid mode where your normal switch does what it wants and then you can program on top of that. I think we're going to start seeing that, there are people doing that, but definitely we're at the beginning of a long evolution. But I think again it's not one warning people are going to say let's do that. People are going to start utilizing the ready universities and other people utilizing it where they need it for a kind of NAC behavior. Some data centers using it for network visualization. Some service providers are experimenting on how to use it for cut through. And you're going to start seeing that but what will probably be the prevalent use model in the next few years is sort of hybrid environments where you're using some element of SDN to do something you couldn't do otherwise but the rest of your network is running business as usual. No, so sorry, I love the discussion, it's always right. Is this evolution or revolution or somewhere in between? It's not a binary function, some things are quite radical and while new architectures, other things are kind of moving the needle. And software and networking isn't new. I mean I look at Juniper and I look at Arista and they've been doing software based configurability and when I got to talk to you at Interop in New York City earlier this year I was pleasantly surprised to understand that HP has actually been working with OpenFlow for at least three years and all your switches are OpenFlow enabled so can you tell us how long have you guys been on this journey and what's the checkpoint we're at? Well the nice thing for us about OpenFlow is that we actually when OpenFlow was started in Stanford about four or five years ago they needed somebody to partner with to work on developing it and they were working with HP Labs and HP and so we partnered with them at it and actually the first implementations of OpenFlow and hardware were on HP switches. And so we've really been on this OpenFlow journey for over four years now. And so and we've been experimenting that as universities have been experimenting with OpenFlow before people were talking about it and so forth. We've been in the middle of all that and seeing what works, what doesn't work, what gets better and so on. So we've really been doing this for a very long time. I think the thing that's really interesting about SDNs relative so I agree with you 100%. SDN is not the first time software has been used in networking. Networking is software by definition. But the fact that you have standardized interfaces like OpenFlow, the fact that we maybe define primitives on top of control planes that give you a standardized interface that's really what gets people excited because when you get away from some of these proprietary things you usually end up with a lot more innovation. And I think that's what people are getting excited about. Okay, so the second dig a little deeper on your OpenFlow, I've talked to a number of the industry watchers and people that know HP really well and they like the leadership that HP's shown on OpenFlow. And the question kind of universally is what about the controller? Are you guys going to be working with the Naciris of the world or can we expect to see something from HP on the controller space? So first of all I want to just highlight it. I think we talked about this before is that there is SDN, OpenFlow is not SDN, OpenFlow can be used for SDN. And as we talked about our van right now it utilizes some versions of SDN, some of it leverages OpenFlow, some of it leverages other things. So OpenFlow is not the start and end of all SDN architectures. I think the higher level point of your question is where do we fit in terms of our SDN plans? And I think at a high level I would say we intend to be heavily involved in the control plane. Whether that's a controller or other aspects, today we have parts of IMC that are in the control plane. So while as HP, we historically are very good at partnering with people to give solutions to our customers and we will keep that in terms of providing open interfaces so if customers choose to do certain things with partners we will be supportive of it. We definitely have some distinct plans on the control plane and stay tuned as they say. One of the things that would highlight is that when you look at some of these problem domains especially in a data center, a campus is very network centric. But in the data center really when you think about this control it's really controlling the fabric and the fabric starts in the server, includes storage. And so when you talk about a control plane there it's not just controlling the switches. And when we look at the problem where we look at solutions to the problem we talk to customers they're interested in, okay how do I simplify my configuration automated to roll out applications. They don't care about the network or the server, the storage. And so when we look at that we look at a greater at a wider view than some people. And so when we come up with solutions in that area you should expect that they would go beyond the network. Okay, great. And when we look at SDN at a broader standpoint is VAN, is that HP's strategy or do we expect to see kind of a broader HP? Do we get an HP branded version of SDN? Cisco often comes out with their marketing term that they super glue with it. And some people like to call SDN the Cisco killer but where's HP going to fit again? Again I think it comes back to me SDN is a method. And then there are implementations. VAN is an implementation of network virtualization using SDN concepts. Now that's a mouseful. But and when we talk a lot about the control plane you're going to see things from HP that are going to leverage SDN capabilities. Now one of the things that's also important about SDN and I think I want to talk to you briefly about is there's sort of three different ways to consume sort of SDN capabilities, right? One model is and that usually fits people who are doing their own thing like let's say an Amazon or Google or so forth. They want to, they might want the hardware from you maybe they build their own hardware that supports open flow and then they want to build their own controller and their own applications and they have thousands of programmers they want to do their own thing, their own ecosystem. Then you have people like universities maybe some larger customers who would like to get the switches from us as well as the control plane with some high level primitives that they can then program and different things on. And then there's third level customers who would like the benefit of all these things but they don't actually want to program anything. And so I think this is the areas that are, so when you look at the van that's more on the left side of that. We have an application that leverages SDN that's network visualization that provides it all built into customers to use. They don't have to program and so forth. However, we're also working on solutions especially for the cloud kind of guys where we'll give you a lot more programmability. One of the big things that's being discussed right now is okay what level programmability do you want? They don't want to program packet forwarding but they want to have primitive so they can come up with their own network applications. So yeah, really interesting the way you put that out because we talked for the enterprise, what do I need to do? And I thought Ethan Banks for packet pushers just put out a recent article and he said what really need to do is have network administrators stop doing CLI. And service providers, they need to be able to program it but when I look at the average enterprise data center we want it simple. Yeah, they might need to choose their profile but we're not going to take these guys off of CLI and then say okay, go program all of these networks. So for the enterprise market, what's your advice to the network administrator? What should they be doing with their education and where do you see those jobs over the next five plus years? Sure, well I think what you hit a spot on in terms of CLI, I think people are going to be, they're still going to be doing a lot of logical activity but it's going to be done at a higher level. And I think they should be aware of virtualization, they should be aware of automation things, there's all kinds of new tools for automation that are going to be leveraged that are, they started off in the server world but they're going to be leveraged in other places and so they should really come up to speed in those concepts, understand virtualization, understand automation mechanisms, understand some of these automation languages because if you look at the cloud and then people in the cloud know this but the cloud is all about automation. You can't scale, you can't get any benefit of the cloud if you don't automate things to the level where you're really dealing with pools of resources and you're not programming every resource on the hardware. And so people are going to be going, someone who's today maybe running a bunch of scripts is going to move on to Vanessa and where he's more defining the logical thing. So their knowledge of networking, their knowledge of what's important is still going to be really, really important but they'll be applying that knowledge, the tools that are operating at a much higher level and so they could, they should stay up to speed on all their knowledge in terms of how these things work but in terms of how they're going to use it, they need to be up to speed on automation ideas and so forth. All right. So, Sarr, we really appreciate you coming in here, sharing your knowledge. I was excited, we got through the whole thing and I don't think open really came up. I understand open and flexible is, you know, core to the network standpoint, I kind of beat on sometimes, we don't want to go on that buzzword too much but, you know, early in open flow in SDN, look forward to watching this space, something we definitely think's a hot trend and HP is, you know, well positioned with its partner ecosystem to move there. So thank you for joining us on theCUBE. This is Stu Miniman with wikibon.org and we will be right back after this brief break.