>> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the CloudNative Computing Foundation, and Ecosystem Partners. >> Hi and welcome back to theCUBE's coverage of KubeCon, CloudNativeCon 2020 in Europe, of course the virtual edition. I'm Stu Miniman and happy to welcome back to the program one of the keynote speakers, he's also a board member of the CNCF, Vijoy Pandey who is the vice president and chief technology officer for Cloud at Cisco. Vijoy, nice to see you and thanks so much for joining us. >> Thank you Stu, and nice to see you again. It's a strange setting to be in but as long as we are both health, everything is good. >> Yeah, it's still a, we still get to be together a little bit even though while we're apart, we love the engagement and interaction that we normally get through the community but we just have to do it a little bit differently this year. So we're going to get to your keynote. We've had you on the program to talk about "Network, Please Evolve", been watching that journey. But why don't we start it first, you know, you've had a little bit of change in roles and responsibility. I know there's been some restructuring at Cisco since the last time we got together. So give us the update on your role. >> Yeah, so that, yeah let's start there. So I've taken on a new responsibility. It's VP of Engineering and Research for a new group that's been formed at Cisco. It's called Emerging Tech and Incubation. Liz Centoni leads that and she reports into Chuck. The role, the charter for this team, this new team, is to incubate the next bets for Cisco. And, if you can imagine, it's natural for Cisco to start with bets which are closer to its core business, but the charter for this group is to mover further and further out from Cisco's core business and takes this core into newer markets, into newer products, and newer businesses. I am running the engineering and research for that group. And, again, the whole deal behind this is to be a little bit nimble, to be a little startupy in nature, where you bring ideas, you incubate them, you iterate pretty fast and you throw out 80% of those and concentrate on the 20% that make sense to take forward as a venture. >> Interesting. So it reminds me a little bit, but different, I remember John Chambers a number of years back talking about various adjacencies, trying to grow those next, you know, multi-billion dollar businesses inside Cisco. In some ways, Vijoy, it reminds me a little bit of your previous company, very well known for, you know, driving innovation, giving engineering 20% of their time to work on things. Give us a little bit of insight. What's kind of an example of a bet that you might be looking at in the space? Bring us inside a little bit. >> Well that's actually a good question and I think a little bit of that comparison is, are those conversations that taking place within Cisco as well as to how far out from Cisco's core business do we want to get when we're incubating these bets. And, yes, my previous employer, I mean Google X actually goes pretty far out when it comes to incubations. The core business being primarily around ads, now Google Cloud as well, but you have things like Verily and Calico and others which are pretty far out from where Google started. And the way we are looking at these things within Cisco is, it's a new muscle for Cisco so we want to prove ourselves first. So the first few bets that we are betting upon are pretty close to Cisco's core but still not fitting into Cisco's BU when it comes to go-to-market alignment or business alignment. So while the first bets that we are taking into account is around API being the queen when it comes to the future of infrastructure, so to speak. So it's not just making our infrastructure consumable as infrastructure's code, but also talking about developer relevance, talking about how developers are actually influencing infrastructure deployments. So if you think about the problem statement in that sense, then networking needs to evolve. And I talked a lot about this in the past couple of keynotes where Cisco's core business has been around connecting and securing physical endpoints, physical I/O endpoints, whatever they happen to be, of whatever type they happen to be. And one of the bets that we are, actually two of the bets that we are going after is around connecting and securing API endpoints wherever they happen to be of whatever type they happen to be. And so API networking, or app networking, is one big bet that we're going after. Our other big bet is around API security and that has a bunch of other connotations to it where we think about security moving from runtime security where traditionally Cisco has played in that space, especially on the infrastructure side, but moving into API security which is only under the developer pipeline and higher up in the stack. So those are two big bets that we're going after and as you can see, they're pretty close to Cisco's core business but also very differentiated from where Cisco is today. And once when you prove some of these bets out, you can walk further and further away or a few degrees away from Cisco's core as it exists today. >> All right, well Vijoy, I mentioned you're also on the board for the CNCF, maybe let's talk a little bit about open source. How does that play into what you're looking at for emerging technologies and these bets, you know, so many companies, that's an integral piece, and we've watched, you know really, the maturation of Cisco's journey, participating in these open source environments. So help us tie in where Cisco is when it comes to open source. >> So, yeah, so I think we've been pretty deeply involved in open source in our past. We've been deeply involved in Linux foundational networking. We've actually chartered FD.io as a project there and we still are. We've been involved in OpenStack. We are big supporters of OpenStack. We have a couple of products that are on the OpenStack offering. And as you all know, we've been involved in CNCF right from the get go as a foundational member. We brought NSM as a project. It's sandbox currently. We're hoping to move it forward. But even beyond that, I mean we are big users of open source. You know a lot of us has offerings that we have from Cisco and you would not know this if you're not inside of Cisco, but Webex, for example, is a big, big user of linger D right from the get go from version 1.0. But we don't talk about it, which is sad. I think for example, we use Kubernetes pretty deeply in our DNAC platform on the enterprise site. We use Kubernetes very deeply in our security platforms. So we are pretty deep users internally in all our SAS products. But we want to press the accelerator and accelerate this whole journey towards open source quite a bit moving forward as part of ET&I, Emerging Tech and Incubation as well. So you will see more of us in open source forums, not just the NCF but very recently we joined the Linux Foundation for Public Health as a premier foundational member. Dan Kohn, our old friend, is actually chartering that initiative and we actually are big believers in handling data in ethical and privacy preserving ways. So that's actually something that enticed us to join Linux Foundation for Public Health and we will be working very closely with Dan and the foundational companies there to, not just bring open source, but also evangelize and use what comes out of that forum. >> All right. Well, Vijoy, I think it's time for us to dig into your keynote. We've spoken with you in previous KubeCons about the "Network, Please Evolve" theme that you've been driving on, and big focus you talked about was SD-WAN. Of course anybody that been watching the industry has watched the real ascension of SD-WAN. We've called it one of those just critical foundational pieces of companies enabling Multicloud, so help us, you know, help explain to our audience a little bit, you know, what do you mean when you talk about things like CloudNative, SD-WAN, and how that helps people really enable their applications in the modern environment? >> Yeah, so, well we we've been talking about SD-WAN for a while. I mean, it's one of the transformational technologies of our time where prior to SD-WAN existing, you had to stitch all of these MPLS labels and actual data connectivity across to your enterprise or branch and SD-WAN came in and changed the game there. But I think SD-WAN as it exists today is application-alaware. And that's one of the big things that I talk about in my keynote. Also, we've talked about how NSM, the other side of the spectrum, is how NSM, or network service mesh, has actually helped us simplify operational complexities, simplify the ticketing and process hell that any developer needs to go through just to get a multicloud, multicluster app up and running. So the keynote actually talked about bringing those two things together where we've talked about using NSM in the past, in chapter one and chapter two, ah chapter two, no this is chapter three and at some point I would like to stop the chapters. I don't want this to be like, like an encyclopedia of networking (mumbling) But we are at chapter three and we are talking about how you can take the same consumption models that I talked about in chapter two which is just adding a simple annotation in your CRD and extending that notion of multicloud, multicluster wires within the components of our application but extending it all the way down to the user in an enterprise. And as you saw an example, Gavin Russom is trying to give a keynote holographically and he's suffering from SD-WAN being application alaware. And using this construct of a simple annotation, we can actually make SD-WAN CloudNative. We can make it application-aware, and we can guarantee the SLOs that Gavin is looking for in terms of 3D video, in terms of file access or audio just to make sure that he's successful and Ross doesn't come in and take his place. >> Well I expect Gavin will do something to mess things up on his own even if the technology works flawly. You know, Vijoy the modernization journey that customers are on is a neverending story. I understand the chapters need to end on the current volume that you're working on. But, you know, we'd love to get your view point. You talk about things like service mesh. It's definitely been a hot topic of conversation for the last couple of years. What are you hearing from your customers? What are some of the the kind of real challenges but opportunities that they see in today's CloudNative space? >> In general, service meshes are here to stay. In fact, they're here to proliferate to some degree and we are seeing a lot of that happening where not only are we seeing different service meshes coming into the picture through various open source mechanisms. You've got Istio there, you've got linger D, you've got various proprietary notions around control planes like App Mesh from Amazon. There's Console which is an open source project But not part of (mumbles) today. So there's a whole bunch of service meshes in terms of control planes coming in on volumes becoming a de facto side car data plane, whatever you would like to call it, de facto standard there which is good for the community I would say. But this proliferation of control planes is actually a problem. And I see customers actually deploying a multitude of service meshes in their environment. And that's here to stay. In fact, we are seeing a whole bunch of things that we would use different tools for. Like API Gate was in the past. And those functions are actually rolling into service meshes. And so I think service meshes are here to stay. I think the diversity of some service meshes is here to stay. And so some work has to be done in bringing these things together and that's something that we are trying to focus in on all as well because that's something that our customers are asking for. >> Yeah, actually you connected for me something I wanted to get your viewpoint on. Dial back you know 10, 15 years ago and everybody would say, "Ah, you know, I really want to have single pane of glass "to be able to manage everything." Cisco's partnering with all of the major cloud providers. I saw, you know, not that long before this event, Google had their Google Cloud show talking about the partnership that you have with Cisco with Google. They have Anthos. You look at Azure has Arc. You know, VMware has Tanzu. Everybody's talking about, really, kind of this multicluster management type of solution out there. And just want to get your viewpoint on this Vijoy is to, you know, how are we doing on the management plane and what do you think we need to do as a industry as a whole to make things better for customers? >> Yeah, but I think this is where I think we need to be careful as an industry, as a community and make things simpler for our customers because, like I said, the proliferation of all of these control planes begs the question, do we need to build something else to bring all of these things together. And I think the SMI apropos from Microsoft is bang on on that front where you're trying to unify at least the consumption model around how you consume these service meshes. But it's not just a question of service meshes. As you saw in the SD-WAN and also going back in the Google discussion that you just, or Google conference that we just offered It's also how SD-WANs are going to interoperate with the services that exist within these cloud silos to some degree. And how does that happen? And there was a teaser there that you saw earlier in the keynote where we are taking those constructs that we talked about in the Google conference and bringing it all the way to a CloudNative environment in the keynote. But I think the bigger problem here is how do we manage this complexity of disparate stacks, whether it's service meshes, whether it's development stacks, or whether it's SD-WAN deployments, how do we manage that complexity? And, single pane of glass is over loaded as a term because it brings in these notions of big, monolithic panes of glass. And I think that's not the way we should be solving it. We should be solving it towards using API simplicity and API interoperability. I think that's where we as a community need to go. >> Absolutely. Well, Vijoy, as you said, you know, the API economy should be able to help on these, you know, multi, the service architecture should allow things to be more flexible and give me the visibility I need without trying to have to build something that's completely monolithic. Vijoy, thanks so much for joining. Looking forward to hearing more about the big bets coming out of Cisco and congratulations on the new role. >> Thank you Stu. It was a pleasure to be here. >> All right, and stay tuned for much more coverage of theCUBE at KubeCon, CloudNativeCon. I'm Stu Miniman and thanks for watching. (light digital music)

