OPNFV Summit 2016

I was fortunate to be able to attend the Open Platform for Network Function Virtualization (OPNFV) 2016 summit in Berlin.

First OPNFV event

This was my first OPNFV related event. To be honest prior to attending I wasn’t quite sure what OPNFV really was. I mean, I knew it was related to NFV in general, but what were the actual goals of the organization? After attending I feel like I have a better idea of what OPNFV’s purpose is, and also the realization that it is still early times with regards to this entire area of cultural, business and technological change related to NFV.

Design Summit

The first two days of the summit were the design summit. Like OpenStack, OPNFV uses its summit to also provide a place for the contributers involved in OPNFV to get together face-to-face and discuss the technical aspects of various projects.

OpenStack Operators Telecom/NFV Working Group

Recently I have been trying to start up a new working group within OpenStack specifically dealing with OpenStack Operators and how they are designing, deploying, maintaining and operating OpenStack NFV clouds. For those that don’t know, there is an OpenStack Operators mailing list, and this group has meetups between OpenStack summits, and as well a portion of the OpenStack design summit time is dedicated to it.

During the OPNFV design summit we were privileged to be given a time slot to have a “birds of a feather” meetup for OpenStack operators. Unfortunately the BoF was lightly attended. Like I mentioned previously, this is a new group and it’s going to take some time to get going. I feel like over the next year or so we will see an explosion of NFV systems installed which are based on OpenStack and thus there will be a considerable number of OpenStack operators managing these clouds, and they are going to want a place to discuss issues with their peers. (I hope.)

My hope is that like other OpenStack working groups we will be able to shepherd positive changes back up through the OpenStack community, be it through working with OpenStack projects to meet NFV related requirements, or via documenting common deployment designs, and similar items.

If you, or anyone you know, would like to participate in this working group we have bi-weekly IRC meetings.

Tacker and Service Function Chaining

OpenStack Tacker is an interesting project that initially started under the OPNFV umbrella, but has now migrated to be beneath OpenStack. Tacker is a “generic virtual network functions (VNF) manager.”

I had the chance to interact with the project technical lead (PTL) for Tacker a couple of times and it was fascinating to hear their story of how the project is maturing and navigating the various open source communities it interacts with. Time and time again I hear how development is largely a social interaction, not just writing code in your basement or cubicle. It takes a lot of work to understand various communities guidelines and cultures. In fact a large component of OPNFV is around understanding how best to work with upstream projects like OpenStack.

One of the major requirements Tacker has from OpenStack is the need for service function chaining (SFC). There is a project within OpenStack now, called networking-sfc which will enable SFC in Neutron, and thus it will be usable by Tacker. With SFC being enabled in Neutron the ability to move workloads from one cloud to another irrespective of the underlying networking technology will be possible. Interoperability is important.

Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet’s destination IP address. It is most commonly used in conjunction with Network Function Virtualization when recreating in a virtual environment a series of network functions that would have traditionally been implemented as a collection of physical network devices connected in series by cables. – networking-sfc

Tacker, as well as SFC, provide important NFV-related functionality and it will be great to see how they are used by the community.

Open vSwitch, OpenDaylight, and OpenStack Performance

There was a good presentation by HPE regarding Open vSwitch (OVS) performance when using OpenDaylight (ODL) in OpenStack.

The two main points in terms of performance were:

1. Use Open vSwitch DPDK
2. Using ODL allows for 110x improvement in layer 3 routing versus standard OpenStack layer 3 (ie. DVR)

The 110x improvement is pretty amazing. From my impression of the presentation, it wouldn’t be possible to use DVR if performance is a requirement for your particular use-case. Note that this was layer 3 only, not layer 2. That said there was an improvement in layer 2 performance, just not as drastic.

In the presentation some reasons for this lack of performance in “vanilla Neutron” were listed as:

1. Linux qRouter performance issues
   
2. Low performance of additional bridges and iptables
   
3. Connection from OVS to the qrouter is not accelerated by DPDK.

More to look into here.

Main Summit

After the first two days of the design collaboration, the summit moved on to a more standard presentation and panel model.

OpenStack Community Panel

I was lucky to be on the OpenStack community panel session and we talked a bit about where NFV is going in terms of OpenStack and what we see happening, or would like to happen, in the future.

I spoke a bit about the OpenStack Operators Telecom/NFV working group, and I’m hoping that participating in the panel helps to get the word out, so to speak, about the group. The Neutron and Tacker PTLs were the other members of the panel.

CENGN

I would be remiss if I didn’t mention the Canadian non-profit CENGN which has been involved with OPNFV from early on. They were the first associate member of the OPNFV. For some reason Canada is usually well behind the technology curve, especially around networking, perhaps due to the void left by the utter (and sad) collapse of Nortel. With CENGN it seems there may be some recovery on the horizon in Canada, or at least an example of an organization designed to push the bleeding edge into Canadian business.

Mikko Hypponen - Complexity is the Enemy of Security

How many of the Fortune 500 are hacked? 500. – Mikko Hypponen

While the talk was titled with regards to complexity, he didn’t really get into the complexity around NFV, other than calling this summit “the acronym conference”which is both funny and accurate. He did mention how Heartbleed and Shellshock have led to the creation of the Core Infrastructure Initiative which irregardless of the silly names given large vulnerabilities is an extremely positive change.

The Hitchhiker/Hacker’s Guide to NFV Benchmarking

There was a short and information packed presentation on benchmarking. There is just a ton of information in the slides and I heavily suggest going through them if you need to benchmark your NFV deployments.

NetReady, Gluon, Service Function Chaining (SFC)

NetReady is a OPNFV project to identify gaps in networking requirements (at this point mainly dealing with OpenStack Neutron) and write prototype code to fill those gaps.

Gluon is a project that allows those prototypes to be easily created, but it does so outside of Neutron by manipulating Nova port binding and, as far as I can tell, avoiding Neutron entirely, which is not great, but I can understand the need to be able to prototype and fail fast.

SFC was all over the OpenStack summit in Austin, and it’s no surprise to see it highlighted at the OPNFV summit as well. I watched a good presentation/demo on it, and there were a lot of questions about competing implementations, from Huawei doing something in ONOS, Redhat doing something with ODL, networking-sfc, etc, etc.

Machine learning

There was a great, but short, presentation on applying machine learning to network scaling strategies.

One thing I realized from this presentation, because they specifically stated it, is that reactive scaling is not enough–you need predictive and reactive in order to scale properly, and one way to get predictive is to use machine learning.

Another important point made was the lack of production data available for use in research and development of predictive scaling. They are hoping the OPNFV can help with that somehow.

Berlin

Berlin is an amazing place. Fortunately it’s still one of the less expensive cities in Europe which means artists can afford to live here and do interesting things. The weather was great. I went around and, of course, visited many tourist attractions, but my favourite thing was a fascinating bicycle race called the Fixie 42 which is a 42km race on fixie bikes. The average speed for the fixie race was 49 km/h; they were practically flying. Also while in Berlin I was fortunate enough to see Beck live!

Conclusion

Overall, I feel attending the OPNFV summit was extremely valuable. OPNFV is only in year two–it’s early times. Most telecoms are only now getting started with NFV. The learning curve, both cultural and technological, is considerable. Recently I heard a quote along the lines of “telecommunications is too important to leave to Telecoms” and in some respects this is what OPNFV is doing.

Further, I’d like to get involved in OPNFV more. Unfortunately I missed the two security presentations, but there is an OPNFV Security group and that might be something I look into helping out with. OPNFV is still a small organization, and while I expect it to grow over time, much like OpenStack has, now seems like a good time to be involved.