
Summary Bullets:
- For the broadband network, NETCONF deserves strong consideration for its ability to work from flexible data models (YANG) and control all devices in the service chain.
- NETCONF, initially standardized in December 2006, has managed thousands of routers and switches, and it works well with SDN.
- OpenFlow versions 1.4 and 1.5 appear to have the requisite functionality needed for WAN device management and control; however, although standardized in October 2013 and December 2014, respectively, vendor commitment to date appears tepid.
Since the beginning of the SDN and NFV discussion a few years back, proponents of OpenFlow have been behind the movement to control all devices in the network. This has unquestionably been the case within the confines of the data center. OpenFlow appears to solve data center issues well, even the early 1.0 version which is widely deployed, according to many sources. However, consider the many cases where, in order to provide an end-to-end WAN service or provide inter-data center connectivity, the use of OpenFlow falls short, at least until now.
Extensions contained in OpenFlow versions 1.4 and 1.5 no doubt address many early limitations, such as transactional actions (e.g., commit/rollback) and dealing with multiple entities that can monitor and/or control the same device. OpenFlow 1.4, for example, adds a new set of port properties to provide support for optical ports, including fields to configure and monitor the transmit and receive frequency of a laser, as well as its power. However, there are very few network vendors that have announced adoption and/or implementations to date, even though the specifications were released in October 2013/December 2014. OpenFlow 1.5 furthers the ability to support a dynamic set of network services and devices and adds a level of extensibility (outside of the standard) to aid vendors in adding new capabilities. Having said that, OpenFlow 2.0, which will add more flexibility and capabilities, is now in the works, injecting some hesitancy to adopt prior versions of the protocol, especially for WAN device support. In all fairness, OpenFlow has made astonishing progress since its inception in 2009, but the capabilities needed for WAN device configuration and control are recent additions.
NETCONF, on the other hand, was established by the IETF in December 2006, after a gestation period that began in 2001 at an IETF meeting to discuss the shortcomings of the management standard of the day, the Simple Network Management Protocol (SNMP), which by this time was anything but simple. NETCONF’s counterpart, YANG, defines the structures and data definitions (the data model) as well as device state; its relevant standard was published in October 2010 (RFC 6020). Used together, they can help automate configuration management and monitoring for a large population of WAN devices (routers, switches and transport gear). Vendors such as Cisco (which now owns NETCONF pioneer Tail-f), Juniper, Ericsson and others have been early proponents, thereby establishing momentum for the technology.
For 2015, we expect to see OpenFlow 1.4/1.5 deployments begin, and for NETCONF/YANG to continue to be used by traditional WAN equipment vendors since it delivers the management and control needed in an SDN environment; however, we also expect to see certain equipment vendors adopt the later versions of OpenFlow, primarily 1.4/1.5. So, for the short haul, both protocols will be continue to be front and center as the blurring between cloud, data center and the WAN continues.