 Live from Boston, Massachusetts, it's theCUBE, covering OpenStack Summit 2017, brought to you by the OpenStack Foundation, Red Hat, and additional ecosystem support. And we're back. I'm Stu Miniman, joined with my co-host John Troyer. Happy to welcome to the program a first time guest, Shannon McFarlane, who's distinguished engineer at Cisco. Shannon, I was at an event about a month ago in Vint Cerf, one of the guys, seminal creator of the internet and everything. He said during his entire career, did he have any regrets? And he said the one regret that he had is that he wished he'd use IPv6 instead of IPv4. Now, OpenStack didn't make that mistake, right? They started almost from the beginning, working on the IPv6 stuff. Tell us why that was kind of a critical design point for OpenStack. Well, historically, we have always had an issue where in many ways, like a security, that IPv6 has always been an afterthought of someone's deployment. And especially in the development of code. People are either in a rush, or they're under budget constraints, or there's no customer demand for them to generate an IPv6-enabled application. And I think we learned a lot of good lessons early on that with OpenStack, if we're building this new thing that people are going to use, that we should have some level of IPv6 support from the get-go. And so that, I think, was a conscientious decision. Yeah, it's always challenging. Whenever you start something, you're kind of stuck with certain, the technology of the day. I mean, I worked for a large storage infrastructure company and 15 years ago, we're getting questions on when you're supporting IPv6, to roll it out, to get it baked in the code. These things take time. So maybe speak a little bit about deployments, what that means for customers, how it helps them with what they're doing. Well, I think the customer side is no different than the vendor side in that if they don't have something that's really knocking on their door day to day as a problem statement, they don't tend to tackle it immediately or even proactively and it becomes a legacy problem throughout their deployment and IT lifecycle. I think from a deployment perspective, overall in the cloud, that we're really starting to see an uptick because a lot of people were kind of hesitant about retrofitting their existing data center and IT environments with IPv6 and they're like, well, if we're going to move things to the cloud and those cloud things may have IPv6 in them and maybe we're moving from a legacy application framework to a cloud native framework, that would be our first step in the IPv6 because we're building this app infrastructure, potentially in the public cloud, for example, from scratch and so a lot of people on the deployment side have kind of waited to move some of these workloads into the cloud and also adopt IPv6 there at the same time and so I think that's been kind of a part of the momentum there. Well, you talked about an uptick. Can you tell us anything about the current state of IPv6 deployments in the production cloud? Yeah, so there's kind of two views of where things are in the production cloud. So the first one is on the public side. I mean, I know that we have a lot of support in IPv6 around Amazon, Microsoft Azure is getting there, Google is behind in some ways. Supporting it, are people actually using it? But they're gaping in. Yeah, and it's hard to deploy it on the production side if the cloud provider doesn't support it. I will tell you that we spent a lot of time on the open stack deployment side, especially in the private cloud environment where people are absolutely moving to IPv6 in a pretty rapid fashion. So the uptick on the open stack side has been monumental really since the Metaka release. We have really had a huge uptick in people deploying it on the tenant side. I think people don't realize how much IPv6 is really out there. I think a lot of times, my perception, homegrown IT folks in their own data centers, that's what they've been used to, that's what we all grew up with. They don't really see a lot of, they see a lot of IPv4 endpoints, right? A lot of IP addresses. And they don't realize that the whole network, all these phones, it's all running, IPv6 behind the scenes, I might not see it. So what does an IT or network administrator in the enterprise right now, is IPv6 still scary for them? What are they going to need to know to move towards there? Well, I think it's as scary as someone coming back from a CIO or even a CFO perspective and saying thou shalt go do public cloud. I think the fear factor has always been there is we're running out of IPv4 address space. I can't expand my mobile network to your point about the phone. I can't expand into other geographies because there's no publicly routable IPv4 space to be obtained in those spaces. So I think that there's still this driven fear factor that people have around we're running out or have run out of IPv4, you got to go do it. And a lot of it does not come from the internal technology side, as you mentioned. It comes from some exterior force. And it's generally somebody that counts money for a living that generally brings that fear into the IT environment. So I think a lot of it has been defensive driven types of movements. But we see definitely on the IT side now where they're having to deal with mergers and acquisitions where they have colliding IPv4 address spaces even though there's an abundance of it, they do have a collision of those address spaces and that has caused kind of a niche deployment of IPv6 internally. And I think the movement of the ability to have workloads represent your company's products on the public internet has also been a driving factor for people to say, okay, well I need people that are on IPv6 to consume my products and services the same way they were kind of in the oldish or the IPv4 world. And that has also kind of driven the internal teams to start adopting it. There's a lot of talk at the show about hybrid or multi-clouds. I have to think that would have some kind of impact on pushing people towards adoption. Absolutely, so I mean this is what I'm spending quite a bit of my time on these days is really helping customers that have either moved to public cloud and or retracting their workloads for whatever reason, whether it's a compliance or a cost or whatever the reason, but they have consumed the public cloud things they like, API driven, elasticity, self-server's provisioning and deployment of IPv6 workloads on that side and now they're bringing or connecting to their private on-prem clouds and they need to have that level of protocol consistency between the two workloads. And so IPv6 and a hybrid environment has absolutely become top of mind versus the we'll do this first and then we'll do IPv6 later. It's absolutely a part of that. As I turn IPv6 on in my infrastructure, are there still sharp edges there? Should I be able to run it end to end? Is it built into most of the stack at this point? Yeah, so that's an excellent point of bifurcation if you will of how people consume their IPv6 deployment requirements. Right now, the vast majority of the deployments, especially inside the enterprise space has really been tenant facing. What I call kind of the data plane of the cloud where I've got workloads that need to be on the outside world. They could be mobile facing or just generic or even internal facing. And IPv6 has really been the focus in that tenant domain less so on the actual operation or the control plane of the cloud. That is starting to pick up because people have learned in many ways not to put IPv6 on after they deploy a massive cloud but to do it as a core part of their design philosophy. And so I think we're starting to pick up more IPv6 exposure in the control plane and that is really revealing the sharp edges as you said because a lot of things like database endpoints and high availability and replication and backup and logging, those types of things are not well tested in the control plane of clouds. But I think from a tenant perspective, a good deal of our resistance to IPv6 deployment is kind of behind us there. We're here at OpenStack Summit. The topic of OpenStack, one of the themes that's emerging is that OpenStack may be no longer a science project, no longer needs a whole team of Linux scientists to get working. Do I still need a network engineer on my team and how OpenStack savvy do they need to be as you go out to customer deployments? I mean, here we just talked about, well, the network engineer can turn it on but still the infrastructure's team has to know about to make sure their HA works and make sure all their availability tools still work. Yeah, so anytime any individual, whether it's a network administrator or a security admin whoever it is, is touching a defining element of their entire cloud such as the internet protocol that they're running on, you have to be savvy with that. And that goes all the way from a developer to an ops engineer to somebody that actually is paying bills and needs to understand where logging and metrics and those types of things incur some sort of cost structure. So yes, I believe that because IPv6 is a very network facing thing that you need network facing people to deal with that. And I think that what it is exposing back to your sharp edges point is that automation is crucial to what we do in the cloud. And what we're finding is that historically in the IPv6 implementation life cycles, it's been very by hand because people have not had this end to end capability of deploying IPv6 everywhere day one. So they've had to by hand deploy it maybe in some switches and in some routers and some firewalls and there's not been this end to end continuity. Now that they kind of have that exposure and they're moving to the cloud, they need to ensure that that capability exists in the automation tools that they have. And so even the folks that are building the deployment structure of their cloud need to have that capability. So again, that goes right down to network folks that are helping with that. Shannon, are there any special considerations for the service providers that are looking at this space? Yeah, so on the service providers side, there's kind of two things. One back to your mobile point is it is what I'm running my business on. So if I don't have routable address structure to run a telephone from an endpoint perspective, that's a problem. The other one is if I'm a service provider that is hosting someone else's content, maybe a cloud, a public cloud service provider that is routing traffic to and from an enterprise that happens to be in the cloud, they need to consider IPv6. I think I was just at the North American IPv6 summit two weeks ago and T-Mobile and Comcast and these guys were all talking about how IPv6 enabled their work and one of the great talks was around T-Mobile is the fact that if you were a T-Mobile customer today, you are running IPv6 on your handset and if you need to go to an IPv4-only world, they will translate you there. But it's here and it's alive and well and the beauty of what we're trying to accomplish with a real IPv6 deployment is the fact that the user shouldn't know which protocol they're running on. They should just have the same experience that the application developer intended and so I think the carrier side and then the routing of things between two points on the internet are top considerations for the service provider. Okay, Shannon, the last question I have for you. What are some of the conversations you're having around the show? What are some of the main points that you'd want people taking away from this event? Yeah, I think we're focused on what do we do next? I think we've got really strong support in OpenStack today. I mean, we've done a lot of work around getting IPv6 enabled in such a way that we have it in the vast majority of the projects, neutron and the ability to do things in the horizon dashboard and those types of things. But what is it that the customers are still feeling from a friction in deployment? And so I think that the goals of moving forward is how do we make sure that the control plane, the databases and the API endpoints and those types of things have IPv6 support and we need to also, I think, as an entire community understand what people are doing with OpenStack or want to do with OpenStack. And when we kind of understand what their use cases are, then we can kind of bolt on any additional support that IPv6 may be able to help them down that road. And I'm Farlan, thank you so much for joining us. Welcome to being a CUBE alum now and we'll be back with lots more coverage here from OpenStack Summit 2017. You're watching the CUBE.