 From Boston, Massachusetts, it's theCUBE, covering OpenStack Summit 2017. Brought to you by the OpenStack Foundation, Red Hat, and additional ecosystem to support. And we're back. I'm Stu Miniman with my co-host, John Troyer. Happy to have on the program, not one, but two Cisco Distinguished Engineers. Jerome Tollette, who is in the Cisco Chief Technology and Architecture Office, and Ian Wells in the Cisco Cloud and Platform Services. Jerome, let's start with you. Tell us a little bit about your role inside of Cisco, what you work on. Yeah, so Cisco is very much involved in an open source project called fd.io, fastdata.io, and one of the projects we are developing in this context is VPP, vector packet processing, which is a very, very fast data plane. And my goal is really to integrate this software into value stacks, including OpenStack, to make NFVI very fast and usable by service providers. And I'm working on that with Ian. Okay, so Ian, all of us in technology have this problem, like when our parents ask us what we do, it's like, I actually have a Cisco shirt that says, blah, blah, cloud. And my mom's like, oh yeah, you talked about that cloud thing before I heard about it on national public radio. So Jerome told us a little, tell us what you work on. Yeah, when I talk to my mom, I try and avoid that topic, it's just easier. But yeah, so I work on, well, it's been all things cloud over the course of time, but in general, it's revolved around NFV from before it was even called NFV. And nowadays, I'm working on Cisco's NFV infrastructure product. I also work with Jerome, I write the code, he sits there and tells me I should write more code on making sure that VPP works with OpenStack so that we can have a decently fast data plane for using with NFV workloads. Okay, and we talked to Lutuck a little bit earlier. Obviously, you know, Cisco's long relationship with the service providers, maybe you're saying before it was even called NFV, give us the quick thumbnail history of this evolution because last year it felt like, wow, NFV, there was that SDN and then NFV and now NFV was like, oh, the killer use case of OpenStack. Yes, and it's been a strange and sort of turbulent history. So I think everybody in service providers that understood for quite a while now that they spend a lot of money on appliances that do one specific job. And getting those appliances out into the network is a very expensive and long-winded process trying to test it in the lab and generally deal with the failures and the consequences and then nagging of companies like us, in fact, when it doesn't quite work. So what we're trying to do is basically turn it into nothing but software for at least the appliances where that works. Some of them are fundamentally so fast that ASICs are the only option. And that's been seen by, well, various people in service providers for actually an extended period of time, maybe five years, maybe a little bit more at this point in time. And we've come a long, a long way, I think. It's elements of reliability and maintainability are needed for this, as well as simple straight line performance. And one of the things that people forget is that moving packets around, that's going to be your customer's internet traffic, you need consistency as well. You need to see consistent rates of hopefully zero drop, consistent speed, consistent bandwidth that doesn't change over time but actually always maintains that service agreement that you have with your customer. What's the current state of OpenStack and our current release now with regards to kind of a minimum level of NFE functionality? Are we there yet? Are we still headed there? Can I, I mean, we see people, obviously one of the themes of the show is right, people are to people and service providers deploying this in the real world right now. I mean, are we 50% of the way there? Are we 80% of the way there? So I think, well, it depends on your measure. It's a kind of complicated question. We can do things today with OpenStack that get you really fast performance in service provider networks. We've done this. I mean, we have products working in service provider networks that do exactly that. We all wish for a little bit more of something. I think at this point it's interesting to notice that what everybody wishes for is quite diverse and it's a little bit here and a little bit there. I think on the running of virtual machines we've generally got the performance that we're going to get and the consistency. There may be one or two niggles about the way resources are scheduled and allocated that we'd like to fix nothing too big. On the networking side of thing, it's always I'd like more functionality. You'll hear people talk about service chaining, MPLSBGP comes up quite regularly which is really integration with the rest of the service provider network. But the problem is service providers are snowflakes. Their networks are all slightly different and all slightly special to them. And so the list of features they want, it's very different from one to the next. And that means that we have a ways to go to really address the kind of general purpose model that would suit everybody. But right now you can get job stuff, certainly can. What is new with this project we are working on called the VPP and networking VPPs. Not only we are bringing very high performance but also predictable performance. When you're a service provider, you really want to have predictable performance which is something I think new in the software networking in OpenStack those days. Data is so important in people have been talking about from the big data through to the AI, ML and thing. I have to think that that fits into kind of the FDIO, VPPPs, what is the stuff you're working on enable from kind of the data and application space? Yeah, so I really see two different use cases at a high level for OpenStack. One is really classical cloud applications and we definitely see a trend for more microservices and that will generate way more connections than what we have today. If you have a look at number of connections in probably the next two, three years, you will probably multiply number of connections by probably a factor of 10 or 50, you know, something like that because of microservices. So that's a given problem. And then you have another problem which is NFV, right? And we are speaking about service providers and how we can increase the throughput and bring this predictable performance. And I guess VPP can play a role in both space but really what we are starting with is this NFV space right now where we need an NFVI, a robust NFVI which is without any hardware. And yes, will there be a loop with analytics? Of course, yes, of course, yes. So we have other projects beside that, one of them is called PENDA, P-A-N-D-A and that's a project for data analytics, another open source project and of course there are bridges between these two things. The important thing then will be how can we use this analytics data to reconfigure the network. But that's very futuristic thing. Right now what we need to deliver is something that works well, that is fast and reliable, that is not a toy. The rest is more like the future. It's funny, we always talk that people's perception takes a long time to change. We're talking a lot of software. I mean Cisco sells a lot of boxes, right? I mean, talk about how your software fits into the overall portfolio. As I said, perception takes a long time to change. So we understand, we've talked to Cisco for many years here at OpenStack and MiniJs. And for what it's worth, it's also complex because Cisco is seen as externally and possibly also to an extent internally a hardware company and what we're doing here is we're putting together software to do what some of that hardware used to do and to do different things and I think it's a change in mindset for both customers and us inside Cisco as well. But yeah, I mean, we talk about one of the issues we run into particularly in the NFV space is that it's a stack. There are VNFs, there's orchestration which everybody loves to talk about. There's also this platform that it runs on. The platform is honestly the unsexy part of this. It would be lovely to say that everybody thinks it's great that this is what you work on, but no, it's just a baseline. It's necessary, but it's just a foundation of a house. Nobody looks at the foundation and says that's a lovely foundation you've got there. We need all of these things to make something work and we also need to recognize, I think, that we aren't going to build every VNF in the world. The thing that you're doing with the network is going to be different and it's going to come from a different vendor and you have to understand that in a network it's going to be a mix of vendors to get your job done from the service provider's perspective. It's a different way of working and we're making some progress there, I think. It's not something you can do from within one company. It involves conversations between vendors, between vendors and service providers to kind of get the message across. Well, speaking exactly to that, right, we're here at the OpenStack Summit. We actually now have split off the design and technical portion of the summits from the more kind of business and human networking portion of the summit. So I kind of miss the hoodies walking around here. I was, this is my first summit, but I wish, there are a lot of hoodies, a lot of technical folks. For both of you, how long have you had involvement in the OpenStack community and how did you see the community and those vendors coming together, kind of both changing what you're doing and maybe accelerating the progress of your projects? So it's interesting. I've been coming to the summit since San Francisco, which is, I think, March 2012, something like that. That was my first and it was like two weeks after I first heard of what OpenStack was. So it was thrown in at the deep end, although thankfully at that time, Cisco had quite an involvement with the networking side of things even then and I was brought up to speed with a lot of help from the people I worked with or in fact didn't work with, but newly found at the summit in fact. I think what's changed is, you know, back in those days you had, it was a small community of people who kind of understood what they were trying to do from just making a cloud perspective. And those of us who'd just come into it, trying to work out what was cloud, quite honestly, in those days. Actually, it's interesting to see how that's involved over this course of time. So moving from then to now, you actually saw this, again, networking people, service providers come in with roughly the kind of what's a cloud approach and getting sometimes a bit of a sharp, sharp, sharp to get educated, but they're very much members of the community and participants at this point. As for the way the summit's changed with the technical tracks being split out, I haven't really got a feel for that yet, but it's definitely a different atmosphere now than it used to be. Part of it, perhaps, because I tend to end up in the technical tracks and then kind of kept away from the normal sessions of things. So it's been a kind of a change to get back into that for me. So I've been involved in OpenStack community since 2013 or 2014, if I remember correctly. And the big change I see is that now NFV is becoming a first class citizen for this community, right? That was not the case. In the beginning, people were kind of ignoring NFV. It was all about cloud. And now it's quite the opposite, right? NFV is becoming very, very important. I think there is a bit of pressure coming from containers and so on. And the community now needs to better articulate what is the strategy with the container? Is it competing? I guess it's not. Is it, what is the complementary? So that's something new. So the big things are that, right? More containers and NFV is becoming very, very important. Jerem, you've participated in both in standards and in OpenSource. How do you see that changing in your? Yeah, that's very important. I mean, I see OpenSource is becoming kind of a standard organization now. So that's really interesting, right? So you have many things which are not like going through the standard normal way of standardization but ends up being OpenSource, right? And becoming a de facto standard, which OpenStack is, right? So that's very, very interesting. However, sometimes, I mean, we see some limits to this model. Like OpenStack is moving very, very quickly on some specific things. And it's not always easy, right? To have stable foundation and how you have a strategy for evolution from one version to the other. You know, that creates some issues as well, right? Ian, we're all trying to deal with this massive pace of change that's going on. How's that affecting you and your customers? It's a problem. I mean, for the longest time, it was always, so how do you, oops, excuse me, how do you deal with a customer who wants version A when you're doing something sort of A minus one, A minus two, you need breathing space to actually get jobs done. So continually upgrading was always a problem. I think we've come to the point now where actually the community is a dressed upgrade a lot better. So that's become a much more manageable problem. But it's, you have to be selective. You have to work out for a given customer base what's going to work for them, what the features they need are, and have honestly a dialogue or conversation with them to say what do you need, what do you not need, have you thought of doing something a different way? I sometimes complain about this, but I think it's important for customers to recognize that beyond a certain point of talking to product managers and talking to sales engineers, they do need a dialogue with the engineers who work on products because sometimes we can offer different solutions. Sometimes we can say to you maybe, maybe this would work for you better or maybe this would work for you and it might not be better, but it's certainly a lot cheaper and more convenient for you to work with. Again, it's almost a negotiation in terms of what the technology can provide you with the effort that it's going to take to actually get that into your industry. Moving over to the enterprise for a moment. Okay, so there's a lot of enterprise IT engineers that are going to have to consume, use, and manage the network core that you guys are building now. Already in the data center, we see a lot more east-west traffic, right? Some of that's microservice based, some of that is just kind of the way applications are built these days. That's already affected how I'm designing my data center. We are increasingly talking about hybrid and multi-cloud architectures, so I'm guessing there's going to be a lot more, just like there's more east-west traffic, there's going to be a lot more inter-cloud traffic. I'm not enough of a network engineer to know what you end up calling that. So, I mean, in five years, the operator, the end user operator at the enterprise, what kinds of things are they going to have to be managing in terms of performance, in terms of stability, in terms of inter-cloud connectivity, back to their apps that may be sitting in three or four different clouds and talking to each other? So, I think from a communications perspective to start there, because obviously, you put distance between two clouds and communications are your biggest problem. Then it's a question of what they need from that connection and how they express that. And quite honestly, this is back to SDN. SDN's been around longer than cloud or at least talked about longer than cloud, so you'd hope it was a solved problem, but I don't think that's quite how this works. It's a story in progress. Yeah, exactly. I think we all understand that there are many things that it could potentially offer to us. I think we're working through the process of trying to get that out of the technology. And that's more complex when you effectively put an ISP between you and your remote cloud, but not between you and your local cloud. So, how do you deal with the ISP to say, I want a certain quantity of bandwidth. I want a certain latency while talking between clouds. Something we can deal with, but we need to get that expressiveness of interface and ideally a programmatic interface, not picking a phone. Policy-driven, automated. I don't want to have to go in and negotiate with each ISP or tweaking routers at each different area. Absolutely, you can see this. You have a shopping list in your head. The ISP does as well. They absolutely don't want to be tweaking routers one by one to make this happen. They want it just to happen because a customer says that's what they want and has paid the money. That would be great, thank you. And then within the cloud, the east-west traffic to some extent, it's the same problem. I'd like to be able to have guarantees. What we generally do in, again, I'm not a data center guy, so I'm going to hand wave here, but what we try and do in data centers, we try and make sure there's more bandwidth than we need so that bandwidth is never in short supply. But that's not practically speaking true and it's certainly not cost effective. So ultimately, things like allocating bandwidth to certain things that are critical and need the bandwidth and not so much to other things really helps out. And again, within a big enough enterprise, obviously you've got multiple data centers or multiple locations. And then the inter-cloud nature of what's going on starts biting again and you've got this question. Well, and the hope, I guess, then NFE is going to allow these service providers to provide you a control plane that to be able to manage precisely those sorts of policies. Yeah, and it crosses SDN and NFE. NFE can be the more complex functions that you're going to need for things like firewalling, for any kind of snooping. SDN is theoretically the managing of cloud bandwidth in the fabric, but it's a quite story, yeah. On the enterprise side, I would say a couple of things I would like to emphasize. We are speaking about different technologies, containers, OpenStack and so on. So probably decoupling the SDN from a given technology is something important, right? So we see new technologies like Oven or like Open Daylight, which are really SDN and controller-based things and I guess that will be critical to decouple that from OpenStack or from Kubernetes so that the same network can be used over and shared by different technologies. At the end of the day, nobody will only deploy an application only based on containers or only based on VMs. That will be a combination of different things. So decoupling and SDN from the orchestration and so on is probably something important. The other thing I would say is it's very interesting to see that today we are still thinking in terms of physical hardware. Look at what we are doing with even VPP, VNF and so on. We are speaking about the virtual switch or virtual router. So think in terms of two containers sitting on the same physical compute nodes, right? Why do you need to create a packet? Why do you need to do crypto? Why do you need to do VXLAN when the two applications talking together are sitting on the same compute node? So you are spending a lot of CPU cycles, a lot of energy just to do something which is useless, right? Packetization, TCP, crypto, VXLAN, all these things are absolutely useless when you just have two processes which have to talk together. So there is probably, and the reason why we are doing that is because we have imported into the virtual world all the concepts that we use in the physical world, right? Which was probably very useful to start with but now I think we can do something a bit more efficient and move from packets to what I call communication. Like you have two applications talking together and they just have to share memory. They just have to communicate with the stream. Probably with IPv4, IPv6 address to identify the endpoint but certainly not go to these useless operations on every packet. That's something important, yes. Well, Ian and Jerome, thank you so much for all the updates, VPP, NFVI, lots of other TLA's and 4LA's to go through here and we'll be back with more coverage of OpenStack Summit. You're watching theCUBE.