Introduction
Overview
OpenConfig Translation feature is designed to enable NETCONF clients to interact with OcNOS (a network operating system) using standardized YANG models, particularly OpenConfig. This feature involves translating data between OpenConfig and OcNOS data models, primarily for edit-config, get-config, get, and notification operations. A Translation Framework has been developed to facilitate these translations.
Feature Characteristics
It is primarily designed to work with OpenConfig 2.0.0 and uses the latest models available at the time of implementation.
The feature targets network operators who wish to manage their multi-vendor network using a standardized interface, reducing operational costs and complexity.
Benefits
The OpenConfig Translation benefits are listed below:
Standardization: Allows network operators to manage OcNOS products using standardized YANG models, promoting consistency and simplifying network management.
Multi-Vendor Support: Facilitates the management of multi-vendor networks through a unified interface.
Flexibility: Supports the translation of both OpenConfig and OcNOS data models, offering flexibility to network administrators.
Error Reporting: Enables error reporting using OpenConfig paths, enhancing troubleshooting and diagnostics.
Prerequisites
Here are the prerequisites for OpenConfig Translation:
• The feature depends on using OpenConfig or OcNOS data models in the NETCONF client.
• The OcNOS NetConf server needs to be restarted and configured with translation enabled.
• The translation is based on OpenConfig release 2.0.0.
Troubleshooting
• Error reporting is done using OpenConfig paths; unknown or unsupported leafs are ignored.
• The translation may lead to the rejection of configuration if unsupported parts are encountered.
• Ensure that the correct data models are used, and translations are properly configured.
Limitations
• Certain operations such as "replace" and "create" might not be supported on all nodes.
• Not all network configurations may be visible through NetConf if they are not supported by the translation.
• Support for RPCs and notifications in OpenConfig models are not supported.
• To handle data with OpenConfig namespaces, the translation must be enabled in advance as enabling OpenConfig translation and editing objects within the OpenConfig namespace in the same transaction is not supported.
• If the translation is not enabled in advance, the payload will be rejected as the current NETCONF session cannot process OpenConfig namespaces, resulting in an unknown namespace error.
OpenConfig Configurations
This document describes the OpenConfig configurations and state attributes supported by OcNOS SP and Optical Transport Network (OTN) versions 6.6.0 and the limitations which apply to some of the paths.
Network-instance Object Values for “type” Attribute
There are several protocols that are configured inside the Network-Instance object, and the distinguishing factor is the value of the /network-instances/network-instance/config/type attribute. For some protocols is also needed to configure leaf /network-instances/network-instance/ encapsulation/config/encapsulation-type.
The below table displays all the values used on current translated protocols:
OcNOS Network Instance (NI) type xpath: /network-instances/network-instance/instance-type | Open Config NI type xpath: /network-instances/network-instance/config/type |
|---|
vrf | L3VRF || DEFAULT_INSTANCE |
mac-vrf | L2L3 + leaf /network-instances/network-instance/ encapsulation/config/encapsulation-type as “MPLS” |
l2ni (bridge) | L2L3 |
vpls | L2VSI + leaf /network-instances/network-instance/ encapsulation/config/encapsulation-type as “MPLS” |
vpws | L2P2P + leaf /network-instances/network-instance/ encapsulation/config/encapsulation-type as “MPLS” |
evpn | L2L3 + leaf /network-instances/network-instance/ encapsulation/config/encapsulation-type as “VXLAN” |
cross-connect | L2P2P |
bridge-domain | L2VSI |
Network-instance restrictions
When deleting a network-instance element via NETCONF, if there are interfaces associated with that instance, a NETCONF get of the candidate datastore still presents the network-instance and interface association. It is removed after a commit operation and then represented correctly on both candidate and running datastore.
Yang deviation and NETCONF Client Yangcli
OcNOS utilizes the Yang deviation statements to indicate that the datamodel supported deviates from the OpenConfig models.
The NETCONF Client Yangcli does not support Yang deviations and should not be used for managing OpenConfig namespace. Note that using NETCONF Yangcli client with OpenConfig may lead to operation errors.
Enable OpenConfig Translation
The OpenConfig feature is disabled by default and must be enabled using the following CLI command on the OcNOS shell.
OcNOS> enable
OcNOS# configure terminal
OcNOS(config)# netconf translation openconfig
OcNOS(config)# commit
OcNOS#^D
OcNOS#show running-config netconf translation
!
netconf translation openconfig
!
Or using the equivalent NETCONF
<netconf-server xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-management-server">
<netconf-translation>
<config>
<translation-mode>openconfig</translation-mode>
</config>
</netconf-translation>
</netconf-server>
The translation is disabled using the following CLI command on the OcNOS shell:
OcNOS> enable
OcNOS# configure terminal
OcNOS(config)# no netconf translation
OcNOS(config)# commit
OcNOS#^D
OcNOS#show running-config netconf translation
OcNOS#
To get the OpenConfig data, the corresponding namespace must be given:
yangcli ocnos@localhost> sget-config /netconf-server source=running
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-server xmlns="http://www.ipinfusion.com/yang/ocnos/ipi-management-server">
<netconf-translation>
<config>
<translation-mode>openconfig</translation-mode>
</config>
<state>
<translation-mode>openconfig</translation-mode>
</state>
</netconf-translation>
</netconf-server>
</data>
</rpc-reply>
Restrictions
Enabling OpenConfig translation and editing objects within the OpenConfig namespace in the same transaction is not supported. To handle data with OpenConfig namespaces, the translation must be enabled in advance. Otherwise, the payload gets rejected, as the current NETCONF session cannot process OpenConfig namespaces, and results in unknown namespace error.