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).
Figure 1. Quantity of YANG Data Models Per IOS XE Release
Figure 2. Quantity of YANG Configuration Paths Per IOS XE Release
Complete information on Cisco IOSXE YANG model coverage can be found in the public GitHub repository. The information there is updated with data from every new IOS XE release.
For customers evaluating gNMI as their network management protocol it may feel like a dead-end when OpenConfig models are insufficient to handle a use case. It is important to understand that gNMI is not limited to OpenConfig models and vendors can make their native models available with gNMI.
But are you stuck with having to choose between using OpenConfig or native models? No, the mixed-schema approach to data modeling offers the best of both worlds.
The gNMI Mixed Schema Approach
The gNMI specification of RPCs and behaviors for managing the state on network devices was proposed by OpenConfig. It’s built on the open source gRPC framework and uses the protocol buffers interactive data language (Protobuf IDL).
At Cisco we believe that our customers should have the best of both native and vendor-neutral data modeling worlds. Enterprise admins can consider using vendor-neutral models to standardize the core elements of configurations and then provide other functionality using the native device models.
With the mixed–schema approach, operators can mix IETF, OpenConfig, and native models without sacrificing many of the advantages of a model-driven approach to configuration and operational data. Operators can disambiguate the schema source using the gNMI “origin” fields defined by the network device vendor.
You don’t lose any transactional benefits when using a mixed-schema approach. This is critical as it means that an operator can, for example, issue a gNMI Set that combines configuration from an OpenConfig and native model in a single transaction. Any failure will cause the entire transaction to fail and removes the need for the operator to deal with complicated configuration rollback scenarios
Support for gNMI in IOS XE
The mixed schema approach is supported in IOS XE using the “openconfig” origin field for OpenConfig models and “rfc7951” for native models. Here is an example where a gNMI Set request is used to enable NTP on a network device.
In this scenario, the operator relies on NTP configurations that are not specified in the OpenConfig model. The first update in the request is completely vendor-neutral and enables NTP on any device that supports the openconfig-system model. The second update is specific to Cisco IOS XE and is easily distinguished via the origin field. The two updates are combined in a single request which means that both must be successful for the whole Set transaction to succeed. There is no need for the operator to perform any complicated roll-back of the device configuration if one of the updates were to fail.
update: <
path: <
origin: “openconfig“
elem: <
name: “system”
>
elem: <
name: “ntp“
>
elem: <
name: “config”
>
>
val: <
json_ietf_val:”{\”enabled\“:true,\”ntp-source-address\”:\”10.1.1.1\”,\”enable-ntp-auth\”:false}”
>
>
update: <
path: <
origin: “rfc7951”
elem: <
name: “Cisco-IOS-XE-native:native“
>
elem: <
name: “ntp“
>
>
val: <
json_ietf_val:”{\”Cisco-IOS-XE-ntp:mindistance\”:2,\”Cisco-IOS-XE-ntp:maxdistance\”:10}”
>
>
This type of mixed-schema approach will work just as well for gNMI Get requests.
Find Out More About gNMI
The gNMI mixed-schema approach with Cisco IOS XE is an extremely useful tool that network operators can use to ease the transition to a model-driven, programmable, and automated network infrastructure. I highly recommend that every enterprise network administrator familiarize yourself with the gNMI specification and models. We’re moving to software-driven deployment and management, with software running in the cloud and on devices that automate network management. With two types of options available for data model-driven network management, you now don’t have to choose among them. You can have the best of both worlds.
Source: cisco.com
Posts
0 comments:
Post a Comment