Primary Blog Author: Shangxin Du, Technical Marketing Engineer at Cisco Systems

With the growing complexity of the modern network, automation is becoming more important. NETCONF is one of the widely adopted protocols by networking vendors and customers among all programming interfaces. Alongside NETCONF, YANG provides a powerful, standardized modeling language to complement the NETCONF protocol. In practice, interoperability between service orchestrator and network devices provides flexible mix-and-match solutions based on customer's deployment choice

Multi-vendor NETCONF interoperability testing

Although EANTC (European Advanced Networking Test Center) has been holding MPLS SDN interoperability testing for quite a few years, NETCONF/YANG interoperability test usually was only a small part of it. In 2020, EANTC did their first test that focused on NETCONF SDN management. Cisco is proud to be a participant conducting a full set of test cases, including basic system management to L2/L3 VPN on top of MPLS and Segment Routing.

All tests were carried out remotely due to  the Covid-19 pandemic, and test setup and results are demonstrated and described in the EANTC white paper.

NETCONF and YANG

NETCONF was developed by NETCONF working group of IETF back in 2006 and published as RFC 4741, then revised in 2011 and published as RFC 6241along with other RFCs, such as using NETCONF over SSH (RFC 6242) and NETCONF based notification (RFC 6470). Today, NETCONF has been widely adopted by network vendors and users. It has become the first choice, when users want to implement an automated infrastructure, especially in multi-vendor deployments.

NETCONF only defines the communication protocol between the server (usually orchestrator) and the client (usually the network device), YANG (Yet Another Next Generation) was made to model the configuration and state data that can be manipulated by NETCONF. It was first published in 2010 as RFC 6020. Further, since YANG is an extensible modeling language, it is not only used by NETCONF, but also by other protocols like RESTCONF. And with the growing need to extend existing encoding methods like XML, YANG has evolved into version 1.1 as defined in RFC 7950.

OpenConfig YANG Models vs Device YANG Models

OpenConfig Yang Models are a collaborative effort to develop a programmatic interface in a vendor-neutral way. OpenConfig is not a standard organization. However, it has become a common model widely adopted by network vendors and users.

One of the biggest reasons users choose to use OpenConfig as a networking model is its vendor-agnostic characteristics. Each vendor's implementation is not quite the same, so deviation can often exist. Even vendors can support the same model, the deviations lead to result that single set of RPC is not capable of managing network devices from different vendors, the application still needs to treat each vendor independently. Also, OpenConfig Models usually lag behind the implementations of the industry. For example, although VXLAN EVPN is widely deployed in the industry, OpenConfig still doesn't have YANG models defined for VXLAN EVPN yet (expected to be released this year with intensive effort from Cisco).

To provide a model for the feature that is not supported by OpenConfig, each vendor has their own model, which is also defined in YANG. In Cisco, we called it Device YANG Model, with it, users can access the configuration and operational data of a new feature without prolonged waiting for OpenConfig YANG model.

Orchestrators from different vendors honor vendor-specific models as long as it is well-defined in YANG, this makes the NETCONF interoperability test reasonable and meaningful.

What are tested in this event?

The first event of the NETCONF interoperability test focused on basic system management and Service Provider service use cases. The testing areas are as below:

• Management of IP implementations
• System Management, hostname, DNS, NTP configuration
• MPLS and MPLS-SR
• L2 VPN Service Creation with SR-MPLS
• L3 VPN Service Creation with MPLS and SR-MPLS
• Bi-Directional Forwarding Detection provision
• Precision Time Protocol provision
• Retrieve interface counters
• Telemetry Streaming with gNMI

As part of the test, first event only focused on the MERGE operation of NETCONF to provision the required configuration and rollback. Even NETCONF does define event notification. However, gNMI (gRPC Network Management Interfaces) is gaining more and more users' attraction. As a result, gNMI was used as the protocol with YANG as the date model in this test.

Which Cisco data center switches were tested?

Although the first event only got a handful of vendors to participate, Cisco joined the test with NSO (Network Service Orchestrator) as orchestrator and Nexus switches as the device under test. During the test, Cisco provides the latest CloudScale Nexus 9316D-GX and Nexus 36180YC-R.

Both platforms were used for the following test cases like IP management, System Management with at least one orchestrator from another vendor. Nexus 9316D-GX are specifically used for Layer 2 and Layer 3 VPN test case on top of SR-MPLS, while Nexus 36180YC-R is used for Layer3 VPN test cases on MPLS. With the compliance of open standard protocol, Cisco Nexus Switches successfully participated in all the combinations with other orchestrators. In the years ahead, we hope to see more vendors to join the effort to add more test scenarios, including VXLAN EVPN, REPLACE operation of NETCONF, and maybe other open management protocols like gNMI.

Proven Openness

Cisco embraces open standards like NETCONF and YANG, and always keep openness in mind. Open is a collaborative work. Cisco is willing to support open standard protocols and contribute to the community to help network operators to model and automate the network. The Multi-Vendor NETCONF interoperability test provided by EANTC will bring users more confidence to design and implement automation infrastructure.

Useful Links

Multi-Vendor NETCONF/YANG-Based SDN Management Interoperability Test Showcases