Enterprise IT administrators with hundreds, thousands, or even more networking devices and services to manage are turning to programmable, automated, deployment, provisioning, and management to scale their operations without having to scale their costs. Using structured data models and programmable interfaces that talk directly to devices―bypassing the command line interface (CLI)―is becoming an integral part of software-defined networking.
As part of this transformation, operators must choose:
◉ A network management protocol (e.g., Netconf or Restconf) that is fully supported in Cisco IOS XE
◉ Data models for configuration and management of devices
One path being explored by many operators is to use Google Remote Procedure Calls (gRPC), gRPC Network Management Interface (gNMI) as the network management protocol. But which data models can be used with gNMI? Originally it didn’t support the use of anything other than OpenConfig models. Now that it does, many developers might not realize that and think that choosing gNMI will result in limited data model options. Cisco IOS XE has been ungraded to fully support both our native models and OpenConfig models when gNMI is the network management protocol.
Here’s a look at how Cisco IOS XE supports both YANG and native data models with the “mixed schema” approach made possible with gNMI.
Vendor-neutral and Native Data Models
Cisco has defined data models that are native to all enterprise gear running Cisco IOS XE and other Cisco IOS versions for data center and wireless environments. Other vendors have similar native data models for their equipment. The IETF has its own guidelines based on YANG data models for network topologies. So too does a consortium of service providers led by Google, whose OpenConfig has defined standardized, vendor-neutral data modeling schemas based on the operational use cases and requirements of multiple network operators.
The decision of what data models to use in the programmable enterprise network typically comes down to a choice between using vendor-neutral models or models native to a particular device manufacturer. But rather than forcing operators to choose between vendor-neutral and native options, Cisco IOS XE with gNMI offers an alternative, “mixed-schema” approach that can be used when enterprises migrate to model-driven programmability.
Pros and Cons of Different Models
The native configuration data models provided by hardware and software vendors support networking features that are specific to a vendor or a platform. Native models may also provide access to new features and data before the IETF and OpenConfig models are updated to support them.
Vendor neutral models define common attributes that should work across all vendors. However, the current reality is that despite the growing scope of these open, vendor-neutral models, many network operators still struggle to achieve complete coverage for all their configuration and operational data requirements.
At Cisco we have our own native data models that encompass our rich feature sets for all devices supported by IOS XE. Within every feature are most, if not all, of the attributes defined by IETF and OpenConfig, plus extra features that our customers find useful and haven’t yet been or won’t be added to vendor-neutral models.
With each passing release of Cisco IOS XE there has been significant and steady growth both in the number of native YANG models supported and in the number of configuration paths supported (Figures 1 and 2). The number of paths provides an insight into the vast feature coverage we have in IOS –XE. As of IOS XE release 17.5.1, there are approximately 232000 XPaths covering a diverse set of features ranging from newer ones like segment routing to older ones like Routing Information Protocol (RIP).