(upbeat music) >> From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 Virtual brought to you by Red Hat, the Cloud Native Computing Foundation, and the ecosystem partners. >> Hi, and welcome back to theCUBE's coverage of KubeCon + CloudNativeCon 2020 in Europe, of course, the virtual edition. I'm Stu Miniman, and happy to welcome you back to the program. One of the keynote speakers is also a board member of the CNCF, Vijoy Pandey, who is the Vice President and Chief Technology Officer for Cloud at Cisco. Vijoy, nice to see you, thanks so much for joining us. >> Hi there, Stu, so nice to see you again. It's a strange setting to be in, but as long as we are both healthy, everything's good. >> Yeah, we still get to be together a little bit even though while we're apart. We love the the engagement and interaction that we normally get to the community, but we just have to do it a little bit differently this year. So we're going to get to your keynote. We've had you on the program to talk about "Networking, Please Evolve". I've been watching that journey. But why don't we start at first, you've had a little bit of change in roles and responsibility. I know there's been some restructuring at Cisco since the last time we got together. So give us the update on your role. >> Yeah, so let's start there. So I've taken on a new responsibility. It's VP of Engineering and Research for a new group that's been formed at Cisco. It's called Emerging Tech and Incubation. Liz Centoni leads that and she reports on to Chuck. The charter for the team, this new team, is to incubate the next bets for Cisco. And if you can imagine, it's natural for Cisco to start with bets which are closer to its core business. But the charter for this group is to move further and further out from Cisco's core business and take Cisco into newer markets, into newer products, and newer businesses. I'm running the engineering and resource for that group. And again, the whole deal behind this is to be a little bit nimble, to be a little bit, to startupy in nature, where you bring ideas, you incubate them, you iterate pretty fast, and you throw out 80% of those, and concentrate on the 20% that makes sense to take forward as a venture. >> Interesting. So it reminds me a little bit but different, I remember John Chambers, a number of years back, talking about various adjacencies trying to grow those next multi-billion dollar businesses inside Cisco. In some ways, Vijoy, it reminds me a little bit of your previous company, very well known for driving innovation, giving engineers 20% of their time to work on things, maybe give us a little bit insight, what's kind of an example of a bet that you might be looking at in this space, bring us in tight a little bit. >> Well, that's actually a good question. And I think a little bit of that comparison is all those conversations are taking place within Cisco as well as to how far out from Cisco's core business do we want to get when we're incubating these bets? And yes, my previous employer, I mean, Google X actually goes pretty far out when it comes to incubations, the core business being primarily around ads, now Google Cloud as well. But you have things like Verily and Calico, and others, which are pretty far out from where Google started. And the way we're looking at the these things within Cisco is, it's a new muscle for Cisco, so we want to prove ourselves first. So the first few bets that we are betting upon are pretty close to Cisco's core but still not fitting into Cisco's BU when it comes to, go to market alignment or business alignment. So one of the first bets that we're taking into account is around API being the queen when it comes to the future of infrastructure, so to speak. So it's not just making our infrastructure consumable as infrastructure as code but also talking about developer relevance, talking about how developers are actually influencing infrastructure deployments. So if you think about the problem statement in that sense, then networking needs to evolve. And I've talked a lot about this in the past couple of keynotes, where Cisco's core business has been around connecting and securing physical endpoints, physical I/O endpoints, wherever they happen to be, of whatever type they happen to be. And one of the bets that we are, actually two of the bets, that we're going after is around connecting and securing API endpoints, wherever they happen to be, of whatever type they happen to be. And so API networking or app networking is one big bet that we're going after. Another big bet is around API security. And that has a bunch of other connotations to it, where we think about security moving from runtime security, where traditionally Cisco has played in that space, especially on the infrastructure side, but moving into API security, which is earlier in the development pipeline, and higher up in the stack. So those are two big bets that we're going after. And as you can see, they're pretty close to Cisco's core business, but also are very differentiated from where Cisco is today. And once you prove some of these bets out, you can walk further and further away, or a few degrees away from Cisco's core. >> All right, Vijoy, why don't you give us the update about how Cisco is leveraging and participating in open source? >> So I think we've been pretty, deeply involved in open source in our past. We've been deeply involved in Linux Foundation Networking. We've actually chartered FD.io as a project there and we still are. We've been involved in OpenStack, we have been supporters of OpenStack. We have a couple of products that are around the OpenStack offering. And as you all know, we've been involved in CNCF, right from the get-go, as a foundation member. We brought NSM as a project. I had Sandbox currently, but we're hoping to move it forward. But even beyond that, I mean, we are big users of open source, a lot of those has offerings that we have from Cisco, and you will not know this if you're not inside of Cisco. But Webex, for example, is a big, big user of Linkerd, right from the get-go, from version 1.0, but we don't talk about it, which is sad. I think, for example, we use Kubernetes pretty deeply in our DNAC platform on the enterprise side. We use Kubernetes very deeply in our security platforms. So we're pretty good, pretty deep users internally in our SaaS products. But we want to press the accelerator and accelerate this whole journey towards open source, quite a bit moving forward as part of ET&I, Emerging Tech and Incubation, as well. So you will see more of us in open source forums, not just CNCF, but very recently, we joined the Linux Foundation for Public Health as a premier foundational member. Dan Kohn, our old friend, is actually chartering that initiative, and we actually are big believers in handling data in ethical and privacy-preserving ways. So that's actually something that enticed us to join Linux Foundation for Public Health, and we will be working very closely with Dan and foundational companies that do not just bring open source but also evangelize and use what comes out of that forum. >> All right, well, Vijoy, I think it's time for us to dig into your keynote. We've we've spoken with you in previous KubeCons about the "Network, Please Evolve" theme that you've been driving on. And big focus you talked about was SD-WAN. Of course, anybody that's been watching the industry has watched the real ascension of SD-WAN. We've called it one of those just critical foundational pieces of companies enabling multi-cloud. So help explain to our audience a little bit, what do you mean when you talk about things like Cloud Native SD-WAN and how that helps people really enable their applications in the modern environment? >> Yes, well, I mean, we've been talking about SD-WAN for a while. I mean, it's one of the transformational technologies of our time where prior to SD-WAN existing, you had to stitch all of these MPLS labels and actually get your connectivity across to your enterprise or branch. And SD-WAN came in and changed the game there, but I think SD-WAN, as it exists today, is application-unaware. And that's one of the big things that I talk about in my keynote. Also, we've talked about how NSM, the other side of the spectrum, is how NSM or Network Service Mesh has actually helped us simplify operational complexities, simplify the ticketing and process health that any developer needs to go through just to get a multi-cloud, multi-cluster app up and running. So the keynote actually talked about bringing those two things together, where we've talked about using NSM in the past in chapter one and chapter two. And I know this is chapter three, and at some point, I would like to stop the chapters. I don't want this like an encyclopedia of "Networking, Please Evolve". But we are at chapter three, and we are talking about how you can take the same consumption models that I talked about in chapter two, which is just adding a simple annotation in your CRD, and extending that notion of multi-cloud, multi-cluster wires within the components of our application, but extending it all the way down to the user in an enterprise. And as we saw an example, Gavin Belson is trying to give a keynote holographically and he's suffering from SD-WAN being application-unaware. And using this construct of a simple annotation, we can actually make SD-WAN cloud native, we can make it application-aware, and we can guarantee the SLOs, that Gavin is looking for, in terms of 3D video, in terms of file access for audio, just to make sure that he's successful and Ross doesn't come in and take his place. >> Well, I expect Gavin will do something to mess things up on his own even if the technology works flawlessly. Vijoy, the modernization journey that customers are on is a never-ending story. I understand the chapters need to end on the current volume that you're working on, but we'd love to get your viewpoint. You talk about things like service mesh, it's definitely been a hot topic of conversation for the last couple of years. What are you hearing from your customers? What are some of the kind of real challenges but opportunities that they see in today's cloud native space? >> In general, service meshes are here to stay. In fact, they're here to proliferate to some degree, and we are seeing a lot of that happening, where not only are we seeing different service meshes coming into the picture through various open source mechanisms. You've got Istio there, you've Linkerd, you've got various proprietary notions around control planes like App Mesh, from Amazon, there's Consul, which is an open source project, but not part of CNCF today. So there's a whole bunch of service meshes in terms of control planes coming in. Envoy is becoming a de facto sidecar data plane, whatever you would like to call it, de facto standard there, which is good for the community, I would say. But this proliferation of control planes is actually a problem. And I see customers actually deploying a multitude of service meshes in their environment, and that's here to stay. In fact, we are seeing a whole bunch of things that we would use different tools for, like API gateways in the past, and those functions actually rolling into service meshes. And so I think service meshes are here to stay. I think the diversity of service meshes is here to stay. And so some work has to be done in bringing these things together. And that's something that we are trying to focus in on as well. Because that's something that our customers are asking for. >> Yeah, actually, you connected for me something I wanted to get your viewpoint on, go dial back, 10, 15 years ago, and everybody would say, "Oh, I really want to have a single pane of glass "to be able to manage everything." Cisco's partnering with all of the major cloud providers. I saw, not that long before this event, Google had their Google Cloud Show, talking about the partnership that you have with, Cisco with Google. They have Anthos, you look at Azure has Arc, VMware has Tanzu. Everybody's talking about really the kind of this multi-cluster management type of solution out there, and just want to get your viewpoint on this Vijoy as to how are we doing on the management plane, and what do you think we need to do as an industry as a whole to make things better for customers? >> Yeah, I think this is where I think we need to be careful as an industry, as a community and make things simpler for our customers. Because, like I said, the proliferation of all of these control planes begs the question, do we need to build something else to bring all these things together? I think the SMI proposal from Microsoft is bang on on that front, where you're trying to unify at least the consumption model around how you consume these service meshes. But it's not just a question of service meshes as you saw in the SD-WAN announcement back in the Google discussion that we just, Google conference that you just referred. It's also how SD-WANs are going to interoperate with the services that exist within these cloud silos to some degree. And how does that happen? And there was a teaser there that you saw earlier in the keynote where we are taking those constructs that we talked about in the Google conference and bringing it all the way to a cloud native environment in the keynote. But I think the bigger problem here is how do we manage this complexity of this pallet stacks? Whether it's service meshes, whether it's development stacks, or whether it's SD-WAN deployments, how do we manage that complexity? And single pane of glass is overloaded as a term, because it brings in these notions of big monolithic panes of glass. And I think that's not the way we should be solving it. We should be solving it towards using API simplicity and API interoperability. And I think that's where we as a community need to go. >> Absolutely. Well, Vijoy, as you said, the API economy should be able to help on these, the service architecture should allow things to be more flexible and give me the visibility I need without trying to have to build something that's completely monolithic. Vijoy, thanks so much for joining. Looking forward to hearing more about the big bets coming out of Cisco, and congratulations on the new role. >> Thank you, Stu. It was a pleasure to be here. >> All right, and stay tuned for lots more coverage of theCUBE at KubeCon + CloudNativeCon. I'm Stu Miniman. Thanks for watching. (upbeat music)

