3.2.2.2.1. Introduction

Nokia provides a suite of vendor-specific YANG models to configure the network element. OpenConfig is an informal working group which provides vendor-neutral YANG models based on the desired usage of a technology by the community. The Nokia vendor-specific model is a more complete representation of the capabilities of the network element, which includes vendor specific features and functions not described by the OpenConfig YANG models. The two YANG configuration models, Nokia’s vendor-specific and OpenConfig’s vendor-neutral, may be used together to configure the network element. Support for OpenConfig models can be established by examining the OpenConfig model with the vendor-specific deviations and augments.

3.2.2.2.2. Merging Configuration Statements

In order to ensure complete traceability and the origin of the configuration (that is, which data model configured the feature), the Nokia and OpenConfig configuration statements are maintained separately in the configuration tree. This allows for the greatest flexibility when accommodating configuration differences between the Nokia and OpenConfig models. The configuration statements are merged, giving precedence to the Nokia model configuration statements when there is a collision (that is, when the same function is configured in both the OpenConfig and Nokia models).

In order to merge configuration for objects, the keys for an object must be equal and deterministic for both the Nokia and OpenConfig models. This provides an anchor for the object and allows the configuration to be rationalized and merged. For example, augments may have been made to OpenConfig models to allow for a deterministic key where a key function is not supported. One example is the use of the configure openconfig interfaces interface interface subinterfaces subinterface number ipv4 config primary-address option. In this case, the OpenConfig model does not allow which of the specified interfaces should be the primary. The control of the primary interface is very important.

When configuration statements are completed using one configuration model, tab completion for a name or reference identifier is not available in the other model. For example, the name or identifier of a list entry must be equally and explicitly entered in both data models in order to share the configuration elements across the different models.

There are two different approaches taken for shared model management, on a per Nokia application basis: leaf level and list level management.

An application that supports shared model management at the leaf level allows both configuration models access to the leaf and merge operations can occur at the leaf level. If both Nokia and OpenConfig models include configuration for a leaf, the Nokia configuration takes precedence. The OpenConfig configuration statements remain in its configuration database but are not applied as part of the operational configuration

An application that supports granularity at the list level allows individual list entries for an application to be managed by one model only. The configuration model that creates the list entry is the only model that can modify or delete the list entry. An attempt to modify the list entry using the configuration access method that does not manage the list entry returns an error message identifying the managing owner of the list entry.

Unless configured explicitly using the Nokia configuration model, a configuration element that does not have a static default value is managed by OpenConfig.

In some situations, partial or incomplete OpenConfig configurations may be allowed. For example, where the OpenConfig structure is accepted but the triggering mapping has not been configured under OpenConfig, the information is not pushed to the application. These partial configurations remain in the OpenConfig configuration tree as they are syntactically correct, however, without an application mapping event, they remain outside of the operating configuration. When a partial configuration is stored in the OpenConfig configuration tree, it does not show as an active element under the SR OS specific application, that is, via show commands or in the /state tree.

3.2.2.2.3. Application Support

Applications may allow for the configuration to be delivered from either the Nokia YANG model or the OpenConfig YANG models. In many cases, applications allow some level of cooperative configuration such that the configuration statements can be received from both Nokia YANG models and OpenConfig YANG models. In order to determine the level of cooperative configuration allowed by an application, the application-specific Nokia or the nokia-conf-combined.yang YANG models can be checked for the following extension statement.

If the above statement is found, the cooperative shared model management configuration is not allowed for that element and all descendants of the element.

The level of shared model management support can be viewed via the MD CLI help if the OpenConfig YANG models have been enabled.

The models that prevent shared model management at a specific level of the hierarchy include the following statement in the help. For example, the commands in the configure policy-options policy-statement context display the following:

3.2.2.2.4. Validating and Committing

Validation ensures the structure and completeness of the configuration against the OpenConfig model. It does not deliver the configuration to application. It is possible that a validation succeeds when the structure and requirements of the OpenConfig model are met.

The commit function performs the validation as above, with the additional step of delivering the converted OpenConfig statements to the application. A successful validation can be followed by a failure to commit the transaction. For example, the following scenarios result in a failed commit action:

Nokia applications that include conditional “when” statements using the Nokia YANG model must have the statements satisfied by the Nokia configuration. The OpenConfig configuration cannot verify or satisfy Nokia conditional “when” statements. This approach prevents “when” statements from changing from one state to another by updating the OpenConfig statements and affecting a non-child leaf in the Nokia configuration. For example, the following message is displayed when the OpenConfig configuration sets the port ethernet mode to hybrid but the conditional “when” statement requires the Nokia configuration to satisfy the condition.

3.2.2.2.5. Error Reporting

Errors can occur in situations such as the following:

Failed transactions display an error message indicating the reason for the failure. A failure maintains the complete set of YANG parameters, as if the commit function had not been issued. This allows the administrator to correct the source of the error.

In the event of a delivery error, the OpenConfig path and the Nokia path are included in the error message. A sample error message is shown below.

3.2.2.2.6. Using the info Command

Several variations of the info command are available in order to collect the required operational data required to view the configuration. The info command can be issued under the Nokia configuration context in the MD-CLI. These include:

info - Show the configuration as explicitly entered for the current context.

info converted - Include converted third party model configuration from the running datastore. When an object is management by OpenConfig, meaning the running configuration has an entry delivered by an OpenConfig configuration statement, the leaf or container be precedes with the statement "## managed: by OpenConfig”.

info converted model openconfig - Include converted third party model configuration from the running datastore with the “managed” indicator removed from the output.

info inheritance - Include configuration inherited from configuration groups.

The converted and inheritance options can be combined into a single command

For more information about the info command, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI User Guide.

3.2.2.2.7. Deviating and Augmenting

Deviation files are created for the OpenConfig model when the model deviates from the application requirements of the network elements, such as implementations that are not supported, added, or replaced, granularity mismatches, and different ranges. These deviations are included in an OpenConfig YANG file which contains text descriptions when different units or ranges are in place. Deviations are not raised for OpenConfig “must” statements, as the “must” statement in OpenConfig models is not supported in SR OS. The deviation file follows the naming format nokia-sr-<OpenConfigModule>-deviations.yang, for example, nokia-sr-openconfig-network-instance-deviations.yang.

It is not always necessary to use a deviation file where a specific function is not supported. For example, in the case of enumerations, when an enumerated OpenConfig value is not supported, the validation or commit function fails with an indication that the entry is not valid.

When a mapping exists for an attribute and the configuration is out of range, an error is generated. For example, the Nokia application configuration for leaf B has a range of 1 to 100, where the OpenConfig leaf B specifies a range of 1 to 300. When the OpenConfig value is set above 100, an unsupported value error message is returned.

As an example of a granularity mismatch, Nokia application leaf C supports centiseconds and OpenConfig leaf C supports milliseconds. If the OpenConfig value in milliseconds can be converted to a valid application value, the OpenConfig value is accepted. For example, OpenConfig leaf C 100 ms is converted to application leaf C 1 centisecond. However, if the OpenConfig value cannot be converted to a valid application value, an error is generated. For example, OpenConfig leaf C 125ms cannot be mapped into centiseconds.

Augments files are also included to add configuration for OpenConfig that is required by the Nokia application in order to function as expected. The augments file follows the naming format nokia-sr-<OpenConfigModule>-augments.yang.