This blog comments on a variety of technology news, trends, and products and how they connect. I'm in Red Hat's cloud product strategy group in my day job although I cover a broader set of topics here. This is a personal blog; the opinions are mine alone.
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.
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,
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
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
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.
Who would use this kind of thing?
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.
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?
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.
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
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.
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.
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?
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.
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.
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.
Once we have this baseline, where do you see things going from there?
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
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.
Who's all involved with this effort?
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
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.
I think that gives some indication of how much interest there is out
there that we have NFV World Congress coming up.
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.
I also saw a fair amount of NFV presence when I was at the Open Compute
Summit a few months ago.
do people do if they want to learn more?
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.
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?
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.
I'm in the cloud product strategy group at Red Hat. Prior to Red Hat, I wrote hundreds of research notes, was frequently quoted in publications like The New York Times on a wide range of IT topics, and advised clients on product and marketing strategies. Earlier in my career, I was responsible for bringing a wide range of computer systems, from minicomputers to large UNIX servers, to market while at Data General. Among other hobbies, I do a lot of photography and enjoy the outdoors.