]> An Experiment: Mapping IETF Device YANG Models to Vendors Deutsche Telekom AG
Bonn 53227 DE ian.farrer@telekom.de
Intwine
kris@intwine.net https://www.intwine.net
Operations and Management NMOP NETCONF, YANG, device, models, vendor, proprietary This document describes an experimental implementation of a YANG to YANG translation function layer providing a northbound interface for configuring networking devices using a set of IETF 'device' YANG modules. The southbound interface of the function implements the proprietary, vendor YANG modules which are implemented natively on devices to be configured. The expected benefits of such an approach are the ability to provide a stable, standardised, and vendor/device agnostic interface for the configuration and maintenance of devices. The main purposes for this experiment is to validate the overall approach, and to identify, and describe the different YANG-to-YANG translation techniques that can be used.
Introduction IETF device YANG models provide a standardized interface for configuring network devices. However, devices may implement vendor-specific YANG models natively, requiring management systems to accommodate differences between vendors. A translation layer between these models could allow management systems to use IETF device models while interacting with devices through their native models. The need for tooling to support this approach was highlighted at the IAB Workshop on the Next Era of Network Management Operations (NEMOPS). Section 3.1.1 of the workshop report notes:
Additionally, the lack of open-source Network Management System (NMS) implementations, tools, and device model implementations was identified as a significant barrier to advancing standardization efforts. The IETF could play a key role in fostering and enabling collaborations to address these challenges. While the IETF does not itself build tools, it was suggested that having a translation tool that runs outside the network device to map IETF device models to vendor-specific ones would be beneficial.
This document explores the suggested approach through an experimental implementation of a YANG-to-YANG translation layer. The layer runs outside the network device and exposes a northbound interface based on IETF device YANG modules. Its southbound interface uses the vendor-specific YANG modules implemented natively on the device. The experiment aims to assess whether this approach can provide a stable, standardized configuration interface across vendors and devices, and to identify and describe the YANG-to-YANG translation techniques needed to support it.
This document is experimental. Its main goal is to evaluate a translation layer between IETF device YANG models and vendor-specific YANG models implemented natively on network devices, and to identify and describe the YANG-to-YANG translation techniques needed to support this approach. The experiment consists of verifying whether the translation layer can support device configuration through an interface based on IETF device YANG models in operational use cases. The experiment can be deemed successful if at least one open-source implementation demonstrates correct translation and application of configuration on network devices from multiple vendors.
Terminology Layer: A logical abstraction representing a level of interaction between the management system and the network device, typically used to describe the northbound and southbound interfaces in the YANG-to-YANG translation experiment. Northbound interface: The interface exposed by the translation layer to the management system, based on IETF device YANG modules. Southbound interface: The interface used by the translation layer to interact with the network device, based on vendor-specific YANG modules. Device model: TBD RFC8969
Problem Statement Since the publication of the original YANG modeling language in 2010, the IETF has standardized a large number of 'device' YANG modules. defines device models as follows:
Refers to the Network Element YANG data model described in or the device configuration model disucssed in . Device models are also used to refer to model a function embedded in a device (e.g., Network Address Translation (NAT) , Access Control Lists (ACLs) ).
The experiment described in this document is specifically concerned with model implementations that are separate from the device being managed. These models cover the configuration and management of a very diverse set of protocols and technologies, and generally take the approach of modelling the necessary parameters and options for a particular technology as defined by the relevant the technical specification which defines that technology. Therefore, the IETF's YANG device models contain a common set of configuration and mangement nodes that are relevant for any standard compliant implementation. Despite the number of available device YANG models, there has been a low rate of implementation in devices and software either available commercially, or as open-source. In many cases, no publically available implementations exist. However, native implementations of NETCONF/YANG management in commercially available networking devices have become commonplace. These implementations are generally based on proprietary YANG modules defined by the vendor and supplied as part of a software release. The structures of such YANG modules differ vastly from the IETF's device models, from vendor to vendor, and often across different platforms and device families from the same vendor. Vendors' proprietary YANG implementations tend to be comprehensive, in that they expose configuration and state for all of the functionality that a given device offers. This may be a superset of the functions defined in the IETF's device YANG models for any given technolgy. Unique functionality offered by one vendor's implementation of a technology versus another's is often a key factor in a customer's decision to purchase. The chosen vendor's native YANG models contain the necessary nodes for this functionality, so it is ready to use on delivery of the device. This does not easily align with the IETF's processes for publishing and updating YANG models, which may take a number of years. In addition, a vendor's proprietary features or extensions to a given technology that are not standardized are unlikely to be included in an IETF device model. The work which is necessary to integrate vendor's proprietary models into an automation system is significant. Multiple vendors and platforms, each with their own disparate proprietary models make this problem significantly worse. Vendor's model also change quite regularly with each release of the device's operating software as features and capabilites are added and removed bringing a high maintenance overhead. From the perspective of the automation implementer, this presents a dichotomy: the IETF's device models present a stable, device and vendor agnostic interface, but they are not widely implemented and do not offer differentiating, vendor specific functionality. Vendor proprietary models are comprehensive in their nature, but have a high cost for implementation and maintainance. The solution which proposed by this document is to produce an abstraction layer, implementing the applicable IETF device YANG models at its northbound interface, and integrating with vendor's proprietary YANG models at the southbound side. The abstraction layer is implemented as a software function using a 'middle-box' approach, which is separated from the device(s) which it is responsible for managing.
Offbox YANG Translation Function Between Orchestrator and Device YANG) | +----------------------------+-----------------+ | | Southbound | (Vendor YANG) v +----------------------------------------------+ | Network Device (Native) | | (Vendor-specific YANG modules) | +----------------------------------------------+ ]]>
Advantages of the Approach A common, IETF defined northbound interface provides a stable interface which higher layers in the automation architecture can interface with. This interface is vendor and device agnostic. The common, YANG northbound interface simplifies the integration of layered implementations. Using a middle-box approach, combined with open-source implementations gives the integrator control and flexibility to adapt the implemenation according to their requirements. If an integration requires proprietary
Overview The experiment selects a representative set of IETF device YANG modules for an MPLS Label Edge Router (LER) providing Layer 3 VPN services. Its service logic produces device configuration expressed using the IETF models. A translation layer, running as part of the orchestration system, converts this configuration into instance data for the native YANG models used by each device. The resulting native configuration is applied through the existing NETCONF southbound interface. The current implementation targets Cisco IOS XR and Juniper Junos (cRPD). IETF Device Modules with Implemented Configuration Mappings
TechnologyIETF YANG ModuleSpecification
System managementietf-system
Interfacesietf-interfaces
IPv4 addressingietf-ip
Subinterfacesietf-if-extensions
VLAN encapsulationietf-if-vlan-encapsulation
Network instancesietf-network-instance
Routing frameworkietf-routing
MPLS interfacesietf-mpls
IS-ISietf-isis
LDPietf-mpls-ldp
BGPietf-bgp
Key chainsietf-key-chain
Routing policyietf-routing-policy
BGP policyietf-bgp-policy
lists the main modules whose configuration data is consumed by the mappings. Supporting imports used only for types, identities, or groupings, and the constituent BGP submodules, are not listed separately. The implementation uses the latest available revisions of the respective modules at the time of implementation. The implementation is suffciently complete to configure the involved devices to perform their role in the network. Further work may be needed to cover the full mapping of each module.
Declarative Configuration Mapping The mapping expresses the native configuration that corresponds to a desired IETF configuration. YANG schemas provide typed data bindings for both sides, and mapping functions written in Acton construct native configuration trees from the source trees. These functions are deterministic and retain no state between evaluations. Device sessions, persistence, and the calculation and application of configuration changes are handled by the surrounding orchestration system. A mapping therefore describes the required configuration without prescribing a sequence of device commands. The translation runs after the configuration contributions from resource-facing services have been merged for a device. Related source trees are processed together: interfaces, routing protocols, network instances, and key chains can refer to one another. For example, a BGP neighbour can reference a peer group and a key chain, while a VPN interface references its network instance. Resolving these relationships against the combined input avoids making the result depend on the order in which individual services contribute their configuration. Mapping can involve renaming and restructuring nodes, converting values, or producing several native objects from one source object. For example, an IPv4 address and prefix length become an address and dotted-decimal netmask in the IOS XR model, and an address with a prefix length on a logical interface in the Junos model. IETF routing policy statements become structured Junos policy configuration or routing policy language text carried in IOS XR YANG leaves. These differences are contained in the vendor mappings, allowing the service logic to use the common IETF models.
Extending the Models with Augments A standard model may lack a node needed to express a particular deployment requirement or a vendor-specific behaviour. The YANG augment mechanism allows a separate module to add nodes to an existing schema. This makes it possible to keep the published IETF modules unchanged while providing the additional inputs required by the translation. The current implementation uses augmentations to add BGP/MPLS L3VPN attributes to the IETF network instance model. It also illustrates the use of augmentations to handle vendor behaviour. It adds ios-xr-policy-type to select regular, hierarchical, or both forms of a policy on IOS XR, and Junos-match-type to select regular, inverted, or both forms of a community set on Junos. These are implementation extensions, not IETF-standardised nodes. Augments preserve access to such capabilities while keeping the common policy structure.
Supporting Additional Vendors and Releases Each supported device type registers mappings from the common IETF models to its native schema. Adding a vendor, platform, or software release consists of providing the appropriate target schema and implementing and testing the mappings for the required configuration subset. Shared source bindings and value conversion helpers can be reused. The existing IOS XR and Junos mappings demonstrate how the same device model can support different native hierarchies without duplicating the service logic. This separation confines many changes in vendor models to the translation layer. It also permits gradual adoption: translated configuration can coexist with contributions expressed directly in native models, provided that thee results are mergeable. Common service logic can move to the IETF models as mappings become available, while vendor-specific configuration remains accessible.
Offbox Translation and Shared Implementation Running the translation offbox allows operators to use IETF device models with equipment that exposes only native YANG models. Mapping fixes, additional model coverage, and local augments can be deployed independently of the device software release cycle. The operator controls the translation code and can inspect and test the generated native configuration before deployment. Higher layers gain a common interface through the IETF device models, reducing their dependence on individual vendor model revisions. The StratoWeave implementation is published as open source , with the vendor mapping modules carrying a BSD-3-Clause licence. Operators can inspect, adapt, and contribute mappings and tests, including fixes for differences discovered in actual deployments. Sharing this work allows operators using the same platforms to build on a common implementation instead of each maintaining an independent integration. We intend to make the mapping functions useable independently of the orchestration runtime, making them reusable in other integrations. A shared implementation can provide executable examples of how IETF models apply to real devices. Comparing mappings and test cases across operators and vendors helps expose ambiguous semantics, missing nodes, and differences in feature support. That evidence can inform both improvements to the mappings and further development of the IETF models.
Standalone Translation Function Under the current experimental implementation, the tranlation logic can only usefully be executed as part of a StratoWeave orchestrator runtime. It is the author's explicit intention to make the translation logic reusable with other orchestration / automation solutions and tools. The standalone translation function we propose would be realized in the form of a standalone binary that accepts a complete device configuration as input. That configuration would be according to the IETF device models, possibly combined with with vendor-modeled YANG modules where desired. The output would be a device-specific configuration suitable for direct application to the target device. We welcome feedback and contributions from the community on how they would want make us of and integrate it in their own automation solutions and tools.
Implementation Considerations This section discusses various considerations for implementing the translation logic in a reusable manner.
Handling Multiple Versions The current Acton YANG framework compiles a set of vendor YANG modules into a device type built around named Acton classes that represent each schema node in the YANG source. The resulting nominal type equivalence means that for another device adapter with a near-identical YANG schema, the compiled Acton classes would be distinct, even if the source YANG schemas were 99% identical. For a translation framework to easily handle the translation of IETF Device models to dozens of versions of vendor YANG modules, structural type equivalence is required. It then becomes trivial to express minor mapping adjustments between different versions of the vendor YANG modules.
Complete Configuration Generation The output of the translation function is always a complete device configuration that represents the desired state of the device. Inside of a StratoWeave-based orchestrator, the diff engine can take this as input and efficiently compute the necessary changes to apply to the running configuration of the device. In other integration scenarios, this complete configuration can be applied directly to the target device using e.g. a NETCONF <replace> operation.
IANA Considerations This memo includes no request to IANA.
Security Considerations This document should not affect the security of the Internet.
References Informative References StratoWeave: IETF Device Model Translation Experiment
Acknowledgements The authors would like to thank Alex Huang Feng for his review and valuable comments.