>> Announcer: Live from the Computer History Museum in Mountain View, California, it's theCUBE, covering DevNet Create 2018. Brought to you by Cisco. (jingle) >> Hi, welcome back to theCUBE. My name is Lauren Cooney, and I'm here today with Matt Johnson who is a technologist at Cisco, with Cisco DevNet. Hi Matt. >> Hi, how's it going? Good to see you again. >> Pretty good. Good to see you again too. So what's going on here? What's going on with the show and what are you working on? >> Oh, sure. So the show in general is just this ability for us, you know, Cisco DevNet have always had quite a large and a growing presence at Cisco Live, kind of Cisco's, Europe and US yearly conferences. But this is the second year we've done Create, and it's really an opportunity to kind of take the real developer angle, the makers, the API integrators, kind of the real, kind of developer ecosystem that's going around Cisco's products and our APIs, and just kind of focus on that audience. So, you know, all the content here is developer for developer. And so it's just really nice to be able to experiment in a bit more of an open format. >> Yeah, exactly. So it's kind of that DIY environment of developers that are coming in and really doing all this stuff and starting to innovate on their own. >> Yeah, absolutely. And what I'm really excited about here we have the, we had kind of a two-day hackathon running at the same time as the event, and so, instead of that just being a little bit of time spent between sessions, these are teams that have already kind of been working behind the scenes on the run-up to the event, so they've already kind of met each other virtually through collaboration, they've already worked out what kind of problem space they want to solve, they've already started working on kind of sample and PLC code, so the idea that at the end of a two-day conference we could actually see some working solutions to real problems that our partners and our customer ecosystem is seeing, I think that's quite-- >> That's great. >> An exciting idea. >> Yeah, Mandy Whalen was just on with us. >> Oh, fantastic. >> And she actually talked a little bit about that, and you know, so these guys will be up for 24 hours hacking on stuff. Hopefully we'll see some great solutions come the end and you know, we'll talk about it here on theCUBE. >> Yeah. >> So tell me about what you're doing today at Cisco DevNet. >> Sure, so from one style of hacking to another, we are actually running this demo called the Black Hat White Hat Challenge. And I went to, I've always been a bit of a kind of hobbyist pentester. >> Lauren: Never, no. >> I liked breaking things from a young age. And I got to attend my first Defcon in Las Vegas last year, and coming from an evangelism background, coming from kind of doing workshops and talks and demos, I was absolutely amazed at the interactivity of pretty much everything that goes on at the black hat hacking conference, sorry the Defcon hacking conference. My apologies. They have, you know, hands-on IoT villages where you can go and try hacking against all the hardware, there is kind of labs and tutorials for people that are maybe just getting into kind of that side of hacking and penetration testing. So I kind of brought that back and I've always had a passion for security, and IoT nowadays, we are in a situation where a lot of these devices we are starting to bring into our homes and our businesses and things, are built to a budget. They are built cheap, they're not security devices. People aren't thinking of security, they're thinking of functionality when they're building those, so someone that makes fridge freezers isn't going to be thinking about the 10 year security roadmap for that fridge freezer. They're going to be thinking about selling the latest smart freezer. >> Lauren: Exactly. >> And so I wanted to kind of bring some of that hands-on Defcon-style hacking into a real-world scenario. So at security conferences and at developer conferences, we always talk about things being insecure, and we talk about needing to think about security. But what we have is a booth here where we actually take off-the-shelf IoT devices, and in a curated path we are getting attendees with no background in kind of pen testing to use real-world hacking tools and real exploits against those devices, to build their access into that network and eventually get to the goal, which is getting into an electrical safe with like a price inside. And all of that is real off-the-shelf IoT. It's real security. And the aim of that is to kind of-- >> So they are actually cracking the safe. >> They are cracking the safe, they are cracking into Wi-Fi. They're getting onto the guest Wi-Fi and then finding a vulnerability in the router which gets them onto the wired network, so that'd be like a guest network in a corporate environment or a guest network in a hotel, getting you onto the hotel's infrastructure network and then to a camera. >> So this is like straight up hacker one. >> Straight up, yeah, exactly, right? Which is perfect. >> Lauren: This is great. >> Yeah, exactly. So that's what we're doing and the idea is to just to kind of stop talking about it and start showing. This is not stuff you need to be super good at. This is stuff you can Google. The tools are out there, the tools are getting more and more easy to use. And also vulnerabilities are becoming more and more common because of the growth of IoT. There were double the number of CVE, like known vulnerabilities in the wild in 2017 than there were in 2016. >> Okay. >> And that's because of this constant pace of new devices. So we're kind of showing that these are really crackable by anyone with a bit of time and research. And then also showing kind of what can be done about that. And, you know, even without kind of the proactive and firewalls and things like that, just getting a developer audience thinking about this stuff, getting them, you know, fresh in their mind, you know, these are the kind of places we should be focusing on IoT security because it's these developers that will be writing code and those products today-- >> I think that's great. And I think security is so important today with everything going on, and then there's Facebook and testimonies that are happening today, and you know, lots of different things. Now, what are you using to actually kind of fill these holes, fill these kind of security vulnerabilities that you're using with these off-the-shelf IoT devices? >> Sure, so what we are showing is how kind of, if you know if you have these devices on your network, obviously layering things like Cisco's net-gen firewalls in line with those devices, has signatures that will detect. It's not going to patch the device itself, 'cause that might be from another vendor or an IoT camera or a light switch or something, but it's going to detect the malicious traffic trying to attack that device and drop it. So you're kind of protecting your perimeter, you're stopping a vulnerable device becoming an actual hack. Alternatively from a personal perspective, as we start looking at how we consume hardware in our homes and businesses, I actually really like kind of the Meraki model and the Nest Cam model, and you know, all the other camera vendors which charge you with subscription, 'cause if you buy hardware one-off, you have no idea whether that price for that hardware allotted budget for the development team to keep thinking about security or whether that team doesn't exist anymore and they're off building their next product. >> Lauren: Yup. >> Whereas if you're buying something on kind of a subscription basis, even though the hardware is in your home, you know that their profit is based on them keeping your product up-to-date. >> Lauren: Definitely. >> So you expect, you know, real-time updates, you expect timely security updates. And so I think that kind of a software as a service style delivery of on-prem hardware is definitely a more secure approach. >> Yeah, and the Meraki model is definitely moving forward as one of the prevalent models that we, you know, Cisco has. >> Exactly. Yeah. >> And it's, you know, that plug and play, easy-to-use, get it up and running, et cetera. >> Exactly, and then on the back of that you know that there's people working on those security things, which isn't something that you think about when you buy it for its APIs and its plug-and-play in its ease-of-use, but just knowing that that is there and, you know, you're paying for that development, is a good thing. >> Where do you see most of these vulnerabilities, and I know you have a lot of background in cloud computing and you know, in these arenas, but where do you see most of these vulnerabilities? >> Matt: So-- >> It's a big question. >> Yeah. I mean a lot of the, hackers are going to wherever, you know, is easiest for the amount of time and effort. Certainly when we see kind of malicious actors kind of looking for a large footprints, large, building botnets et cetera. There could be a very, very clever attack that requires a lot of time and effort, or there could be an IoT device that you know there's going to be 4 million of them sold online, they're going to go for those. And like I said, these devices are low-power, built to a budget. You can get them into your hands and like SaaS service online. So people can take them apart, they can have a look at the code inside of them. They can have a look at the operating system. So it's quite easy to find vulnerabilities on these IOT devices. >> Lauren: Oh yeah. >> So that is definitely a growing area. Also the level for harm on those kind of vulnerabilities, if we are talking about Internet-connected healthcare, Internet-connected hospital equipment, you know, control valves for factories that may or may not be dealing with certain kind of materials. That is definitely a focus both from a security industry perspective, and also kind of where we are seeing hackers targeting. >> That's great. So tell me a little bit about what else you're working on right now. I think, I always find it interesting to hear from you what you're kind of hacking with and-- >> Yeah, sure. So that's my, that's my kind of security hobby-cum-part time role I guess within DevNet. >> Lauren: Love it. >> I quite like that kind of hands-on security evangelism. A lot of other stuff I'm doing is all around kind of open source and micro services and containers. So we're doing lots of work internally with Kubernetes Right now. Proof of concepting, some new user space networking code. >> Lauren: Oh great. >> Which would allow basically the network your traffic takes from your application in the container, write out to the network card, to be a user space app. So, you know, you're not stuck with the networking that a cloud provider gives you. If you want to test your application fully like packet to app back to the wire, and know that that network is also going to go with you when you deploy anywhere, we're going to be able to do that. >> That's fabulous. >> And there's also some real performance benefits to kind of not going in and out of the Linux kernel, so we can kind of saturate 40 gigabits a second from a container, straight down to the wire on kind of commodity compute like UCS what like any x86 service. So really excited about that. It's in development at the moment. That's all open source. >> Lauren: It will be all open source. >> It's all open source already under the FD.io project, FD dot io. >> Oh. >> The integration into Kubernetes is ongoing. And obviously will be open sourced as it gets developed. But that's super exciting. Also just the whole Merakifi, Merakification if I can say that. This idea of turning on-prem devices into kind of black box, you know, cloud managed, cloud updated. You have an IT team. They're just remote and kind of paid for in a SaaS model rather than having to manage and patch those devices on-prem. >> Lauren: Oh yeah. >> You know, we currently do that with switches and routers and cameras as I'm sure you know that the Meraki product portfolio, I don't see why we don't do that with on-prem compute. Why don't we do that with on-prem, you know, Kubernetes clusters. Why should a Kubernetes cluster, just because it sat in your data center, be any different in terms of usability, billing, management, than the one you get from Google Cloud platform or Azure or AWS? It should have the same user experience. So across those two areas, yeah, that's where I'm spending most of my time at the moment. >> Great, well, we're kind of wrapping up here. Tell me, what is the most exciting thing for you that's coming down the path in the next six months or so? >> Um. >> Can you tell us? >> I cannot tell you the most exciting thing, I'm afraid. It has to do with everything I'm talking about, kind of the networking, the as a service, super excited about user space networking. We have customers that looking to do kind of real-time video pipelines for a broadcast in containers. And being able to do that on-prem or in cloud or wherever, and this FD.io VPP technology, I think will really unlock that. >> Lauren: That's great. >> So real use cases, and yeah, super excited. >> Great. Matt, thank you so much for coming on today. >> It's been pleasure. >> Yeah, my pleasure as well. This is Lauren Clooney and we'll be right back from the show here at Cisco DevNet Create. (jingle)

