Set of screw and bolt heads

Do SDN and NFV Standards Really Matter?

Set of screw and bolt headsStandards are generally accepted as good — I’m not sure if they’re in the same class as motherhood and apple pie, but they’re close. One example of the goodness that is associated with standards is that it is common for vendors to claim that their solutions are “more open” than that of their competitors, in part because their solutions are built on industry standards. Given the halo effect that surrounds standards, am I totally out of it when I suggest that right now, standards are almost totally irrelevant to the development and implementation of SDN and NFV?

I’m not using this blog to flog OpenFlow. As most people know, the OpenFlow protocol allows a SDN controller to control the forwarding tables in a switch or router. Whether you like OpenFlow or not, that’s a relatively well-defined problem statement. As a result, it makes sense to develop a standards-based way to solve that problem. However, there aren’t a lot of other well defined problem statements relative to the development of SDN and NFV.

Consider the case of the North Bound Interface (NBI) that exists between the SDN controller and the business applications and network services that utilize the controller. Over the last few years, this interface has been the subject of great debate in the SDN community. Proponents of standardizing argue that the lack of standardization impedes the development of SDN because without standardization application developers won’t be very motivated to develop applications that use the controller. The argument against standardization is that we are so early in the development of SDN that we don’t really know what should go into the NBI, and hence it makes no sense to standardize it. I recently talked with Sarwar Raza who is the chair of the NBI working group that was formed a few months ago by the Open Networking Foundation (ONF). I admit that I thought the goal of the NBI working group was to develop one or more standards for a NBI. Sarwar pointed out that standardization was not a short-term goal of the group, and that “Our goal in the next year is to formalize the framework along with the information and data models and then iterate some with code before we even start a standards discussion.”

One of the groups that is most associated with the development of NFV is the European Telecommunications Standards Institute (ETSI). Just because of the fact that the word standards is in their name, I assumed that they are developing NFV-related standards. One thing that ETSI has done is to publish a white paper in which they attempt to standardize the NFV terminology and concepts. They also published a document in which they attempt to define a high-level architectural framework for NFV. While both of these activities are very important, terminology, concepts, and architectural frameworks are not what most people think of when they think of standards.

So has ETSI given up on creating what we typically think of as a standard? I don’t think so. ETSI has identified nine potential use cases for NFV. The organization is currently focusing a lot of their time and attention right now on conducting twenty-three Proof of Concepts (POCs) that are based on those use cases. The approach they are taking is similar to the approach that the NBI working group is taking, and it goes right back to the question: do SDN and NFV standards matter? Yes they do matter, but only once there is a well-defined problem statement that the standards can address. What the NBI working group and ETSI are saying is let’s spend some time developing prototypes and implementing POCs so that we can better understand the issues, and maybe then we can initiate a more common standards process.

About the author
Jim Metzler
Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.