3.1.1. Prerequisites for Using Model-Driven Management Interfaces

Before configuration editing is permitted in model-driven interfaces, the management interface configuration mode must be set to model-driven or mixed. See Management Interface Configuration Mode for details.

All loose references using IDs to certain elements (elements which use IDs as keys in classic interfaces but string names in model-driven interfaces) must be replaced with references using string names. See Loose References to IDs for details.

Strict routing policy validation is used for model-driven interfaces. The routing policy must exist for the management interface configuration mode to be changed. References to non-existent routing policies must be removed before attempting to switch modes. Strict policy validation is applied to the following routing policy references:

A newly created routing instance, group, or EBGP neighbor in a model-driven interface applies the secure default behavior to reject all routes. It is compliant with RFC 8212. The secure behavior can be disabled using the ebgp-default-reject-policy command. However, Nokia recommends configuring import and export policies that express the intended routing instead of using the insecure default behavior.

3.2.1. SR OS YANG Data Models

The Nokia SR OS YANG modules are the heart of the model-driven architecture and have the following attributes.

The YANG model for state data in SR OS has the following attributes.

All configuration modules, state modules, and types modules are advertised in the SR OS NETCONF server <hello>. Submodules are not advertised in the <hello>.

The bof, admin, tools, debug, or clear branches of the CLI do not have equivalent YANG data models.

3.2.2. OpenConfig YANG Data Models

OpenConfig presents a vendor-independent set of YANG models. OpenConfig YANG model attributes are mapped to application-specific configuration and state. SR OS requires the following system management configuration to access the application configuration using the OpenConfig YANG models.

OpenConfig YANG models are available for all model-driven interfaces. In MD-CLI, OpenConfig configuration is located in the configure openconfig context.

When a configuration is committed, the system checks to ensure that openconfig-modules is set to true. If openconfig-modules is set to false, a configuration error is raised.

The openconfig-modules command behaves differently depending on the configuration access method, MD-CLI, gNMI, or NETCONF as follows:

It is possible to configure the network element using both Nokia YANG and OpenConfig YANG models. Configuration ownership is a key concept, determining which model-driven access method can update a container or list entry. Only the access method that has claimed configuration ownership of an container or list entry can modify the configuration for that container or list entry. Individual applications define the required container or list entry based on their unique requirements. The applications also determines if and how ownership can change. It is possible to have both Nokia YANG and OpenConfig YANG commands in the same set transaction. Validation and commit functions apply to all transactions in a single set. If an access method attempts to configure elements under a part of the hierarchy it does not own, an error message is generated. An example of the error message is:

Configuration ownership also influences default imports. The owner imports their container or list entry defaults. In the case where OpenConfig is the container or list entry owner but the model has opted to omit configuration elements required for application functionality, the Nokia application defaults are imported. These defaults cannot be modified using OpenConfig if the configuration path is not included in the OpenConfig model. If an object in the OpenConfig model does not specify a default, the application can use any default available. Typically, this is the existing SR OS application default for the container or list entry.

In the case where the OpenConfig model includes a leaf but does not include a default, the Nokia default can be used as specified in Table 53.

An operator action, such as the modification of a container or list entry using OpenConfig, may transition the container or list entry ownership to OpenConfig. Transitioning from OpenConfig to Nokia configuration ownership usually requires the deletion of the container or list entry through the OpenConfig model.

If the Nokia models are to be considered for configuration, the nokia-modules or nokia-combined-modules parameter must be set to true in the configure system management-interface yang-modules context.

When model-driven management interface configuration mode and OpenConfig YANG are enabled, the OpenConfig YANG configuration options become available. The openconfig-modules true command can be changed to openconfig-modules false during operation. However, all OpenConfig YANG configuration statements must be deleted prior to deleting the openconfig-modules leaf or setting it to openconfig-modules false, otherwise an error is generated. This protects the system from entering a state where an OpenConfig mismatch is possible.

The validate command validates the model-driven configuration against the model-specific definition, including any deviations. The commit command performs application-level mappings, another validation function, and activation of the candidate datastore. The application-specific mapping ensures the application requirements are met using the same criteria that is common for that application across all configuration actions.

In cases where there is an incomplete set of modeled data which results in an error, or there are other errors that arise from the commit operation, all transactions fail and produce an error message indicating the reason for the failure. A failure maintains the complete set of YANG parameters, as if the commit command had not been issued. This allows the administrator the option to correct the source of the error. Partial configurations are allowed as determined by the application and are not themselves invalid.

The transaction is tracked, including the OpenConfig Key and the Nokia Key. Both the OpenConfig path and the Nokia path are included in the returned error message. This error message uses the following format; Nokia:Normalized:OC-Key/path. This approach allows error message parsing and extraction of preference for the operator's model-driven-specific approach. A sample error message is shown below.

Where <extra-context> could be the OpenConfig context or related key information.