(cheerful music) >> Announcer: Live from Los Angeles, it's theCUBE! Covering Open Source Summit North America 2017. Brought to you by The Linux Foundation and Red Hat. >> Welcome back, and we're live here in Los Angeles. This is theCUBE's special coverage of Open Source Summit North America. I'm John Furrier with Stu Miniman. Two days of wall-to-wall coverage. Our next guest, Ed Warnicke, who is a distinguished consulting engineer with Cisco. Welcome to theCUBE. >> Glad to be here! >> Thanks for coming on. Love to get into it. We love infrastructure as code. We love the cloud developers. The young generation loves it. Making things easy to use all sounds great, but there's still work to get done. The networking... So what's going on here at the Open Source? So this is the big tent event where there's a lot of cross-pollination around projects. Obviously the networking side, you guys at Cisco are doing your share. Give us the update. Networking is still a lot more work to be done. It's a very strategic part of the equation. Certainly making it easier up above makes it programmable. >> Yeah, you have to make the networking invisible even to the DevOps layer. There are certain things that you need from the network. They need isolation and reachability. They need service discovery and service routing. But they don't want to have to think about it. They don't want to be burdened with understanding the nitty gritty details. They don't want to know what subnet they're on, they don't want to have to worry about ACL's, they don't want to think about all of that. And the truth is, there's a lot of work that goes into making the network invisible and ubiquitous for people. And in particular, one of the challenges that we see arising as the world moves more cloud-native, as the microservices get smaller, as the shift happens toward serverless, as Kubernetes is coming on with containers, is that the network is really becoming the run time. And that run time has the need to scale and perform like it never has before. So the number of microservices you'd like to put on a server keeps going up, and that means you need to be able to actually handle that. The amount of traffic that people want to push through them continues to go up. So your performance has to keep up. And that brings a lot of distinct challenges, particularly when you're trying to achieve those in systems that were designed for a world where you had maybe two NIC's on the box, where you weren't really thinking when the original infrastructure was built about the fact that you were actually going to have to do a hell of a lot of routing inside the server because you now have currently hundreds, but hopefully someday thousands and tens of thousands of microservices running there. >> Ed, you know, I think when we've been talking about the last 15 or 20 years or so, I need to move faster with my deployment. It always seemed that networking was the thing that held everything up. It's like, okay, wait, when I virtualized, everything's great and everything, and I can just spit up a VM and do that. Oh, but I need to wait for the network to be provisioned. What are the things you've been working on, what open source projects? There's a lot of them out there helping us to really help that overall agility of work today. >> Absolutely. So one of the things I'm deeply involved in right now is a project called FD.io, usually pronounced Fido, because it's cute. And it means we can give away puppies at conferences. It's great. What FD.io is doing, is we have this core technology called VPP that gives you incredibly performant, incredibly scalable networking purely in user space. Which means from a developer velocity point of view, we can have new features every three months. From an extensibility point of view, you can bring new network features as separate plugins you drop as .so's into a plugin directory instead of having to wait for the kernel to rev on your server. And the revving process is also substantially less invasive. So if you need to take a microservice network as a user space thing and rev it, it's a restart of a process. You're talking microseconds, not 15-minute reboot cycles. You're talking levels of disruption where you don't lose your TCP state, where you don't lose any of those things. And that's really crucial to having the kind of agility that you want in the network. And when I talk about performance and scalability, I'm not kidding. So one of the things we recently clocked out with VPP was being able to route a terabyte per second of traffic with millions of routes in the forwarding tables on commodity servers with no hardware existence at all. And the workloads are starting to grow in that direction. It's going to take them a while to catch up, but to your point about the network being the long pull, we want to be far ahead of that curve so it's not the long pull anymore. So you can achieve the agility that you need in DevOps and move innovative products forward. >> Ed, one of the things that comes up all the time, I wanted to get your reaction to this because you're an important part of it, is developers say, look, I love DevOps. And even ops guys are saying, we want to promote DevOps, so there's a mind meld there if you will. But then what they don't want is a black box. They want to see debugging, and they want to have ease of manageability. So I don't mind pushing dev, if I'm an ops guy, send the dev down, but they need a path of visibility. They need to have access to debug fast. Get access to some of those things. What do you see as gates if you will, that we got to get through to make that seamless and clean right now? Obviously Kubernetes, lot of stuff going on with orchestration. And containers are providing a path. But still, the complaint and nervousness is okay, you can touch and program the infrastructure, but if something happens, you're going to be reactive. >> Yeah, that gets exactly to the point. Because the more invisible the network is, the more visibility you need when things go wrong. And for general operational use. And one of the cool things that's happening in FD.io around that, is number one, it's industrial scale. So you have all sorts of counters and telemetry information that you need from an historical point of view in networks to be able to figure out what's going on. But beyond that, there's a whole lot of innovation that's been happening in the network space that has yet to trickle down all the way to the server edge. A really classic example on the visibility front has to do with in-band iOAM. So we now have the technology, and this is present today in VPP, to be able to say, hey, I would like an in-band trace on the flow though the network of this flow for this customer who's giving me a complaint, where I can see hop by hop through the network including in the edge where VPP is, what's the latency between hops? What path it actually passed through. And there's even a feature there where you could say, at each hop, please send the packet capture at that hop to a third-party point where I can collect it so I can look at it in something like Wireshark. So you can look in Wireshark and say, okay I see where this went into that node and came out that node this way. Node by node by node. I don't know how much more visibility than that is actually physically possible. And that's one of the kinds of things that the velocity of features that you have in VPP has made very possible. That's the kind of thing that would take a long time to work into the traditional development line for networking. >> What's the Cisco internal vibe right now? Because we covered the DevNet Create event that Susie Wee put on, which was kind of like a cloud-native cool event. Kind of grassroots, kind of guerrilla. I love the mojo there. But then you've got the DevNet community at Cisco, which is a robust killer developer community on the Cisco side. How are those worlds coming together? I can imagine that the appetite for the Cisco DevNet teams, the DevNet developer community, is looking at cloud-native as an opportunity. Can you share some insight into what's the sentiment, what's the community vibe, what's going on? For folks that just got to run the networks, I mean this is serious stuff. In the past, they've been like, cloud-native, when you're ready we'll get there. But now there seems to be an onboarding of cloud-native. Talk about the dynamic. >> There has to be, because cloud-native won't wait. And there's a lot of things that the network can do to help you as the run time. The iOAM example is one, but there are a ton more. Again, cloud-native won't wait. They will find a way, and so you have to be able to bring those features at the pace at which cloud-native proceeds. You can't do it on six-month product cycles. You can't do it on 12-month product cycles. You have to be able to respond point by point as things more forward. A good example of this is a lot of the stuff that's happening with server meshes in Insteon. Which is coming really fast. Not quite here, but coming really fast. And for that, the real question is, what can the network do for DevOps? Because there's a synergistic relationship between DevOps and NetOps. >> So you were saying... Just to try to get at the point. So yes, are you seeing that the DevNet community is saying hey we love this stuff? Because they're smart, they know how to adapt. Moving from networks to DevOps. To me it seems like they're connecting the dots. You share some-- Are they, yes no maybe? >> They're absolutely connecting the dots, but there's a whole pipeline with all of this. And DevNet is at the short pointy end where it touches the DevOps people. But to get there, there's a lot of things that have to do with identifying what are the real needs, getting the code written to actually do it, figuring out the proper innovations, engaging with open source communities like Kubernetes so that they're utilized. And by the time you get to DevNet, now we're at the point where you can explain them to DevOps, where they can use them really cleanly. One of the other things is, you want it to come through transparently. Because people want to be able to pick their Kubernetes Helm charts off the web, take the collection of containers for the parts of their application they don't want to have to think about, at least right now, and have it work. So you have to make sure you're supporting all the stuff that's there, and you have to work to be able to take advantage of those new features in the existing API's. Or better yet, just have the results of those API's get better without having to think about new features. >> So they're in great shape. It's not a collision, it's not friction. >> No, no no. >> It's pretty much synergistic. Network guys get the DevOps equation. >> No, we get the DevOps equation, we get the need. There is a learning process for both sides. We deeply need each other. Applications without networking are completely uninteresting. And this is even more true in microservices where it's becoming the run time for the network. On the same side, networks without applications are completely uninteresting because there's no one to talk. And what's fascinating to me is how many of the same problems get described in different language and so we'll talk past each other. So DevOps people will talk about service discovery and service routing. And what they're really saying is, I want a thing, I don't want to have to think about how to get to it. On the network side, for 15 years now, we've been talking about identifier/locator separation. Basically the having an IP address for the thing you want, and having the ability to transparently map that to the location where that thing is without having to... It's the classic renumber your network problem. They're at a very fundamental level the same problem. But it's a different language. >> The game is still the same. There's some language nuances that I think I see some synergies. I see people getting it. It's like learning two languages. Okay, the worlds come together. It's not a collision. But the interesting thing is networking has always been enabling opportunity. This is a fundamental nuance. If you can get this right, it's invisible, as you said. That's the end game. >> Absolutely. That's really what you're looking for. You want invisibility in the normal mode, and you want total transparency when something has to be debugged. The classic example with networks is, when there's a network problem it's almost never the network. It's almost always some little niggle of configuration that went wrong along the way. And so you need that transparency to be able to figure out okay, what's the point where things broke? Or what's the point where things are running suboptimally? Or am I getting the level of service that I need? Am I getting the latency I need, and so forth. And there's been a tendency in the past to shorthand many of those things with networking concepts that are completely meaningless to the underlying problem. People will look at subnets, and say for the same subnet, we should have low latency. Bullshit. I mean basically, if you're on the same subnet, the guy could be on the other end of the WAN in the modern era with L2 overlays. So if you want latency, you should be able to ask for a particular latency guarantee. >> It felt to me that it took the networking community a while to fix things when it came to virtualization. (Ed laughs) but the punch line is, when it comes to containers, and what's happening at Kubernetes, it feels like the networking community is rallying a lot faster and getting ahead of it. So what's different this time? You've got kind of that historical view on it. Are we doing better as an industry now, and why is it? >> So a couple of things. The Kubernetes guys have done a really nice job of laying out their networking API's. They didn't get bogged down in the internal guts of the network that no DevOps guy ever wants to have to see. They got really to the heart of the matter. So if you look at the guarantees that you have in Kubernetes, what is it? Every pod can talk to every other pod at L3. So L2 isn't even in the picture. Which is beautiful, because in the cloud, you need to worry about subnets like you need a hole in the head. Then if you want isolation, you specify a network policy. And you don't talk about IP addresses when you do that. You talk about selectors on labels for pods, which is a beautiful way to go about it. Because you're talking about things you actually care about. And then with services, you're really talking about how do I discover the service I want so I never have to figure out a pod IP? The system does it for me. And there are gaps in terms of there being things that people are going to be able to need to do that are not completely specified on those API's yet. But the things they've covered have been covered so well, and they're being defended so thoroughly, that it's actually making it easier because we can't come in and introduce concepts that harm DevOps. We're forced to work in a paradigm that serves it. >> Okay, great. So this'll be easy, so we'll be ready to tackle serverless. What's that going to mean for the network? >> Serverless gets to be even more interesting because the level of agility that you want in your network goes up. Because you can imagine something in serverless where you don't even want to start a pod until someone has made a request. So there's an L7 piece that has to be dealt with but then you have to worry about the efficiency of how do you actually move that TCP session to the actual instance that's come up for serverless for that thing, and how do you move it to the next thing? Because you're working at an L7, where from the client's point of view, they think it's all the same server, but it's actually been vulcanized across all these microservices. And so you have to find an efficient way of making that transparent that minimizes the degree to which you have to hairpin through things all over the cluster because that just introduces more latency, less throughput, more load on the cluster. You've got to be able to avoid that. And so, by being able to bring sophisticated features quickly to the data plain with something like FD.io and VPP, you can actually start peeling those problems off progressively as serverless matures. Because the truth of the matter is, no one really knows what those things are going to look like. We all like to believe we do, but you're going to find new problems as you go. It's the unknown unknowns that require the velocity. >> So it sounds like you're excited about serverless, though. >> Ed: Usually, yes, definitely. >> So I love serverless too, and I always talk about it. So what is in your opinion the confusion? There are some people who are like, oh it's bullshit. I don't think it is personally. I think it's nirvana. I think it's what people want, what most developers want. There's a server behind it. It's not serverless per se. It's just from a developer standpoint, you don't have to provision hardware. >> Or containers, or VM's, or any of that. >> I personally think it's a good thing. Is it just a better naming convention? Give the people, what's the nuance? Why are people confused? >> I think it's much more fundamental than just the naming convention. Because historically, if you look at the virtualization of workloads, every movement we've had to date has been about some workload run time technology. VM's were about virtual machines. Containers are about containers to run technology. When you get to microservices and serverless, we've made the leap from talking about the underlying technology that most developers don't care about to talking about the philosophy that they do. >> Their run time is their app. Their run time assembly is their code sandwich, not to say the network. >> Just as in serverless, I don't think anyone doubts that the first run of serverless is going to be built on containers. But the philosophy is completely divorced for them. So I'll give you an example. One of the things that we have in VPP is we have an ultra high performance, ultra high scalability userspace TCP stack. We're talking the kind of thing that can trivially handle ten million simultaneous connections with 200,000 new connections coming in every second. And right now, you can scope that to an isolation scope of a container. But there's no reason, with the technology we have, you can't scope it all the way down to a process. So you control the network access at the level of a process. So there's a lot of headroom to go even smaller than containers, even lighter weight than containers. But the serverless philosophy changes not a wit as you have that improvement come in. >> That's beautiful. Ed, thanks so much for coming on theCUBE. We really appreciate your perspective. I'd like you to get one final word in to end the segment. Describe what's happening here because the OS Summit, or the Open Source Summit, is the first of its kind, a big tent event. What's your take on it? What's the purpose of the event? What's your experience? Share with the folks who aren't here what this event is all about. >> It's really exciting, because as much as we love The Linux Foundation, and as much as we've all enjoyed things like LinuxCon in the past, the truth is, for years it's been bleeding beyond just Linux. I don't see the OS Summit so much as a shift in focus, as a recognition of what's developed. Last year we had the Open Source Summit here. We just called it LinuxCon. The year before we had the Open Source Summit here. We just called it LinuxCon. And so what's really happening is, we're recognizing what is. There's actually no new creation happening here. It's the recognition of what's evolved. >> And that is open source as a tier one reality that goes way beyond Linux, which is by the way super valuable at the kernel. >> Ed: Oh, we all love Linux. >> All Linux apps... The only apps are Linux apps. But it's a bigger thing. The growth and scale that's coming is unprecedented. I think a lot of people still are pitching themselves, Stu and I were commenting, that what's coming is going to change the face of software development for generations to come. There's an exponential scale of software libraries coming on board. Up to 400 million was forecast by 2026? >> That sounds conservative to me. (laughs) >> You think so? Well, I mean, just to get the scale. So there's going to be some leadership opportunities for the community, in my opinion. >> Absolutely. And this is where the Open Source Summit actually... I mean, words matter because they shape the way we think about things. So where I think the shift to the Open Source Summit has huge value is that it starts to shift the thinking into this broader space. It's not just a recognition of what's happened. It's a new load of software here for the community. >> This is not a marking then, it's a recognition of what's actually happening. I love that quote. Open Source Summit, brilliant move by The Linux Foundation. Create a big tent event for cross-pollination, sharing of ideas. This is the ethos of open source. Ed, thanks so much for coming on theCUBE. This is theCUBE with live coverage from the Open Source Summit in North America, formerly LinuxCon and all the other great events here in Los Angeles. I'm John Furrier with Stu Miniman. More live coverage after this short break. (electronic music)

