>> Okay great. So we are here today with Guido Appenzeller. Guido received his PhD in computer science from Stanford in, in 2005. And he spent a lot of time while he was at Stanford both during and after his PhD, working on various problems in computer networking. He was very prominent there in the emergence of, of the openflow protocol. He was for quite some time managing and, and helping run the clean slate program at, at Stanford out of which SDN and openflow emerged. >> [CROSSTALK]. >> Since, since then he's a, he he's a, founder, he's a co-founder and CEO of Big Switch. Since about april 2010. And and he's been quite involved in the development of a number of SDN related products, including an SDN controller as, as part of his, his work with Big Switch. So, we're going to talk to Guido today about SDN controllers, about SDN in the enterprise and, and, and network virtualization in the enterprise. So thanks a lot for, for spending the time with us, Guido. >> Thanks for having me Nick, appreciate it. >> Great. So I thought we could basically first start talking about enterprise networks. So in particular, what do you think are the big met, network management challenges in, in enterprise networks, and what do you think the role is of, of SDN in, in helping solve some of those challenges? One of the things too, is, is SDN has of course taken a big foothold in, in data center networks. But, but you know, of course we'd like to, you know, we're starting to see SDN get deployed in, in enterprises, you know, Big Switch has been, been very involved in that. What are the different challenges in deployment of SDN in the enterprise that, that, that are, that are different from SDN in say the data center? >> Sure. So let's see. So, currently, I mean, when, when we talk about the, the enterprise, we typically mean the enterprise data center, right? You know, enterprise is two big segments, the networking desk campus and there's, there's the data center. So if you look at an enterprise data center today. You know the, the, we've seen over the past 15 years huge advances in how we manage compute, how we manage servers, right. And during the same time, hardly anything has changed in how we manage the network. You go way back, 15 years ago, if you had a server, now you would rack and stack the server, plug it with a serial cable. You know, insert a CD and install Linux on it and then hand it off to your house team, or maybe install Windows. And you know, today that has completely changed. Today, I have servers. I do them automatic way. We have PC booting installs, some kind of virtualization solution on them, you know, either close sourced VMWare or open source, you know, KVM or, or Zen. And, you know, once that system is up and running, it doesn't mean these resources sit there, the resource pool, and when people actually want to do something with them they come in, they reserve resources, right. And, and that has really completely changed how, how, you know, service can be administered. You know, if you look at the numbers, the numbers of how many servers a single administrator can administer has gone up by about a factor of five, over the past couple of years. On the networking side, nothing has happened, right. In, [INAUDIBLE] I logged in via telnet into a switch. >> Right. >> Configure the switch with like, you know, line by line you know, commands. And today, I'm using SSH to log into the switch. And I'm using those very same commands, right? It's a 100% manual process, there's no automation, the number of administrators that I need per networking equipment has basically stayed flat, there's no change. And the, so that the net result of that is that today you know, the operational expense for running a network and enterprise data center is a disproportionate amount of, of the, of the overall cost. You have that, you know they have the people who have done this for a very long time, they're still using the same processes. So it's a huge pain right. If you're in a classic enterprise, you're at [INAUDIBLE] that's probably not going to go up much at the moment and it's probably going to be about flat. And you know, physically having bigger and bigger demands from your applications saying hey I can go to Amazon and sign up for a virtual machine with a couple of clicks. But you internally, you're you know, your transfer pricing has stayed the same over the past couple of years, and takes two weeks to provision this virtual machine with the network. >> Right. >> A huge, huge challenge for our, for your typical CIO. >> I see. Yeah, so, so, so, it's, yeah I guess like the thing that STN offers in that case is basically the ability to sort of view the network as sort of like a logical pool of resources and, and so forth. so, are there, I mean, are we there yet? Like, is it you know, do, does SDN, obviously, it's a tool that helps you basically, you know, potentially see, see the network as a logical pool of resources. But, do we have all the, all the, sort of applications and, and you know, things talking to the controller that make that possible yet? >> You know, it's early days, right. Right now, you know, the number of actual deployed SDN systems is still very small. You know, it tends to be the larger, very innovative companies that do it. In certain areas now, we have solutions with SDN that, you know, in my arguably entirely biased opinion. You know, are vastly superior of what we can do with classic networks. >> Yeah. >> Let me try to explain a little bit how they are different and then so why SDN matters here, right. In a classic network, we're basically, all the, the state is distributed all over the network and, you know, configuration is done in a distributed way. It's actually very difficult to treat the network as a resource pool. Right, because sort of managing these resources. >> Right. >> Allocating these resources, requires some sort of central entity. You can, can try to do it with a distributed protocol, but in practice you know, I think we've learned that that doesn't work particularly well. >> Right. >> And I mean the other thing is, I think we've made huge advances in building large, centralized systems. And when, I mean centralized, I mean logically centralized, right. Nobody in their right mind would actually use a single, single server to control the entire data center. I give [UNKNOWN] many controllers, but they mesh together as logically one controller. so, you know today you have solutions from, from companies like ours, that basically, allow you to, to take in that work, right. Use SDN, because even the network powers up all the switches connect up to the SDN controller, right. We did the [UNKNOWN] recently, where actually the switch boots its switch from [UNKNOWN] the SDN controller. >> I see, yeah. >> The switch is bare metal. It just you know, fetches the software and starts off. And you know, and then basically all the managment, all the administration's done on the controller, right. And from a customer's point of view this is great, I mean, I recently talked to a, a large bank in, in New York about their requirements for this type of solution. They said, they said, pretty much quote, Guido, if there's more than ten CLI commands on the switch, you're doing it wrong, right. >> [INAUDIBLE] >> We want everything in a central place. It makes a ton of sense. And then basically, you know, once you have all this aggregated in a single place where it can manage its resources in one place. You can then easily create interfaces between the SDN controller and for example, a cloud provisioning system, something like openstack. Where, for example, if a user goes to open stack and says, look, I need a new application, right, then automatically we'll create a virtual network that goes along with this application. So this application can't talk to another application [INAUDIBLE]. >> That to me seems like really exciting is where, where it kind of you know, we, openflow started as kind of a way of, of, of managing, managing switches and routers. Now we're talking about SDN in terms of like managing network services, and you know, you talk about a pool of resources, it's not just flow table entries, it's. >> Not at all. >> You know, cloud resources and so forth, and it seems like there's a, there's definitely like a lot of challenges and opportunities. >> So the network, so there's this [INAUDIBLE] point, the software defined data center, right. This idea that, that really, I have a data center which is a big resource pool and then I use an API to tell the data center what I want to do with those resources. And you think of a memory manager for RAM, right, we now want to have the same thing but at the data center scale. >> Uh-huh. >> And if you look at it that way, right, the network is a unbelievably critical piece because it's special use to stitch everything together, right. I need to be able to configure my firewall over there, and then to configure my service over there, my storage over there, then to make sure that everything connects, and you know, the isolation domains are properly set up. Typically the network is the central piece, so it's, it's a very important problem to solve. >> Yeah, that makes sense. You mentioned a little bit about, you know, what's going on in, in, in industry, and, and, and sort of like with your, with your company, some of the things that people are, are talking about with SDN. But, but also like you've been involved in, in SDN essentially since the early days. I mean, basically, right from the beginning with, with you know, right from the beginning of Openflow, with, with the clean slate lab at Stanford. And so you have a kind of unique experience and that you spent a bunch of time in, at a university and academia working on, on, on SDN type stuff and then, now, you've, you've also been in, in industry doing it in. I was wondering if you could kind of compare and contrast your experience, you know what, what it was like kind of doing research on, you know, SDN and Openflow at, at a university versus now you sort of working in, in, in, in on a, you know, on your own start up, doing this type of you know solving these problems. And what's been your experience and, you know, for people who are in, in, in roles and in different places, like what do you the right things are for, for people in industry to be working on? What do you think the role of, of you know, researchers and academics are? I'm wondering if you could talk a little bit about that? >> Sure. You know, it's, it's, both places are great and both places are very different, right. If you're, you know, if you're in academia that really gives you an opportunity to, you know, ask more fundamental questions, take a big step back, right, and ask, what can we really do to, to fundamentally [INAUDIBLE]. >> Right. >> What it is, by doing, doing incremental you know, improvements in academia I think is sort of not worth it, right. You want to ask the question okay, if we have really different paradigm here, if we have a really big problem which nobody knows how to solve, how can we tackle that, right? Let's, let's be disruptive. Now, and the good news is, you can visibly you, you know I'm, I'm a, I'm a systems researcher so I'm entirely biased here, I think anything you should do in academia should actually build a working system that demonstrates that it works, right. Because that's the way the research is being done which, at the end of the day just isn't all that all that exciting, because it doesn't work in practice. Let, once you have a, say a quality demo right? Something that shows look, this is practically feasible, right here, we can, you know, touch it and see if I. Then to some degree it's mission accomplished, right? I mean you further knowledge, you've taken this to the next step. And, you know, in industry first of all your focus tends to be much more short term., right. You know, you raise money for a start up. You know, you currently have a year and a half of runway. You know, we currently have a little more, but, but it's, you know, typically you are saying okay, which milestones do I have to hit in this period of time in order to get to the next, next trench, right. And these milestones are, you know, typically a lot more mundane, right. You have the rough idea of what you want to build hopefully already in your head. But you know you have the very focused on things like quality, right. If you're building a network for a bank, you know, this network can't go down, right. You have to have you know, several nines or many nines up time >> Right. >> Which is very different from academia. Academia probably you know adopt one of uptime is perfectly fine it's enough to to do your demo at the next conference. You know but, but so, so you spend a lot more time on your know, lot of QA. Right, you know probably, you know, depending how you are on your engineering anywhere between one third and two thirds of your time is spent on testing, right. Which you know that, that's very, very different. And you know, the, the problem is sort of more incremental. There's a lot more problems around just integration with external services, so many of the things we do is like you know, one of our, one, a major new feature released [UNKNOWN] was [UNKNOWN] which is an access control mechanism for administrators, right? >> Right, right. >> That's something which academically is not very interesting, but, but if you're an enterprise running this, it's absolutely critical. >> Right, right. >> Type of challenges change. I mean, I think, I, I'm personally, I'm a huge believer that, that the, the best possible thing you can do is go back and forth between the two. Because you know, having been in, in, in industry really helps you understand, what are the hard problems, you know, that people are trying to solve, right. It's, it's really helps you focus, right, to make sure you don't, you don't go down a direction that you know, at the end of the day you know, is, is academically just frankly mankind you know, doesn't really need it. >> Right. [LAUGH] >> On the other hand you know, if, if you are purely in industry you often stop seeing the big picture really, you know, what are the, the really big letters here, what are the big mega trends about? So, go back and forth. >> Yeah, yeah, that's, that's interesting. May, maybe we'll see you see you back in academia at some point then. >> Maybe. [LAUGH] >> Yeah. So I wanted to ask a little bit about SDN controllers. Because certainly your company has one, in, in the course, actually we're, we're covering a few, you know, people will see, will have some exposure to pox and, and flood lights and, and I talk a little bit about [UNKNOWN] as well. But you know, it's, it's like impossible even to cover in a course like all controllers that are out there right now and, and it's like there are, there're almost too many controllers to count. And why are there so many controllers and, you know, in your sort of exposure to the, at least, you know, the few that you might know about. You, what are the, you know, how, what's the difference between these controllers? And how would you pick one versus the other, >> I think it really depends what, what you want to do with the controller, right. If you look at you know when we started we looked at a different open source controllers, you know then, you know, started developing floodlight, which is actually based on the Beacon code from Stanford originally. You know, when it comes to picking control I think it really depends what you want to do. If you're looking for something to, to play around with just to get an idea of you know, how this thing works, probably going for a very simple, very lightweight one is a good choice right. You know, when Floodlight, the controller we're building is actually the same code that sits at the core of our product. Right, there's a ton of things around it right, enterprise ready Floodlight is, its not something you would ever deploy anywhere for, for production, right. But, but you basically the core engine is the same thing. So its, its told that it is very well tested. You know that's, that's very, very reliable. You know very performant, and you know if you want to build an app on top of it that's actually, you know, so really production quality, then I think it's a great choice. You know, the, how to pick a controller, you know, I think you have the usual suspects, right? >> Mm-hm. >> You know, I think we can claim that by, by number of mailing list posts, the number of downloads, we're doing pretty well at the moment. >> Right. >> You know, we're about 2x or 3x ahead of the, the closest competitor with flood lights. There, there's a nice community around it, you know, which also sometimes matters because that means there's, there's tools available for you know, this, there's extra packages available for it. And you know, we as a company will continue to invest there. >> Mm-hm, mm-hm. In terms of just, you know, your company also has like an open source, floodlight, and of course, you sell an SDN controller as well. So, what are the, what are the differences there, I mean, how would you, how would you sort of characterized the difference between your open source controller, and the one that you're actually trying to sell as a product. >> So they, they're very different piece. You know, it's probably you know, a factor of four or five in code size. The Flood lights is essentially I think of as the engine, right? It basically has the, the basic event looks that, that mask the communication to, to the switches. You know, it has the basic abstractions. You know, so how do we think of the network in terms of hosts, and links and so on, right. And you know, it does some basic things such as topology discovery, you know, sort of simple forwarding. and, you know, [UNKNOWN] has the, you know, all the infrastructure on top of it that allows you to build apps on top of it. You know, our enterprise controller has a lot more, I mean, first of all you know, Floodlight's a single, single entity with, you know, right now usually no persistent storage underneath. Right? The enterprise controller always layers a database underneath, right. >> Mm-hm. >> And it's, it's usually, well not usually, it's always deployed you know, it, as multi node system, where basically we have multiple nodes, where one goes down, you fail over to the other one. >> I see, yeah. >> And you know that you know it, it has a CLI, it has a user interface, you know it has you know, a lot more sophisticated affording logic for certain specialized cases, where you need it. You know that has apps on top, right. No customer, so far has just bought a SDN controller. >> Right. Right. >> We buy a SDN controller with something on top, that actually helps them solve a problem. Like, for example network virtualization or you know, [UNKNOWN] or [UNKNOWN] software. >> Right. >> And so, and, typically, so, so for example, you know, the network virtualization, and I'd have to run the numbers. My guess is it has more lines of code than, than floodlight probably by a factor of two or so. So there's, you know, you're sort of seeing the tip of the iceberg. To really get this thing running enterprise there's a lot underneath. >> Yeah, yeah, that's, it, it, that's interesting. So, in some sense the, the, the open source controller that you have, I mean. It's, it's kind of one way to build community around you know, developing the, the types of apps that might sit on top of, of a Floodlight controller through a Northbound API. >> Right. >> But, but, but then, you know, the, the, the, the commercial product that you guys have, basically you could imagine it sort of a, almost a, you know, an ecosystem that sits with, with Floodlight as, as the central engine of that. >> Yeah, exactly. >> I see, yeah. So I guess that, that, that raises another question, which is certainly that, that the question of northbound APIs I mean certainly as you, as you pointed out, no one just buys a controller, they want, they want, they want it to, they want to buy a solution. >> They want to do something with it. >> Yeah. And and that of course requires a way of talking to the controller through some you know, some northbound API. I, I, I wonder in terms of you know, in terms of just the applications that, that you are all developing and so forth, you know no, no dominant northbound API has, has emerged and you know, theres I guess you know, certainly no standard we're, we're very far from that. But I mean, I, I wonder if, in your experience and exposure to different types of applications that people want to build on SDN and so forth. Do you think that different types of applications will need different northbound APIs, or different APIs to the controller? Do you see the emergence of, like, a common API? For example like, you could write many, many different types of applications that all talk to floodlight through the same, same API. Or do you think the financial services people are going to need something totally different than you know, the people building security applications, or traffic load balancers, or what have you. >> So, you know, I think at, at this point. I don't think we're ready to standardize in a single northbound API, and that's frankly because we're still figuring out what the right abstractions are, right. That being said, let me try to provide a little bit of sort of texture of what the different pieces are. You know, that we're seen. Now, and so first of all, there's different Northbound APIs. There's, if you take a bare bones controller engine like Floodlight, right, then a Northbound API is typically at the level of, here's a packet, you know, and here's a flow entry. maybe, you know, here's a host or a link, right. That's being tracked. But they're still fairly low level ideas. If you look at, for example, our, our network virtualization solutions, those APIs right, which because of the high level northbound APIs they typically think about, think at a level, they still have the notion of a host, right. But it's actually a different notion from what floodlight has, because floodlight sometimes can't really tell, is it the same host, or is it just duplicate MAC address? and, you know, the, the, they also have notions of, for example, of a virtual network, right. >> Right. >> Or circuit, right, firewall and, and, the, so your much, much higher level abstractions that, you know, that, that, that we're using. And then you can go even one level higher which, you know, if you, you look, for example, at or the, openstack quantum API. Which essentially is also an API for, for you know, not specifically targeted for SDN but, but you know, for basically software that runs networks to talk to applications, right. That has even higher level abstractions. Right. [UNKNOWN] and things like that. So there, there's not really one northbound API. There's multiple levels here that, that have, that have different semantics. You know, at this point, I think, there is a little, we're starting to see a little bit of a standard emerge, right. You know, because I think, if you look at the, the early Stanford controllers which were the first open flow controllers out there, they all, you know, had a notion, for example, for host, for link, and so [UNKNOWN] topology graph. >> Yeah. >> Of a, you know, of a switch. A couple of other things. And those things are reappearing, right. So I think we know at least for the low, low to mid level API's, there's, we're starting to see some common themes. If you go higher up the spec though, it's still all over the place. So you know, we you know, we just did an internal refactoring of our API's. You know, it will come out at some point. I mean, just because we figured out, you know, some of the structures we had before. You know, we could improve on. There's some standardization efforts underway, you know, I would expect those to go relatively slow. At least, you know, that for, while we may standardize on some of the API calls, I think there'll be a lot of networks where we will still have, you know, for another couple of years, you know, you have to, to haul, control specific methods. >> Interesting. Yeah, yeah, I mean, it seems like, as you point out the, the range of, of things that people want to do with, with SDN, it's just like so wide ranging that. >> Exactly. >> It's so any different layers that it's, it's hard to agree on one standard, let alone >> Yup. >> The, the API for managing a data center is probably not the same API as for managing a backbone. I mean it's, they're just too different. >> That, that, that makes sense. Yeah. In terms of just the, the, I mean, you mentioned the types of things that are, that are necessary to make SDN work in an enterprise. And certainly one of those, one of those things is, is, network virtualization. and, and the other sort of cloud, cloud resources, and I wonder sort of what you think about the role of SDN in terms of like, you know, obviously it's got to do some amount of integration, in terms of like you've got to be able to view the network as a, as a, as a pool of resources and, you know, there are other things that you may need. But, certainly this definitely, you know, moves as the SDN beyond the domain, just like controlling routers and switches. But, what, what do you think actually, you know, what do you think are the biggest or most important roles that SDN can play for helping integrate cloud computing in, in, in the enterprise? And, and, and, and also sort of making virtualization, you know, easier to manage? >> Yeah. So, look, I think at the end of the day, right, SDN is on a, on a trajectory where, where I think over time it'll basically replace, you know, what we call, ethernetwork virtualization of fabrics today. Right? These are different things in many cases. But basically, let me take a step back. If you have an enterprise data center. I'm thinking more the private cloud version than the traditional enterprise data center. You know, there's two problems you, you, you have to solve. One is you have to provide connectivity between your LAN hosts. And, you know, the other one is that you basically want to, you know, enforce traffic segregation, and, and basically enforce arbitrary topologies, for example [UNKNOWN] and services, you know, in, in your network. Does that make sense? >> Yeah, that makes, that makes sense. >> And, you know, there's probably two s-, two thoughts, two schools of thought, right? There's one school of thought that says, hey, let's, let's have two different solutions. Right, you know if you follow what what the guys from the sewer have done, right. They basically say I do everything that [UNKNOWN] create an over lay there, then you work with a hydro switch partner that, that does the packet forwarding behind it for the fabric, right. And there's folks like, like, I guess that they are saying, it's wrong approach, you should actually have one integrated solution that matches both your physical network, and, and your virtual network, right. So basically you know, introducing another layer of, of indirection you know, doesn't really make your, your job easier. In fact it, it makes your job harder here. And you know, there's a lot of development going on. You know, we have, our, our biased opinion on what's the right approach, you know, you, you, you just heard, and I think you know, long term what we're hearing from customers is they really looking for, for, you know, think of it is one console right, that allows them to, to manage the entire network. Anything that forwards packets in their system, you know, up to the, to the gateways that go out. And you know, the other thing is pretty clear is this thing needs to be tightly integrated with the overall data center you saw software to find data's at the manuscript infrastructure. >> Right. Right. >> And you know, I think that's the, that's what we'll all kindly figuring out, right? How do you build these systems, how do you plug them into the corridor orchestration system. And how you know, what that do yourself to create these, can you get to a point where you can treat your network as a resource pool you know, for your administrator. >> Yeah that, that makes sense. It seem like another, another big challenge that comes up in, in network management and enterprise network management rather that, that we haven't talked about yet but I think bears mentioning. Is security. I mean, it seems like everyone talks about enterprise network security and, and it seems like there are a whole bunch of issues there that kind of cross with network management ranging from like access control to intrusion detection, to, to isolating different parts of the network, or isolating different services. And I'm wondering if, if, you've encountered that in your discussion with, with various enterprises. Like, what kinds of security problems, the enterprise networks are facing, and, and do you see a role for, for SDN in helping solve those problems? I mean, do we need new apps that talk to, say, a floodlight controller that, that solves specific security problems, and, and if so what, what do you think they are? >> There are huge security challenges in enterprises. So, and specifically, if you go into the highly regulated industries, like you know, financial, health care. But even, even just a normal IT company. You know, security is, is paramount, right? The, let's look for a second how they build security today then how we do the, the, with SDN. Right. Today security is typically done by, first of all VLANs. Just segregate, segregate traffic, right. >> Right. >> Then firewalls. Right. To, to, to basically put between different VLAN segments and, and presume, make sure only certain traffic can, can get across. Right. That's sort of the the two biggest tool that it will have. And then you have a whole sort of monitoring infrastructure you know, intrusion detection system, [UNKNOWN] systems as well, behind that. The, you know, for SDN I think you know almost any SDN solution for the data center today is out there typically they replaces VLANs with something more flexible. VLANs are, are very manual, very hard to administer. With SDN, you can highly automate that, right. Simply control that, so that's basically you know that SDN is absolutely essential. It, it provides segregation, it can provide simple [INAUDIBLE] right, to know that a chip, like a switch, a switching chip, you know, for Broadcom chip today. It's actually pretty good in providing basic ACL's you know, for, for stopping certain traffic, you know,. To replace a full firewall today, I don't think actually SDN can help, right. Because typically what a firewall typically does is, is as far as looking deep into packets, right. You know, to try and understand what the packet is made of. You know, a switching chip can't do that, right? A switching chip can look at a header, but that's what it's optimized for. It can't, can't go deep or you know, it's very very [UNKNOWN] network processor, just a CPU frankly right there. >> Right. >> Most firewalls just have a regular CPU. But SDN can again help to stitch in these services, right. If I basically have two virtual machines running on a hyper visor, and say I want to pick up traffic on one of them send it over to a firewall you know, send it back to the other virtual machine. >> Right, right. In terms of like steering traffic on the network between different middle boxes and so forth you could basically orchestrate, you could. >> [CROSSTALK] Exactly, service insertion, those are big topic. It's very complex and, and SDN can help it Tom. >> Yeah, that, that makes it. Yeah, that makes. >> The the last bit for, for basically picking up traffic and analyzing traffic when it's of tapping, right. You know, that is, that is being done with SDN today. That was actually one of the, the first applications and that's very successful. A regular switch plus an SDN controller you know, basically makes a great programmable patch panel, so to speak, right. Where it can basically take traffic, filter it, and redirect it to, to the right analysis process. >> I see. I, I, I take it you're seeing quite a bit of that in, in, in enterprise networks now, just in terms of using SDN, maybe to steer traffic towards the right. >> Yeah. >> Towards the right middle boxes, and so on. >> Absolutely. >> Is, you know, are those problems sort of well-understood and, and solved? Do you think, I mean we talked a little bit about abstractions. Do, do you think that the notions of traffic steering and things like that, could use better applications or, or abstractions? I mean, it seems like there's huge trade-offs now in terms of like well this middle box over there performs the right function, but I gotta steer my traffic and that's going to affect the performance, right. Or you have to worry about network congestion. >> To, today most customers just build an overlay network for that. So they sort of punt on, [LAUGH] you know punt on the, they, you know, you duplicate the traffic and then you use an overlay network to steer it. There's certainly interesting, interesting questions there. You know, in terms of how do we, can we do that in the network itself, and in a very efficient way. [SOUND]. >> I guess, I guess another question I wanted to ask was certainly, in my, in my limited observations of, of the campus network here, for example, there are different sub-organizations and departments, each of which have their own policy. Sometimes their own way of doing things, their own network operators, and so forth. And you get an organization like an enterprise, right. And I can imagine that it's probably even worse in some cases, because you've got, not only sub-organizations, each with their own operators, but also you, you've got acquisi, acquisitions and mergers that happen. >> Absolutely. Like bits and pieces of networks that you're all trying to kind of glue together. And it seems to me that's like you've got the potential for a lot of like independent configuration going on, maybe even like a lot of different you know, heterogeneity in terms of like vendors, switchers. Even down to like the way certain things are done in different parts of the network. And I'm wondering like, do you see specific challenges there? I mean, it seems like a really hairy, like a hairy world you're dealing with, in, in enterprises, in terms of just all the heterogeneity. like, have you encountered much of that in, in, in your dealings with, with customers and clients and, and, do you think that, that, it seems to me that SDN like, needs to solve a problem there. But do you think that SDN maybe makes some of those problems easier to, to, to deal with or do you think it's just yet another problem that SDN has to solve to be, to sort of make it in the enterprise? >> I think, so, so, typically the way its, we see it organized in enterprise is that you, you have relatively, more or less centralized IT teams. You know, we're not talking CitiBank here which. >> Yeah. >> [INAUDIBLE] Little bit smaller. You have, you have fairly centralized IT teams, which then basically, sort of, essentially an internal service provider. To the different teams that actually do stuff. >> Right. Right. >> The IT team, you know, you have an IT team who provides the infrastructure, and you have another IT team that builds the app that goes on top of that. And basically the IT team, the infrastructure team builds the app team, you know, for, whatever resources they consume. so, what SDN can really help there is that basically by virtualizing the network you have an incredibly useful primitive to do this, right. I mean so in a, in a, the, the, the most innovative enterprises today, how it works, is that you're an app team you can actually go to self service console and say, hey I need you know, a new application, you know this many virtual machines, and this type of network, right. >> Mm-hm. >> The next generation you can actually say, look, I need a three tier application, I need you know, my application consists of you have the gateway then the firewall then the load balancer. Then comes my web tier and then another firewall. Then comes my application tier, then another firewall, and then my database, right. And each of these tiers is a collection of virtual machines, right. >> Right. >> Because we can have this template, the three tier template or the two tier template. And then I pick my template. And then as they get the whole infrastructure substantiated for me. I think that's what stuff, you know, enterprise are probably trying to get to, right. And SDM is an incredibly, you know, incredibly powerful for, for basically orchestrating all this, all the functionality in the network as this happens, right. By doing this in a distributed way is more or less impossible. You have to have some central point of control, and that's the SDN control. >> that, that makes a lot of sense. I guess just to close out we definitely talked a lot about challenges in, in enterprise networks. I'm, I'm, I'm wondering if there is any other challenges that, that you think you know, that we haven't talked about in terms of like really big man, network management challenges. Where, SDN is the, is the killer app or the, or the sort of the hammer that, that we you know, we've been facing this problem for a really long time and now all of a sudden SDN kind of makes it, makes it easier. Or, you know, maybe there's a specific opportunity in, in enterprises that, that, that, where network managements been really hard and now SDN is the lever that we needed. Are there other things that we haven't chatted about that, that we haven't chatted about that, that. >> [CROSSTALK]. >> Are worth mentioning. >> I mean we're, we're very focused we certainly seen you know, from, from other organizations that using you know, SDN and backbone networks, we've seen them using it to basically interconnect data centers, right. We've seen it we haven't seen a whole lot on campus networks yet. Campus networks tends to be a little bit more conservative, right. >> Mm-hm. >> We've seen some people playing around with it you know, for for basically all kinds of case where you just stitch together things like you know, at a peering point for example, right. Or, or you know at a, you know, in a, in a, in a exchange where you have lots of connections coming in and you basically you know, need to provide a lot of pseudo wiretap abstractions. >> Mm-hm. >> So, there's, you know a number of interesting areas. fundamentally, I think, 100% of networking that's out there today, you know, in the long term will be replaced by SDN, right. So. >> Wow. >> You know, handy little $50 billion industry or so, you know, give or take, that, that really, you know, will, will, will change it's entirety. But it's going to take some time. >> Yeah, makes sense, great. well, thanks a lot for taking the time, really appreciate, really appreciate your talking to, to us today. >> Thanks for having me Nick. >> Thanks a lot. >> Bye.