Deviation files are available for each model where there are differences from the published OpenConfig model. These deviations can include not-supported, add, replace, granularity mismatches, and different ranges. The OpenConfig YANG file 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 this format nokia-sr-<ocmodule>-deviations.yang, for example, nokia-sr-openconfig-network-instance-deviations.yang.

There are several places where ranges and units may not be aligned between OpenConfig YANG and SR OS application implementation.

When a mapping exists for an attribute but the configuration is out of range, an error is generated. For example, the application configuration leafB has a range of (1 to 100), where OpenConfig leafB specifies a range of (1 to 300). When an OpenConfig set above 100 is requested, an unsupported value error is returned.

As an example of a granularity mismatch, application leafC supports centiseconds and OpenConfig leafC supports milliseconds. If the OpenConfig value in milliseconds can be converted to a valid application value, the OpenConfig value is accepted (for example, OpenConfig leafC 100 ms is converted to application leafC 1 centisecond). However, if the OpenConfig value cannot be converted to a valid application value, an error is produced (for example, OpenConfig leafC 125ms cannot be mapped into centiseconds).

3.5.1. Mixed Configuration Mode

Mixed configuration mode is useful for operators to migrate from classic management interfaces to operating in a full model-driven mode. It allows the use of previous classic CLI scripts or other OSS integration (for configuration) although with some pre-requisites (see Prerequisites for Using Model-Driven Management Interfaces) and some limitations (see Table 54).

3.5.2. Loose References to IDs

A loose reference is a reference where the target of the reference does not have to exist. For example, configure service pw-template 23 egress filter ip 37 can be configured (when the management interface configuration mode is classic) even if ip-filter 37 does not yet exist in the configuration.

Before switching the management interface configuration mode to model-driven or mixed, all loose references using IDs must be replaced with references using string names (or removed from the configuration) for the following elements:

In the following configuration example,

can be changed to

Because ip-filter 37 is a loose reference, it does not require a name for the configuration to be valid. However, it may be desirable to assign a name as follows, to make the binding operational.

Note: A name can only be assigned to a filter or any element in the above list of elements which use IDs as keys in classic interfaces but string names in model-driven interfaces. It is recommended to assign names to the elements prior to an upgrade to Release 15.1.R1. A name can also be changed in releases prior to Release 15.1.R1. Elements without names are automatically assigned a name (the ID converted to a string) during an upgrade to Release 15.1.R1 or later, and cannot be changed without manually deleting and recreating the element.

Loose references to IDs for the objects listed above cannot be created while in mixed or model-driven configuration mode. Any classic CLI scripts must also be updated to avoid the use of any of the commands below.

The following lists the set of affected loose references. Some items take a service-name as an input. SR OS converts these service-names to IDs, and stores the IDs in the configuration. In these cases, the service-name becomes an alias at configuration edit time and is not stored as a reference.

IPsec related configuration:

Eth-cfm, oam-pm, and saa:

Filters:

PKI:

QoS:

Subscriber Management:

Miscellaneous:

3.5.3. Transitioning Between Modes

Depending on the size of the system configuration, transitioning away from classic mode may take several seconds to several minutes while the model-driven database is populated and synchronized to the current configuration. During the transition period, configuration changes are not allowed and service is not affected.

Transitioning to classic mode is immediate with no impact to services on the router.

3.7.1. Alcatel-Lucent Base-R13 SR OS YANG Modules

In addition to the model-driven Nokia SR OS YANG modules, SR OS also supports a second set of YANG configuration data models called the Alcatel-Lucent Base-R13 SR OS YANG modules (sometimes simply referred to as Base-R13).

The two sets of configuration models have a similar overall tree structure (just as the classic CLI and MD-CLI have a similar overall tree structure). But the behavior of Base-R13 NETCONF/YANG is quite different from the model-driven NETCONF/YANG.

The YANG modules for the Alcatel-Lucent Base-R13 SR OS YANG modules) have the following attributes.

The Base-R13 configuration data models are not interchangeable with the model-driven Nokia models. An XML request based on the Alcatel-Lucent Base-R13 YANG modules does not work if applied to a router using the urn:nokia.com:sros:ns:yang:sr:conf namespace and vice versa.

There are no state models for Base-R13 NETCONF/YANG.

3.7.2. SPC Objects in Base-R13 NETCONF/YANG

See the System-Provisioned Configuration (SPC) Objects section for general background information about SPC Objects in SR OS. This section only describes SPC object specifics for Base-R13 NETCONF/YANG.

The following behaviors apply to Deletable SPC Objects with Base-R13 NETCONF/YANG:

The following behaviors apply to Non-Deletable SPC Objects with Base-R13 NETCONF/YANG:

Some Non-Deletable SPC Objects are visible in a <get-config> request in the urn:alcatel-lucent.com:sros:ns:yang:conf-*-r13 namespace (the Alcatel-Lucent Base-R13 SR OS YANG modules), even if they are set to default values: