Podcast: OPNFV with Red Hat's Dave Neary

Dave Neary is the SDN and NFV community strategy head at Red Hat. In this podcast we talk Network Function Virtualization, who is using NFV, and the open source OPNFV project which will be coming out with its 1.0 release shortly.

Listen to MP3 (0:10:18)
Listen to OGG (0:10:18)

[Transcript]

Gordon Haff:  Hi, everyone. This is Gordon Haff of Red Hat, and welcome to another edition of the Cloudy Chat podcast. Today I'm joined by Dave Neary, who is the SDN and NFV community strategy head. That has something to do with communications, networking. There's lots of acronyms. Dave, introduce yourself, please.

Dave Neary:  As you said, hi, Gordon. Thank you for the introduction. As you said, I'm working on the Open Source and Standards team on SDN and NFV. In that capacity, I've been working particularly closely with OpenDaylight and OPNFV.

Gordon:  We've covered this in prior podcasts, but it's been a little while, and I think this is a new area, still, for a lot of folks. Could you please explain, in reasonably simple English, what is NFV? What does it stand for? Why should you care?

Dave:  NFV stands for network functions virtualization, or network functions virtualized. It's essentially converting hardware that's been used in the telecommunications industry to provide features, telecommunications applications, to provide those in virtual machines instead of physical hardware.

Gordon:  Who would use this kind of thing?

Dave:  Typically, users are communications service providers, CSPs, to add yet another acronym. Your local telco would be using this to power voice, remote access for things like broadband, radio access. Those kinds of things are network functions. In the enterprise, in the data center, other things, like gateways, firewalls, intrusion detection systems can be considered network functions as well. They're applications that sit on your network and through which network traffic flows on its way to its destination.

Gordon:  What's the advantage of doing things this way rather than buying dedicated hardware, which I guess was the historical way you got these things?

Dave:  The first advantage is flexibility, agility, the ability to deploy new applications faster and cheaper than when you're doing hardware‑based deployment. Second advantage is the ability to optimize capex--capital expenditure--and operational expenditure by moving to virtual machines instead of physical machines. By virtualizing both your compute and your network, you make it easier to scale the number of applications that a single system administrator can manage, and you also make it easier to do capacity planning, to scale out your infrastructure over time, because you're no longer tied to physical infrastructure for your core network functions.

Gordon:  Dave, you work on our Open Source and Standards group. As we said at the beginning, you're involved with our community strategy. Tell us a little bit about OPNFV.

Dave:  OPNFV stands for the Open Platform for NFV. It's a project whose goal is to create a production‑style reference platform for network function virtualization with entirely open‑source components. It doesn't make a choice about which open‑source components to use there, except there are a certain number of things that are a given. You're going to need network virtualization, so a software‑defined networking controller. You're going to need infrastructure as a service. The project right now has converged on OpenStack as the infrastructure as a service for private cloud, and OpenDaylight, to a large extent, for the software‑defined networking piece. There's also a project in OPNFV using OpenContrail.

I would say that right now the project has four pieces. The first and the most important is the provision of hardware, on which you can deploy these open‑source components. The second is the deployment tools and integration ‑‑ the glue code, if you like ‑‑ that allows you to deploy all of these pieces together as a reference platform. The third piece is a set of requirements projects, which are going to define what are the needs of the telcos that want to use this NFV platform and how do we fill the gaps in the platform upstream to respond to those requirements. Then the fourth component is testing and performance, so actually testing network‑function workloads on top of this platform to identify gaps and to verify when the changes are accepted upstream, to verify that the platform is meeting the requirements and the needs of telcos.

Gordon:  We're around the time of the first release of OPNFV ‑‑ depending on exactly when we release this podcast. Could you tell our listeners about what's coming in that first release?

Dave:  The first release is really setting the foundational pieces, the building blocks, for being able to drive change. One of the things about OPNFV which is a very important value is that we want to be upstream first. What that means is that we're aware that an NFV platform is made up of multiple pieces, not just OpenStack and OpenDaylight, the two that I've mentioned already, but also data plane acceleration is very important, so projects like DPDK or the OpenDataPlane project are very important. KVM, the Linux kernel, Libvirt, are all pieces of the platform as well.

Optimizing that entire platform for NFV involves tweaking a lot of moving parts. To get those changes upstream, we first need to have a baseline. This first release is the baseline. We have a set of labs on which we can deploy the reference platform. We have two reference deployment stacks that are being included in the release. One is based on the Foreman, and the other is based on Fuel, which is an OpenStack installer, and we have a set of requirements projects that have been created over the course of the first release cycle.

This release is really where we agree on how we work together, and we create the base platform on which we can now start really driving change upstream through those requirements projects and through the testing and performance projects that are getting started.

Gordon:  Once we have this baseline, where do you see things going from there?

Dave:  We've already started to think about the next release cycle of OpenStack. We're working very hard in OPNFV to make sure that when we identify feature gaps in OpenStack, that those feature gaps are documented in a way that will be acceptable to the upstream OpenStack project. We're following the OpenStack specs process. That process is open now for the Liberty release, for Nova and Neutron, which are two very important projects in OpenStack for the NFV use case.

We're working on identifying features that will be implemented in the very next release of OpenStack. We're also identifying other features around, as I said, data plane acceleration, which is a big area, and figuring out how we move to the bleeding edge of those projects. Right now we're using the latest stable release of OpenStack and the latest stable release of OpenDaylight. As we start to get changes upstream, we will want to be able to integrate those as soon as they're integrated upstream so that we can test on the latest version. That's really what's coming, I think, in the next release cycle.

Gordon:  Who's all involved with this effort?

Dave:  A lot of people across the industry. I've mentioned telcos. The network equipment providers, these are the people who traditionally would've been vendors of those hardware solutions I mentioned earlier. Almost all of the network equipment providers are involved in this project. That's companies like Ericsson, Nokia, and Alcatel‑Lucent, who recently merged, Huawei, Samsung, NEC, Cisco. Then we have a large number of software platform vendors, people who are selling OpenStack solutions, and hardware vendors, people who provide the underlying data‑center hardware that you would have in a traditional data center.

Then there are a number of ISVs, independent software vendors, who are specializing either in open‑source virtual network functions or in components of the platform, things like deep packet inspection, the ability to look into packets as they're arriving in the network and identify what type of content is in them and tag them appropriately, or data plane acceleration, which I mentioned, which is the ability to offload data plane processing from the kernel into user space, which is a big accelerator of performance in the NFV world.

Gordon:  I think that gives some indication of how much interest there is out there that we have NFV World Congress coming up.

Dave:  Yes. This is a new event. It's a sister event to the SDN OpenFlow World Congress, which is an annual event that's been going on for some time. Really, it's one of the events that is going to be important in the NFV world. It's the first time it's being run, so we're looking forward to seeing how it plays out.

Gordon:  I also saw a fair amount of NFV presence when I was at the Open Compute Summit a few months ago.

What do people do if they want to learn more?

Dave:  The canonical source is www.opnfv.org. That's the website describing the project, its governance structure and so on. All of the work that the community is doing is in wiki.opnfv.org, and that is a very rich and very fast‑moving source of information on what's happening day‑to‑day in the OPNFV project.

Gordon:  Great. I'll be putting some more information, links, and so forth in the show notes for this podcast. Dave, anything you'd like to close with?

Dave:  This first release, OPNFV Arno ‑‑ we're naming our releases after rivers ‑‑ is the first, I hope, of many. We're looking forward to getting some changes into projects like OpenStack, KVM, and OpenDaylight very soon, to really turn this into the production‑style NFV platform that we hope it will become.

Gordon:  Thank you, Dave.