>> Host: Live, from Santa Clara, California, it's TheCUBE covering Open Networking Summit 2017. Brought to you by the Linux Foundation. (upbeat music) >> Hey, welcome back everybody, Jeff Frick here with theCUBE. We are coming to the end of day two at Open Networking Summit. We just got here today, it's a great show. Everyone who's talking everything about software-defined networking is here. And along with Scott Raynovich we're joined by Dave Ward, one of the luminaries doing panels, doing keynotes. >> Here we are in TheCUBE. >> And here we are. Dave is the CTO of Engineering and Chief Architect at Cisco Systems. So Dave, great to see you as always. >> Great to see you guys. >> So what's the buzz of the show, you've been here for a couple of days, any surprises? >> No real big surprises to be honest, always there's some great announcements and great launches going on. But really what I'm finding surprising is that this is the sixth year of this conference, can you believe that? So year six from where we started, and I may be the first person to say this, have you ever had anybody in theCUBE today talking about openflow? >> Jeff: No. >> Remember those days? >> Now, nothing against open flow that's not my point, but think about how far we've gone and so. >> Scott: Actually, yeah, Martin was talking about it. >> Course he did. Course he did. He's not going to let it go. (laughter) But love you Martin. But really my point is, look how far we've come in six years. Six years ago we had a protocol, small community, one group working on this stuff, really working in standards, there was no open-source associated with that at that time, now look where we are. Basically the place to do work is now in open-source and come together as a community. So, the buzz for me really is holy shit, this thing is real! There's a lot of people investing a lot of money and time and really trying to work together to improve and build the ecosystem around networking, around network functions, what services are being delivered and building a business off networking again, so networking is back. It's cool again. >> Jeff: Right. Great. And then there's this whole new thing coming down the pike in the form of 5G, and IoT that's just opening up a new opportunity kind of redefine, what are these standards, and how is this going to help push things along? >> Well, it's kind of interesting and so I'm just ripping for a second. When you take a look at where we've come over the last several years and it was SDN controllers and configuring the network. Then it was virtualizing the network. There was a lot of talk yesterday and today about analytics and creating a reactive network. All of that has been built in the those six years and come together in different open-source communities to build those pieces. We've got SDN controllers, projects like OpenDaylight, projects like FD.io, projects like PNDA, P-N-D-A-.io. That's the SDN virtualized network and data analytics piece, but when you get to 5G and IoT, one thing I'll be talking about tomorrow in my keynote, is that there're big blocks missing in the industry. So, let's dial it back to historically, remember when the HVAC contractor logged on to the network and that malware on that laptop stole 70 million credit cards, remember that? >> Yes. >> Still haven't solved that problem yet. And so the reason why I'm bringing this up is what's missing, identity. So we had this notion that networks controlled by IT operators that are going to go in and config and provision that network. Well, we're now to the point where we need to link people and things to be able to drive what that intent is on the network, and whether its buzz words, which is real functionality by the way, of micro-segmentation. HVAC contractor goes into a micro-segment, can't get to the point of sale, can't steal the credit cards. Basic bread and butter stuff we want from the network. This is what SDN is supposed to deliver, virtualized services like firewalls and other sporadic security, we'll just hold that for a second. But that linking of who the person is, what device they're on, where they are on campus, where they are in the world, etc., etc., time of day, whatever the case may be, are now the variables that need to go into the top of this system, into a policy engine that then drives that reactive network. We've made a couple of great strides in six years, but to get to 5G, and in particular to get to IoT, we have to have another couple of major blocks come into the industry to make that work well. Hopefully it's open-source where that's going to go, and it's not just a standards body and not just open-source, cuz we still need things to be manufactured and interoperable and the rest of it. So hopefully these things come together as we've seen the maturing of those two big groups. >> I was going to say, it kind of begs the question, what is the interplay between standards bodies versa or together with open-source projects? Cuz before you didn't really have open-sources standards really set. Set the regs. Now you've got these open-source projects, which have a main channel, they might start forking, there's all kinds of places that they can go, and how do the two kind of work together? >> Well there's been a ton of effort, and coming out of the SDN open-source movement around model-driven networking, and although it sounds kind of geeky, the main way of representing those models is through representation called YANG. The interesting thing about YANG is that's been not only adopted in SDN, as the main object and way of representing the models being converted to network and equipment computes, computers etc. But the IETF has taken that up and really driven a service approach through the IETF which is I want to deliver a VPN service, I want to deliver load engineering on the network versus what we did with SNMP, or what the industry did, which was I'm going to fully distribute this out to all the protocols and all the functions and everybody's going to write a NIB etc., etc. and we know how that turned out. So the craze for model-driven networking, the standards bodies picking this up, IETF, MEF, which is metro ethernet forum, broadband forum, BBF. All these organizations have now taken on that mantra that came out of open-source SDN of model-driven networking and are working towards creating those models so that way we will have a standardized way to program the network. But what's next is the telemetry coming out. Those objects need to be standardized so that way whether it's a Cisco device or somebody else's device, it's actually sending out the same data that can be collected and can be interpreted properly. Does it mean that it's a NIB? Does it mean that it's only going to go over one particular transport? I don't think anybody in the industry really cares whether it's JSON, Google RPC, Protobuffs, Netconf, or any of these pieces, they're all perfectly fine, they have different semantics associated with them, but nonetheless those common objects and common data models have been what has been the key to keeping the industry working together, the common architectural philosophy, and then the standards bodies have thankfully picked that up over the last couple of years. >> Yeah we were talking here earlier, I mean you just threw out a bunch of alphabet soup there and I understand 80% of it, but it does raise the issue we were talking about earlier about these standards development organizations and the IETF, the TM Forum, the MEF. Now we have open-source, so we have the Linux Foundation. We have a lot of these different organizations and I think while you would know better than I as a CTO, people are becoming challenged by tracking and following all this stuff, do you think we need some sort of consolidation of these standards or at least some more unification, we just saw ECOMP and Open-O merge so there seems to be some consolidation. What will we see going forward? What's going to help you as the CTO? >> There's no doubt if there's consolidation, that would be easier to track and easier place to develop, but in reality, Scott, it's 50 shades of YANG. (laughter) >> And the reason why I say that is each and every standards body has done their own specific function, again whether it's Metro Ethernet or its broadband access or its mobility, each one of those standards bodies is redefining themselves to be SDN capable. There's no doubt. If there's a one stop shop, it would be the most optimal way to get something done the fastest, but that's not the way the world works. So actually I think we are going to see a continuous increase of more folks working on this, more foundations being build, etc., etc. Although, what we have witnessed over the last couple days in the last year, is that the communities, the open-source communities in particular, are coming together and trying to integrate the pieces together versus just islands of cool technology that there's a few geeks interested in, no. Thankfully the operators and some enterprises have come in and said I need this stuff to work and I need this stuff to work together and that discipline is actually fundamentally new and different than the way either standards bodies worked or open-source worked in the past. So I'd love to say that there'd be even more consolidation. There's frankly a bit of fatigue over, not saying it's wack-a-mole but you have to chase, you have to really figure out and track where all this stuff is going on in the industry to really keep abreast and understand how wide and how deep it goes. >> It's interesting this trend lately where people are just donating ... The project is just being absorbed into Linux Foundation. So now there's at least kind of a consistency across all these various projects, in terms of the way things are managed, the shows, the communication, and them helping standardize a process to help those projects be more successful in their distribution and adoption in the company. >> Linux Foundation has done the industry a huge service. They understand governance. They've gone through a zillion different experiences of how to build communities. What works well when there's competing factions that need to come together and work, on board marketing team, on board legal team, able to build foundations as necessary, or what's been experimented with over the last couple of years is, if you remember when we started to number these, you need to have a 503C, you need to have a foundation, there was frankly a high cost associated with these. Now, open-source is being contributed there's no foundation, and there's no cost. And so there's a whole continuum of things that the industry, the networking industry I should say, is learning about how to build communities and although this sounds cliche, you may launch a product, but you don't launch a community, you actually have to build it. And it's not all one company that's doing the donating or doing the working and that will produce, that'll create the longevity of that particular project. And that is what the Linux Foundation knows how to do well or at least catalyzed people to come together to do that well. >> Now you mentioned one of the big questions that always comes up with open-source is well how do we make money, right? Cause it's all free. It's like, you know ... >> Are we on Jerry Maguire? What's going on? (laughter) >> Jeff: Free like a puppy. (laughing) >> Still my favorite. >> Free like a puppy, yeah, you guys still got to change the newspaper. So you were on a panel today there was a big discussion about the commercialization and how does, I mean obviously Cisco has to stare at this big puppy in the room if you will, you know. What's going to happen to our licensing model with all this open-source, what came out of that discussion, what came out of the panel about how do you make money in this open-source world? >> So a couple of things, one thing that was discussed was not only how to make money, is which comes first, cost reduction, total cost of ownership, or new service revenue. And really the outcome there, and AT&T, Comcast, and Lightspeed Ventures was also in the panel with me. Needless to say it's a combination of both. If you're coming in with a project and the project is please spend this money so you can save this money, we know how to do that math. We can add up the rows and columns and can understand whether or not money will be saved over time. But the new service revenue really certainly in an enterprise space, is really what's being discussed. In particular, can I get these new services, I need these new security functions, I want to manage all my branches from the cloud or whatever the case might be. So new service revenue is depending on which use case, which technology, which layer. Both of those two balance out and they both are required in the algorithm. Now, can people make money off of it? And the answer is, needless to say, Lightspeed Ventures colleague said, "Hey man, if there's a community "and there's a technology, "you can list off a zillion cases of where that community "is turned into a true company that can provide value-add "and additional IP and move forward." Now, let's move this from just startups to big companies like Cisco or AT&T and Comcast and not only do we all use open-source in our projects, all those companies are contributing to open-source. And in Cisco's case, we're contributing to open-source for a couple of key reasons, one is there are gaps in the industry, which were limiting the industry. So let me give an example. We open-sourced a virtual switch router, which you might think, okay it's Cisco they're going to do something in networking, but the reason why we open-sourced it, and it's a piece that we actually use in our products, was there was not a virtual switch or router that had the scale, performance, or features that enabled the industry to utilize all the capabilities of the hardware underneath, whether it's computer or networking or security. And so the industry literally would have stalled with a limited feature set versus being able to utilize decades of networking knowledge and experience in things that are key and necessary, encapsulations, features, filters, quality of service etc., etc. There's a zillion of these pieces. And so there's a couple different ways, how can somebody make money off of this really is the fundamental question. We contribute into open-source communities and use that open-source to build products as well. And we can do this across video, we can do this in networking, and we do this in NFV, we do this in orchestration in these pieces and we also catalyze an ecosystem around these projects and then potentially around our portfolio as well. And so we continuously expand our ecosystem into startups that are using this technology, advancing the technology, enabling the industry to move faster, and trying to fundamentally create those business outcomes that our customers want. >> I just love that you just innately understand the value of an active community and that really comes through, so but unfortunately the janitors have rolled in, the vacuums are going, the garbage cans are rolling, so before they unplug all of our gear, I want to give you the last word Dave. What are some of your top priorities for 2017? >> So top priorities for 2017 really comes down to working towards filling the gaps I mentioned, identity and policy, but additionally number one, make sure that the automation orchestration policy around networking in a containerized stack is created. So we live through a long era of hypervisors and what it was like to work with open stack and what it was like in open-source and have to invent all this technology. We learned a ton. But it doesn't exist in a containerized world. So for 2017, fill the big gaps in the industry and work towards orchestrating and automating networking, compute, storage, and security in a containerized world. >> Pretty simple. I think that's the answer. I was going to say 42 is usually the answer, but I think that was it Dave. (laughter) >> I love 42. (laughing) >> Thanks Dave, so he's Dave Ward, Scott Raynovich, I'm Jeff Frick, you're watching TheCUBE from Open Networking Summit 2017. We'll see you tomorrow. Thanks for watching. (upbeat electronic music) >> You're also an entrepreneur, right? You know the business, you've been in the business.