Stamp reading "Approved"

How will SDN and NFV Standards Really be Developed?

Most people like standards because they believe that standards lead to something they really want, which is interoperability. I have been a member of three different standards committees, one of which was sponsored by the European Computer Manufacturers Association (ECMA). At one ECMA meeting, a 45 minute discussion broke out about the proper format for a footnote.

I get the fact that people like standards, and I also understand that one of the potential advantages of SDN and NFV is they help organizations become more agile. But I have to ask: Are the companies that are driving the evolution of SDN and NFV driving an agile process?

Who’s Driving the Evolution of SDN and NFV?

Although there is some overlap, the organizations driving the development of SDN and NFV fit into three broad classes:

  • Industry groups such as the ONF and ETSI. This class of organization develops use cases, best practices, architectures, frameworks, APIs, vocabulary and POCs. I like how ETSI establishes Industry Specification Groups (ISGs) such as the one it established for NFV (ETSI NFV ISG). ETSI ISGs have a two year life cycle. After that they either establish a charter for a new phase of the ISG or they go away. The phase 1 charter of the ETSI NFV ISG focused on requirements and the charter for phase 2 focuses on implementation.
  • Standards Developing Organizations (SDOs) such as the IETF and the Alliance for Telecommunications Industry Solutions (ATIS). Unlike an ETSI ISG, a SDO typically doesn’t have a predetermined life span. As such, they tend to move slowly and focus on technical elegance. I have nothing against technical elegance other than sometimes the pursuit of technical elegance results in a process that is anything but agile. For example, a review of their Web site shows that the IETF currently has 29 Internet drafts in varying stages of completion focused just on the topic of service function chaining. There may be some fantastic technology hidden inside those 29 Internet drafts, but I have to believe that having that many Internet drafts on that one topic is going to slow down getting anything of value into production in the near term.
  • The open source community including organizations such as OpenDaylight and the OPNFV, both of which are member of the Linux Foundation. The general charter of this group of organization is captured in the initial announcement that the Linux Foundation made about OPNFV. As part of the announcement the Linux Foundation declared that OPNFV will establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of NFV and ensure consistency, performance and interoperability among multiple open source components. The Foundation also stated that because multiple open source NFV building blocks already exist, OPNFV will work with upstream projects to coordinate continuous integration and testing while filling development gaps. The bottom line being these groups are developing platforms that over time will become quite feature-rich and many companies are likely to build their offerings based on these platforms.

How Will This Play Out?

Some of the industry groups I have talked to are looking to establish a close relationship with the open source community. One example of that is the ONF’s northbound interface group. They hope that some component of the open source community will decide to implement the interfaces they develop.

It is unclear, however, how the relationship between the SDOs and the open source community will develop. One option is that after a group such as the OPNFV has make progress on creating an open source reference platform for NFV, that one or more SDOs will establish working groups to create standards for some of the key tasks that are part of the reference platform. However, since SDO working groups have historically taken years to create new standards, another option is that whatever functionality is part of the reference platform will become defacto standards.

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.