Model-driven management interfaces

SR OS supports two classes of management interfaces:

Classic management interfaces
- SNMP
- classic CLI
Model-driven management interfaces
- Model-Driven CLI (MD-CLI)
- NETCONF
- gRPC (gNMI and gNOI)

Unless otherwise indicated, the term ‟CLI” in the SR OS user documentation refers to the classic CLI. The classic CLI has been supported in SR OS from the initial introduction of SR OS. For more information about classic CLI commands, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

The MD-CLI is a model-driven CLI introduced in SR OS Release 16.0.R1. For more information about MD-CLI commands, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI User Guide and the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide.

Model-driven management interfaces are based on a common infrastructure that uses YANG models as the core definition for configuration, state, and operational actions. All model-driven interfaces take the same common underlying YANG modules and render them for the particular management interface.

The model-driven interfaces are similar to the classic CLI interfaces with the following notable differences.

The classic and model-driven configuration formats are incompatible; the system automatically converts the classic configuration to the model-driven format when the management interface configuration mode is changed to model-driven.
Some classic CLI branches have been moved, renamed, or reorganized in the SR OS YANG modules.
Many elements use strict references in model-driven interfaces instead of the loose references used in the classic CLI and SNMP. For more information, see Loose references to IDs and Strict routing policy validation.
Many elements use string names as keys in model-driven interfaces instead of the numerical identifiers used in the classic CLI and SNMP. See String names as keys for more information.
The classic CLI shutdown command has been replaced with admin-state in model-driven interfaces.
The classic CLI commands with multiple parameters have been separated into individual leafs in model-driven interfaces.
The model-driven interfaces make extensive use of Boolean values (true and false) for configuration settings.
The default configuration handling is as follows.
- In model-driven configuration mode, the system operates with ‟explicit” default handling. Users can set a leaf to the same value as the default and the system displays it as part of the configuration. This handling is similar to RFC 6243 ‟explicit” mode.
- In mixed configuration mode, the system uses ‟explicit” default handling but it is not persistent. Explicitly configured default values are not preserved during a high-availability CPM switchover or a reboot. Nokia recommends deleting the leaf instead of setting any leaf explicitly to its default value in mixed configuration mode.
A newly created routing instance, group, or EBGP neighbor in a model-driven interface applies the secure default behavior to reject all routes. Using the ebgp-default-reject-policy command to implement this is compliant with RFC 8212. Nokia recommends configuring import and export policies that express the intended routing instead of using the insecure default behavior. For more information about RFC behavior, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.

Management interface configuration modes

The system can operate in different management interface configuration modes, which affects which CLI and network management protocols can be used to configure the system. The following interfaces are available for configuration on SR OS:

model-driven (default)

Configuration via model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via the classic CLI and SNMP.
classic

Configuration via the classic CLI and SNMP, no model-driven interfaces are supported.
mixed

Configuration via the classic CLI and model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via SNMP.

Mixed configuration mode is a transition mode 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 developed by users for configuration, although with some prerequisites (see Prerequisites for using model-driven management interfaces with classic configurations) and some limitations (see Management interface configuration mode).

Use the configure system management-interface configuration-mode command to enable configuration editing by model-driven interfaces.

Table 1. Management interface configuration mode
		Configuration mode
		Classic	Mixed	Model-driven
Classic Interfaces	Classic CLI: configuration write	✓	✓
	Classic CLI: configuration read	✓	✓	✓
	Classic CLI: non-configuration commands	✓	✓	✓
	SNMP: configuration write	✓
	SNMP: non-configuration writes (such as admin reboot)	✓
	SNMP: configuration read	✓	✓	✓
	SNMP: state read	✓	✓	✓
	SNMP: notifications (traps)	✓	✓	✓
Model-driven Interfaces with Nokia YANG Models	MD-CLI: configuration write and read		✓	✓
	MD-CLI: state read	✓	✓	✓
	NETCONF: configuration write and read		✓	✓
	NETCONF: state read	✓	✓	✓
	gNMI Set/Get: configuration write and read		✓	✓
	gNMI Get: state read	✓	✓	✓
	gNMI Telemetry: configuration read		✓	✓
	gNMI Telemetry: state read	✓	✓	✓
Saved Configuration File Format	bof	Classic	Classic	Classic
	configure	Classic	Classic	MD
	debug	Classic	Classic	MD
	li	Classic	Classic	MD
Features	OpenConfig YANG models			✓
	Commit history			✓
	Configuration annotations			✓
	Configuration groups			✓
	MD-CLI rollback command			✓
	Classic CLI admin rollback revert command	✓	✓
	Explicit defaults^{^¹}			✓
	Explicit non-deletable SPC objects^{^²}			✓
	Configuration changes accepted immediately after a CPM high-availability switchover^{^³}	✓		✓
	Named route policy entries			✓
	gRPC MD-CLI service for the NISH client		✓	✓
	Remote management using the NISH manager		✓	✓
	MD-CLI command aliases			✓
	Python 3 for pyexec, EHS, CRON, and MD-CLI command aliases			✓
	The use of the pySROS library from any location			✓
	Incremental saved configuration files			✓

¹ In model-driven mode, users can set a parameter to the same value as the default, and SR OS remembers that it was explicitly set and displays it as part of the configuration. In mixed mode, these values are not persistent and they are lost or forgotten at a CPM high-availability switchover or a reboot.

² In model-driven mode, users can explicitly create any of the SR OS non-deletable SPC objects, and SR OS remembers that it was explicitly created and displays it as part of the configuration. See SPC objects, for more details about the SPC objects.

³ In mixed mode, changes to the configuration are blocked for a few minutes after a CPM high-availability switchover event while the model-driven database is synchronized with the SR OS application layer. There is no impact to running services.

YANG data models

Model-driven management interfaces are based on a common infrastructure that uses YANG models as the core definition for configuration, state, and operational actions. All model-driven interfaces (NETCONF, gRPC/gNMI, and the MD-CLI) use the same common underlying YANG modules and render them for the particular management interface. These YANG models are also used for telemetry.

SR OS supports:

Nokia YANG data models
OpenConfig YANG data models

Nokia SR OS YANG data models

The Nokia SR OS YANG modules are the base for the model-driven architecture.

SR OS configuration is divided into several top level configuration regions (see Datastores and regions for details). The data models for each configuration region are separated into different YANG modules.

The primary configuration region (configure) is modeled in the nokia-conf YANG module specified in a single file located at YANG/nokia-combined/nokia-conf.yang in the SR OS image distribution.

An alternative packaging of the primary configuration region is also available as a set of submodules (for example, nokia-conf-system) that belong to a single module located at YANG/nokia-conf.yang in the SR OS image distribution. The submodules have independent revision dates and can be used to identify which parts of the configuration model have changed.

The packaging options (combined and submodule) are alternate representations of the same data model. There is no difference between using the combined or submodule packaging for all the basic configuration or state operations (including with telemetry). The same containers, list, leafs, and so on, exist in the same namespaces whether you are using the combined or submodule packaging. The main difference between the combined and submodule options is seen in the NETCONF <hello>, YANG library, and <get-schema> data where there are lists of modules and submodules.

Some YANG tools may show errors about circular dependencies in the submodules. For example, Pyang gives an error about circular dependencies but does complete the processing to build complete tree or jstree output. If circular dependencies are preventing any necessary tools from correctly processing the YANG, use the combined packaging instead of the submodules. For details about enabling various sets of YANG modules, see the yang-modules commands in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

The lawful intercept (LI) configuration region is modeled in the nokia-li-conf YANG module specified in a single file called nokia-li-conf.yang.

The BOF configuration region is modeled in the nokia-bof-conf YANG module specified in a single file called nokia-bof-conf.yang.

SR OS state information is modeled in the nokia-state YANG module specified in a single file located at YANG/nokia-combined/nokia-state.yang in the SR OS image distribution.

LI state information is modeled in nokia-li-state.yang which augments the primary nokia-state module.

BOF state information is modeled in nokia-bof-state.yang.

There are also a series of nokia-types-* modules that are included by various configuration and state modules.

The SR OS YANG modules have the following attributes.

The modules can be used with NETCONF, telemetry, or with the Set/Get RPCs of the gRPC-based gNMI service.
The modules and submodules indicate the SR OS major release stream using a YANG extension (for example, sros-ext:sros-major-release "rel16";). Module and submodule revisions form a contiguous series of revisions inside a major release stream. There may be two files for the same module with the same revision date but with different contents because they are from two different major release streams. Each active major release stream has revisions ongoing in parallel.

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 common operational clear, monitor, show, and tools CLI commands do not have equivalent YANG data models.

Some admin and file operations have YANG models whereby each operation is modeled using a YANG ‟action” statement. These can be viewed in the nokia-oper-*.yang files. See YANG-modeled operations for more information.

OpenConfig YANG data models

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 needed 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.

Basic configuration

OpenConfig YANG models are available in model-driven interfaces, including the MD-CLI, gNMI, and NETCONF. Use the following command to enable OpenConfig YANG models.

configure system management-interface yang-modules openconfig-modules

Access to the OpenConfig models is different depending on the model-driven interface.

MD-CLI
- OpenConfig configuration statements are located in the configure openconfig context.
- OpenConfig state information is located in the state openconfig context.
- When a configuration is validated or committed, the system verifies that openconfig-modules is set to true. If openconfig-modules is set to false and there are OpenConfig configuration statements in the candidate, the action fails with an error indicating that the OpenConfig module cannot be disabled when OpenConfig configuration elements exist.
  
  The operator must set openconfig-modules to true and perform the validate or commit action again.
- The system checks openconfig-modules to determine whether OpenConfig state elements can be accessed.
gNMI and NETCONF
- The system checks openconfig-modules to determine whether OpenConfig models can be advertised and whether the system can accept or send OpenConfig configuration or state elements.
- If openconfig-modules is set to false, the system blocks OpenConfig edits, requests, and responses from being sent or accepted at the gNMI or NETCONF level. A <get> operation from the root without a declared namespace or branch succeeds but does not include any OpenConfig data. However, a <get> operation that explicitly requests data from the OpenConfig namespace generates an error.
AAA rules for OpenConfig are different in the MD-CLI, NETCONF and gNMI
- A configure openconfig AAA profile entry applies to configure openconfig commands in the MD‑CLI, and to config and state elements in NETCONF and gNMI.
- A state openconfig AAA profile entry only applies to state openconfig information in the MD-CLI. AAA entries for NETCONF and gNMI state elements are not supported.

OpenConfig state without OpenConfig configuration

This feature supports the ability to retrieve the application state for the OpenConfig state path, without entries being configured in the OpenConfig models. This is helpful for users who only want to use a vendor-specific configuration to configure the node, but still want access to the OpenConfig common state information.

As part of the new feature, users can access OpenConfig state information from any of the following configuration mode settings.

configure system management-interface configuration-mode {classic | mixed | model-driven}

This means that regardless of the configuration mode, OpenConfig state information is available through any of the following:

NETCONF using get commands
Telemetry gRPC (on_change and polling) using the following command
```
tools dump system telemetry on-change-paths {open-config | nokia}
```
MD-CLI using the state openconfig context

Use the following commands with a Layer 3 interface to enable access to the OpenConfig state information from any configuration mode without OpenConfig configuration.

configure router interface external-reference openconfig subinterface
configure service vprn interface external-reference openconfig subinterface

The addition of the external reference does not influence the configuration other than to allow for a mapping between the Nokia vendor-specific configuration and the OpenConfig state. As part of the configuration, a user must also configure a port for the interface and a Layer 3 subinterface.

MD-CLI

[ex:/configure router "Base" interface "to-dutb"]
A:admin@node-2# info
    admin-state enable
    description “interface to dut b”
    external-reference
       openconfig
          subinterface 10
       }
    }
    port 1/1/c2/1:0
    ipv4 {
        primary {
            address 10.10.12.1
            prefix-length 24
        }
    }
    ipv6 {
        address 2001:db8:1:ab::a {
            prefix-length 64
        }
    }

classic CLI

A:node-2>config>router# info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
...
        interface "to-dutb"
            external-reference
                openconfig
                    subinterface 10
                exit
            exit
            address 10.10.12.1/24
            description "interface to dut b"
            port 1/1/c2/1:0
            ipv6
                address 2001:db8:1:ab::a/64
            exit
            no shutdown
        exit
----------------------------------------------

Shared model management

To ensure complete traceability of the origin of the configuration (that is, which data model configured the command), the Nokia and OpenConfig configuration trees maintain separate configuration statements. This allows for the greatest flexibility when accommodating configuration differences between the Nokia and OpenConfig models. If a conflict occurs during a merge (because of different values set in the two data models), the Nokia model has precedence.

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 using the following command to configure the primary address. In this case, the OpenConfig model does not define which of the specified interfaces should be the primary. The control of the primary interface is very important.

configure openconfig interfaces interface subinterfaces subinterface ipv4 config primary-address

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 to share the configuration elements across the different models.

Two different approaches are taken for shared model management, on a per Nokia application basis, to managed lists and leafs.

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 OpenConfig and Nokia models include configuration for a leaf, the Nokia configuration takes precedence. The OpenConfig configuration statements remain in the configuration but are not applied as part of the running configuration.

An application that supports shared model management at the list level allows only one model to manage individual list entries. 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.

Cannot access or modify element - managed by <managing owner> module

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 delivered 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.

To disable shared model management so that only one model is used to configure the same element, use the following command:

configure system management-interface yang-modules shared-model-management false.

For example, disable shared model management if OpenConfig configuration is used for all elements available in the OpenConfig models and you want to prevent the same configuration with Nokia models. When shared model management is disabled, the first model used to configure an element owns management of the element, and other models cannot configure it.

Application support

Applications allow for the configuration to be delivered from either the Nokia YANG model or the OpenConfig YANG models. In most cases, applications allow shared configuration such that the configuration statements can be received from both Nokia YANG models and OpenConfig YANG models. To determine the level of shared configuration an application allows, check the application-specific Nokia or the nokia-conf-combined.yang YANG models for the following extension statement.

sros-ext:shared-model-management {
    sros-ext:openconfig false;
}

If the above statement is found, the 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 are enabled.

[ex:configure system management-interface yang-modules]
A:admin@node-2# openconfig-modules true

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

[ex:/configure policy-options policy-statement "policy-1"]
A:admin@node-2# entry ?

 [entry-id] <number>
 <number> - <1..4294967295>

    Entry ID for a route policy entry

    Note: 'configure policy-options policy-statement "policy-1"' and all other elements 
    in this context must be managed by one data model.

Validating and committing a configuration

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:

the Nokia application requirements are not met
the list entry is managed by Nokia
a resource limit enforced by the application is exceeded by merging the OpenConfig configuration

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.

MINOR: MGMT_CORE #2205: configure port 1/1/4 ethernet access - OpenConfig and Nokia condition mismatch - failed condition

Errors can occur in situations such as the following:

the OpenConfig model attempts to deliver an incomplete configuration as required by the Nokia application
conflicts exist where an OpenConfig model attempts to access a list entry managed by Nokia
other delivery errors from the commit operation

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. The following example shows the structure of such an error message.

<severity>:<module> #<code>: <context in which the error occurred> <related context>
 - <error message>

Displaying the configuration

Several variations of the info command are available to display the configuration in output formats that show Nokia and converted third-party model configuration in different ways. The following examples show syslog server 10.1.1.2 that is managed by both OpenConfig and Nokia models with some leafs managed by either Nokia, OpenConfig, or both models. Syslog server 192.168.0.10 is managed entirely by the OpenConfig model.

info command

The following example shows the configuration starting at the present working context as in each model's native configuration syntax.

[ex:/configure openconfig system logging]
A:admin@node-2# info
    remote-servers {
        remote-server 10.1.1.2 {
            config {
                host 10.1.1.2
                source-address 10.1.1.2
                remote-port 456
            }
        }
        remote-server 192.168.0.10 {
            config {
                host 192.168.0.10
                source-address 192.168.0.10
                remote-port 456
            }
        }
    }

[ex:/configure log]
A:admin@node-2# info syslog *
    syslog "oc_rem_1.1.1.2" {
        address 1.1.1.2
        severity emergency
        port 540
    }

info converted command

The following example shows converted third-party model configuration from the running datastore with model management displayed as a comment above each configuration element:

## managed: nokia if the element is only managed by a Nokia model
## managed: openconfig if the element is only managed by an OpenConfig model
## managed: openconfig-nokia if the element is managed by both OpenConfig and Nokia models

Use this command to determine if two models are managing the same element, or if a model is managing an element that it is not intended to.

[ex:/configure log]
A:admin@node-2# info converted syslog *
    ## managed: openconfig-nokia
    syslog "oc_rem_10.1.1.2" {
        ## managed: openconfig-nokia
        address 10.1.1.2
        ## managed: nokia
        severity emergency
        ## managed: openconfig
        log-prefix "10.1.1.2"
        ## managed: openconfig-nokia
        port 540
    }
    ## managed: openconfig
    syslog "oc_rem_192.168.0.10" {
        ## managed: openconfig
        address 192.168.0.10
        ## managed: openconfig
        log-prefix "192.168.0.10"
        ## managed: openconfig
        port 456
    }

info converted model openconfig command

The following example shows converted OpenConfig model configuration from the running datastore with the ## managed: comment removed from the output. Use this command to show OpenConfig configuration in the Nokia format.

[ex:/configure log]
A:admin@cses-V93# info converted model openconfig syslog *
    syslog "oc_rem_10.1.1.2" {
        log-prefix "10.1.1.2"
    }
    syslog "oc_rem_192.168.0.10" {
        address 192.168.0.10
        log-prefix "192.168.0.10"
        port 456
    }

info converted values command

The following example shows converted third-party model configuration from the running datastore with all the values that each model tries to set. Use this command to determine if there are duplicate or different configuration commands in the Nokia and third-party models. The configuration set by the third-party model is prefixed with ## to indicate that the Nokia configuration has precedence and its value is in the running configuration. In the example below, both the Nokia and OpenConfig model set the address to 10.1.1.2, which is duplicate configuration. Both the Nokia and OpenConfig model set the port to different values, and the value 540 set by the Nokia model is in the running configuration.

[ex:/configure log]
A:admin@cses-V93# info converted full-context values syslog
    ## managed: openconfig
    ## /configure log syslog "oc_rem_10.1.1.2" { address 10.1.1.2 }
    ## managed: nokia
    /configure log syslog "oc_rem_10.1.1.2" { address 10.1.1.2 }
    ## managed: openconfig
    ## /configure log syslog "oc_rem_10.1.1.2" { port 456 }
    ## managed: nokia
    /configure log syslog "oc_rem_10.1.1.2" { port 540 }

info converted differences command

The following example shows converted third-party model configuration from the running datastore with only the values that are different that each model tries to set. Use this command to determine if there are different configuration values in the Nokia and third-party models. The configuration set by the third-party model is prefixed with ## to indicate that the Nokia configuration has precedence and its value is in the running configuration. In the following example, both the Nokia and OpenConfig model set the port to different values, and the value of 540 set by the Nokia model is in the running configuration.

[ex:/configure log]
A:admin@cses-V93# info converted full-context differences syslog
    ## managed: openconfig
    ## /configure log syslog "oc_rem_10.1.1.2" { port 456 }
    ## managed: nokia
    /configure log syslog "oc_rem_10.1.1.2" { port 540 }

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

Deviations and augments

Deviation files are created for the OpenConfig model when the model deviates from the application requirements of the system, 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-<OpenConfigModel>-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 to function as expected. The augments file follows the naming format nokia-sr-<OpenConfigModel>-augments.yang.

Datastores and regions

As described in RFC 8342 a datastore is a conceptual place to store and access information. A datastore maps to an instantiated YANG data tree. See RFC 8342 for more information about datastores.

SR OS supports conventional configuration datastores (for example, running and candidate) as well as some proprietary datastores (for example, li-running).

SR OS also has a proprietary concept called a region (or configuration region). The set of branches and elements in the configure branch of the CLI are all located in the primary configuration region simply called configure. The majority of SR OS configuration is in the configuration region including ports, interfaces, services and filters. Examples of other regions are:

bof (boot options file)
debug (debugging configuration)
li (lawful intercept)

Each region has its own configuration datastores (running, candidate, and so on). The saved configuration for each region is stored in a separate file on compact flash or remotely (for example, bof.cfg, debug.cfg, config.cfg, li.cfg). Regions are independently locked for configuration changes. See the output of the following command in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Clear, Monitor, Show, and Tools Command Reference Guide for an example of per-region per-datastore information.

 show system management-interface datastore-locks

NMDA support

SR OS supports the Network Management Datastore Architecture (NMDA) for the <intended> and <operational> datastores. When the nmda-support command is enabled, the following changes to the YANG model advertisements for NETCONF occur:

The ietf-yang-library:1.1 revision 2019-01-04 YANG module is advertised in the hello capabilities replacing the ietf-yang-library: 1.0 revision 2016-06-21 version.
The following additional YANG modules are advertised in the hello capabilities:
- nokia-datastores
- ietf-datastores
- ietf-netconf-nmda
- ietf-origin
The ietf-yang-library YANG module revision 2019-01-04 replaces the ietf-yang-library revision 2016-06-21 YANG module when using ietf-netconf-monitoring and ietf-yang-library modules-state.
The following additional YANG modules are advertised when using ietf-netconf-monitoring and ietf-yang-library modules-state:
- nokia-datastores
- ietf-datastores
- ietf-netconf-nmda
- ietf-origin

SPC objects

System-Provisioned Configuration (SPC) objects (configuration list elements and their descendants) are provided as a convenience to users in SR OS.

There are two basic classes of SPC objects: deletable and non-deletable.

Deletable SPC objects are placed into the configuration by SR OS but can be deleted (removed) by a user. The following characteristics apply to deletable SPC objects.

Deletable SPC objects can be removed or recreated via NETCONF <edit-config> requests.
Deletable SPC objects that have not been removed are visible in a NETCONF <get-config> response.
Deletable SPC objects that have been removed are not visible in model-driven interfaces.
In the classic CLI these are removed by specifying the keyword no, which is then visible in an info command or in a saved config (admin save); for example, no log-id 99.
The following list summarizes the deletable SPC objects in the SR OS (listed against their MD-CLI paths).

configure log filter 1001
configure log log-id (99,100)
configure system security user-params local-user user "admin"
configure system security aaa local-profiles profile "administrative"
configure system security aaa local-profiles profile "default"
configure system security ssh server-cipher-list-v2 cipher (190..230)
configure system security ssh client-cipher-list-v2 cipher (190..230)
configure system security ssh server-mac-list-v2 mac (200..240)
configure system security ssh client-mac-list-v2 mac (200..240)

Non-deletable SPC (ND-SPC) objects are not added to the configuration by SR OS, but they can be referenced by other parts of the configuration even if they are not visible as part of the configuration. The following characteristics apply to ND-SPC objects.

Some ND-SPC objects contain leafs (or other descendant elements) that can be modified (for example, cpu-protection policy 254). Some ND-SPC objects cannot be modified (for example, qos sap-ingress ‟default”).
ND-SPC objects are not displayed in model-driven interfaces as part of the configuration unless a user explicitly creates the object. This explicit creation of ND-SPC objects is only supported when operating in model-driven configuration mode; it is not supported in mixed configuration mode. When a user explicitly creates an ND-SPC object, SR OS remembers that it was explicitly created and displays it as part of the configuration. This may be useful for NETCONF clients and tools that perform offline validation of the configuration against the SR OS YANG models and to resolve leafrefs that point to ND-SPC objects.
Deleted ND-SPC objects in model-driven interfaces no longer appear as part of the configuration. All descendant elements are reset as unconfigured.
ND-SPC objects can be referenced by other parts of the configuration regardless of whether they have been modified or created.
ND-SPC objects created inside a configuration group in model-driven interfaces do not appear in the output of info intended or info inheritance.
ND-SPC objects are not displayed in the classic CLI as part of the configuration unless a child or descendant element is modified. Some exceptions to this behavior include the following examples.
```
configure service customer 1 name ‟1”
configure system security cpu-protection policy 254
```
ND-SPC objects cannot be deleted in the classic CLI. A deletion attempt returns an error.

The following non-deletable SPC objects are the common ones used.

configure service customer "1"
configure qos sap-egress queue 1
configure qos sap-ingress queue (1,11)

The following list summarizes the non-deletable SPC objects in the SR OS (listed against their MD-CLI paths).

Note: Support for commands in the following list depends on the type of router. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide for support information.

bof port "management"
bof router "management"
bof router interface "management"
configure application-assurance group partition cflowd export-type ("volume","tcp-performance","rtp-performance","comprehensive","pgw-edr")
configure application-assurance group partition policy app-group "Unknown"
configure application-assurance group partition policy application "Unknown"
configure application-assurance group partition statistics aa-sub-study ("protocol","application")
configure call-trace location (cf1,cf2)
configure call-trace trace-profile "default"
configure call-trace trace-profile ‟default”
configure card fp ingress network pool "default"
configure cflowd sample-profile 1
configure eth-cfm default-domain bridge-identifier <x>
configure filter log 101
configure lag scheduler vlan-qos-policy "default"
configure log log-events (adp event tmnxDiscoveryEndNotify ... wpp event tmnxWppPGHostAuthFailed)
configure log log-id 101
configure multicast-management bandwidth-policy "default"
configure multicast-management multicast-info-policy "default"
configure multicast-management multicast-info-policy bundle "default"
configure oam-pm bin-group 1
configure oam-pm bin-group bin-type (fd,fdr,ifdv)
configure oam-pm bin-group bin-type bin (0..2)
configure port ethernet egress port-scheduler-policy overrides level (1..8)
configure port ethernet lldp dest-mac (nearest-bridge,nearest-non-tpmr,nearest-customer)
configure port ethernet lldp dest-mac tx-mgmt-address (oob,system,system-ipv6,oob-ipv6)
configure port scheduler vlan-qos-policy "default"
configure port tdm ds1 channel-group egress port-scheduler-policy overrides level (1..8)
configure port tdm ds3 channel-group egress port-scheduler-policy overrides level (1..8)
configure port tdm e1 channel-group egress port-scheduler-policy overrides level (1..8)
configure port tdm e3 channel-group egress port-scheduler-policy overrides level (1..8)
configure qos fp-resource-policy "default"
configure qos fp-resource-policy aggregate-shapers queue-sets size (2..8)
configure qos hw-agg-shaper-scheduler-policy sched-class (1..6)
configure qos network "default"
configure qos network egress fc (be,l2,af,l1,h2,ef,h1,nc)
configure qos network ingress fc (be,l2,af,l1,h2,ef,h1,nc)
configure qos network-queue "default"
configure qos network-queue queue (1,9)
configure qos policer-control-policy root priority-mbs-thresholds priority (1..8)
configure qos policer-control-policy root tier (1,2)
configure qos port-scheduler-policy level (1..8)
configure qos queue-group-templates egress queue-group "policer-output-queues"
configure qos queue-group-templates egress queue-group queue 1
configure qos queue-group-templates egress queue-group sched-class-elevation sched-class (1..6)
configure qos sap-egress "default"
configure qos sap-egress queue 1
configure qos sap-egress sched-class-elevation sched-class (1..6)
configure qos sap-ingress "default"
configure qos sap-ingress queue (1,11)
configure qos scheduler-policy tier (1..3)
configure qos shared-queue "egress-pbr-ingress-queues"
configure qos shared-queue "policer-output-queues"
configure qos shared-queue fc be
configure qos slope-policy "_tmnx_hs_default"
configure qos slope-policy "default"
configure router ("Base","management","vpls-management")
configure router bgp convergence family (ipv4,vpn-ipv4,ipv6,vpn-ipv6,label-ipv4,label-ipv6)
configure router bgp multipath family (ipv4,ipv6,label-ipv4,label-ipv6)
configure router bgp next-hop-resolution labeled-routes transport-tunnel family (vpn,label-ipv4,label-ipv4)
configure router bgp next-hop-resolution shortcut-tunnel family (ipv4,ipv6)
configure router interface ("system","management")
configure router interface network-domains network-domain "default"
configure router isis 0 igp-shortcut tunnel-next-hop family (ipv4,ipv6,srv4,srv6)
configure router isis interface level (1,2)
configure router isis level (1,2)
configure router isis link-group level (1,2)
configure router isis segment-routing-v6 locator level (1,2)
configure router isis segment-routing-v6 micro-segment-locator level (1,2)
configure router mpls class-forwarding-policy fc (be,l2,af,l1,h2,ef,h1,nc)
configure router mpls interface "system"
configure router mpls lsp auto-bandwidth fc (be,l2,af,l1,h2,ef,h1,nc)
configure router mpls lsp-template auto-bandwidth fc (be,l2,af,l1,h2,ef,h1,nc)
configure router network-domains network-domain "default"
configure router network-domains network-domain ‟default”
configure router ospf igp-shortcut tunnel-next-hop family (ipv4,srv4)
configure router ospf3 igp-shortcut tunnel-next-hop family (ipv4,ipv6,srv4,srv6)
configure router p2mp-sr-tree p2mp-policy candidate-path path-instances (1,2)
configure router rsvp interface "system"
configure router sgt-qos...
configure service cpipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service cpipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service customer "1"
configure service epipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service epipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service ies interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service ies interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service ies subscriber-interface group-interface wlan-gw vlan-range "unmatched"
configure service ipipe sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service ipipe sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service vpls interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service vpls interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service vprn bgp multipath family (ipv4,ipv6,label-ipv4,label-ipv6)
configure service vprn interface sap egress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service vprn interface sap ingress qos policer-control-policy overrides root priority-mbs-thresholds priority (1..8)
configure service vprn isis interface level (1,2)
configure service vprn isis level (1,2)
configure service vprn isis link-group level (1,2)
configure service vprn sgt-qos...
configure service vprn subscriber-interface group-interface wlan-gw vlan-range "unmatched"
configure subscriber-mgmt gtp peer-profile ("default","default_s11")
configure subscriber-mgmt ipoe-session-policy "_tmnx_bonding"
configure subscriber-mgmt ipoe-session-policy "default"
configure subscriber-mgmt ppp-policy "default"
configure system alarm-contact-input (1..4)
configure system fp resource-allocation lpm scale-option (1..4)
configure system fp resource-allocation pool (1,2)
configure system power-management 1
configure system ptp router "Base"
configure system security cpu-protection policy (254,255)
configure system security dist-cpu-protection policy ("_default-access-policy","_default-network-policy","_default-port-policy")
configure system security snmp access group (cli-li-readwrite,cli-readonly,cli-readwrite,cli-vprn-readwrite,snmp-mgmt,snmp-ro,snmp-rw,snmp-rwa,snmp-trap,snmp-vpls-mgmt,snmp-vprn,snmp-vprn-ro)
configure system security snmp view (iso,li-view,mgmt-view,no-security,vprn-view)
configure system security user-template {tacplus-default,radius-default,ldap-default}
configure system usb "cf2"
configure test-oam service-activation-testhead acceptance-criteria-template "default"
configure test-oam service-activation-testhead frame-size-template "default"
configure test-oam twamp twamp-light source-udp-port-pools port (64374..64383)

Prerequisites for using model-driven management interfaces with classic configurations

These sections apply to using model-driven management interfaces with existing classic configurations by changing the configuration mode. The classic configuration is automatically converted to model-driven configuration format by the system when the configuration mode is changed to model-driven. Before configuration editing is permitted in model-driven interfaces, configure system management-interface configuration-mode must be set to model-driven or mixed after the prerequisites are completed.

Transitioning between modes

Perform the following steps before setting the management interface configuration mode to mixed or model-driven.

Verify that the system configuration only contains commands that are supported in model-driven interfaces. For more information, see section ‟Unsupported Configuration in MD Interfaces” in the SR OS R23.x.Rx Software Release Notes, part number 3HE 19269 000 x TQZZA.
Update the system configuration to meet the prerequisites described in Prerequisites for using model-driven management interfaces with classic configurations.

Perform a mode change configuration check as follows.

Use the following command to check if the configuration meets the preceding prerequisite reference requirements to change the management interface configuration mode. Incompatible configuration commands are displayed with an error reason if the prerequisite is not met.

tools perform system management-interface configuration-mode check

Note: The command does not check if the configuration contains commands that are unsupported in model-driven interfaces. For more information, see section ‟Unsupported Configuration in MD Interfaces” in the SR OS R23.x.Rx Software Release Notes, part number 3HE 19269 000 x TQZZA.

The following example shows the output of the configuration-mode check command when there are incompatible configuration commands.

===============================================================================
Mode Switch Validation Check
===============================================================================
Current Mode       : classic            Desired Mode       : model-driven
Configure          : Errors Detected    LI                 : No Errors
-------------------------------------------------------------------------------
Configuration Validation Errors
-------------------------------------------------------------------------------
1  : MINOR: MGMT_CORE #2004 Incompatible configuration - dynsvc-password
     configured in system security password
2  : MINOR: MGMT_CORE #2004 Incompatible configuration - 'eth-cfm association
     bridge-identifier' reference to service-id exists
3  : MINOR: MGMT_CORE #2004 Incompatible configuration - ca-profile cmpv2 url
     service-id references exist
4  : MINOR: MGMT_CORE #224 Entry does not exist (MD-CLI: configure policy-
     options policy-statement "PEERING_ROUTER_OUT" entry 50 from prefix-list)
-------------------------------------------------------------------------------
Action required: configuration requires updating before mode switch
===============================================================================

Save and back up your configuration. Existing configuration is converted to the MD-CLI format if the mode is changed to model-driven and the saved configuration file is in MD-CLI format.
Change the configuration mode to mixed or model-driven as follows.
Note:
- Depending on the size of the system configuration, transitioning 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.
1. If using mixed mode, set the configuration mode to mixed by issuing the following commands:
```
configure system management-interface cli md-cli auto-config-save
configure system management-interface configuration-mode mixed
```
  Log out and start a new CLI session to access the MD-CLI engine.
2. If using model-driven mode, set the configuration mode to model-driven by issuing the following commands:
```
configure system management-interface cli md-cli auto-config-save
configure system management-interface configuration-mode model-driven
```
  Log out and start a new CLI session to access the MD-CLI engine. When a new user session begins, the MD-CLI engine is available and the MD-CLI prompt is displayed.
Save the configuration manually.
- In mixed mode, issue admin save from the classic CLI.
- In model-driven mode, issue admin save from the MD-CLI.

Configuring the CLI engine

The CLI engine refers to the CLI environment used in a user session (for example, console, Telnet, or SSH) to configure and operate the router. The CLI engine is either the classic CLI engine or the MD-CLI engine. The following terms are also used:

preferred CLI engine: the CLI engine that is started at user login
authorized CLI engine: a CLI engine that a user can switch to (using the CLI engine switch command (‟//”)) or where a user can execute commands
active CLI engine: the CLI engine that is currently in use for a user session

The default preferred CLI engine and authorized CLI engines for a session are determined by the management interface configuration mode, which eliminates the need to explicitly configure the CLI engine. With the use of these dynamic defaults, it is possible to transition between the different configuration modes. Management interface configuration modes and CLI engines summarizes the CLI engines for the management interface configuration modes.

Table 2. Management interface configuration modes and CLI engines
Management interface configuration mode	Default preferred CLI engine	Default authorized CLI engines
classic	classic-cli	classic-cli
mixed	classic-cli	md-cli, classic-cli
model-driven	md-cli	md-cli, classic-cli (read-only)

The preferred and authorized CLI engines for a session can be changed to use either the classic CLI or the MD-CLI engine.

In the classic CLI, the first engine configured is the preferred CLI engine. The default is no cli-engine.

A:node-2>config>system>management-interface>cli# cli-engine ?
  - cli-engine <engine-type> [<engine-type>...(upto 2 max)]
  - no cli-engine

 <engine-type>        : classic-cli|md-cli

In the MD-CLI, the cli-engine command is a user-ordered list, and the first engine from that list is configured as the preferred CLI engine. Leaving the cli-engine command unconfigured (or deleting the cli-engine values) maintains or reverts to the dynamic default. MD-CLI cli-engine configurations summarizes the supported actions for the MD-CLI cli-engine configuration.

Note: For the changes to the cli-engine command to take effect, log out of the CLI session and start a new session.

Table 3. MD-CLI cli-engine configurations
cli-engine configuration	Preferred CLI engine	Authorized CLI engines	Description
[classic-cli]	classic-cli	classic-cli	User is restricted to the classic CLI engine
[classic-cli md-cli]	classic-cli	classic-cli, md-cli	User can switch between classic CLI and MD-CLI engines in a session
[md-cli classic-cli]	md-cli	md-cli, classic-cli	User can switch between MD-CLI and classic CLI engines in a session
[md-cli]	md-cli	md-cli	User is restricted to the MD-CLI engine

Loose references to IDs

A loose reference does not require the target of the reference to exist in the configuration.

For example, when the management interface configuration mode is classic, you cannot configure the following command, even if ip-filter 37 does not exist in the configuration.

configure service pw-template 23 egress filter ip 37

Before switching from the classic 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:

all services including the following;

configure service vprn
configure service vpls
configure service epipe

the following mirror element
```
configure mirror mirror-dest
```

the following service elements

configure service pw-templates
configure service customer

the following filter elements

configure filter ip-filter
configure filter ipv6-filter
configure filter mac-filter

the following QoS elements

configure qos network
configure qos sap-ingress
configure qos sap-egress

the following Ethernet CFM elements

configure eth-cfm domain
configure eth-cfm association

Note: A name can only be assigned to a filter or any element in the preceding 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 before an upgrade to Release 15.1.R1.

A name can also be changed in releases before 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 in the preceding list 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 following commands.

In the following example, a configuration is shown for the service PW template egress filter.

configure service pw-template 23 egress filter ip 37

You can change this configuration to the following.

configure service pw-template 23 egress filter-name ip ops-sec-filter-a33

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

configure filter ip-filter 37 name ops-sec-filter-a33

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:

configure service vprn interface sap ipsec-tunnel local-gateway-address 
configure service vprn interface sap ip-tunnel delivery-service
configure service vprn interface sap l2tpv3-session router
configure service epipe sap l2tpv3-session router
configure service vpls sap l2tpv3-session router
configure service vprn interface sap ipsec-gw default-secure-service
configure service ies interface sap ipsec-gw default-secure-service
configure service vprn interface sap ipsec-gw dhcp server
configure service ies interface sap ipsec-gw dhcp server
configure service vprn interface sap ipsec-gw dhcp6 server
configure service ies interface sap ipsec-gw dhcp6 server
configure service vprn interface sap ipsec-gw local-address-assignment ipv4 address-
source
configure service vprn interface sap ipsec-gw local-address-assignment ipv6 address-
source
configure service ies interface sap ipsec-gw local-address-assignment ipv4 address-
source
configure service ies interface sap ipsec-gw local-address-assignment ipv6 address-
source
configure service vprn interface sap ipsec-tunnel bfd-enable
configure ipsec client-db client private-service
configure system file-transmission-profile router

eth-cfm, oam-pm, and saa:

configure eth-cfm domain association bridge-identifier
configure oam-pm session ip router
configure oam-pm session ip router service-name
configure saa test type cpe-ping service
configure saa test type icmp-ping router
configure saa test type icmp-ping service-name
configure saa test type icmp-trace router
configure saa test type icmp-trace service-name
configure saa test type mac-ping service
configure saa test type mac-trace service
configure saa test type vprn-ping
configure saa test type vprn-ping service
configure saa test type vprn-trace
configure saa test type vprn-trace service

Filters:

configure service pw-template egress filter ipv6
configure service pw-template egress filter ip
configure service pw-template egress filter mac
configure service pw-template ingress filter ipv6
configure service pw-template ingress filter ip
configure service pw-template ingress filter mac

configure service template epipe-sap-template egress filter ip
configure service template epipe-sap-template egress filter ipv6
configure service template epipe-sap-template egress filter mac
configure service template epipe-sap-template ingress filter ip
configure service template epipe-sap-template ingress filter ipv6
configure service template epipe-sap-template ingress filter mac

configure service template vpls-sap-template egress filter ip
configure service template vpls-sap-template egress filter ipv6
configure service template vpls-sap-template egress filter mac
configure service template vpls-sap-template ingress filter ip
configure service template vpls-sap-template ingress filter ipv6
configure service template vpls-sap-template ingress filter mac

configure li li-filter-block-reservation li-reserved-block ip-filter
configure li li-filter-block-reservation li-reserved-block ipv6-filter
configure li li-filter-block-reservation li-reserved-block mac-filter

PKI:

configure system security pki ca-profile cmpv2 url
configure system security pki ca-profile ocsp service

QoS:

configure service template epipe-sap-template ingress qos
configure service template epipe-sap-template egress qos

configure service template vpls-sap-template ingress qos
configure service template vpls-sap-template egress qos

configure service pw-template ingress qos
configure service pw-template egress qos

Subscriber management:

configure service ies subscriber-interface group-interface srrp bfd-enable
configure service vprn subscriber-interface group-interface srrp bfd-enable

 
configure subscriber-mgmt local-user-db ipoe host host-identification service-id
configure subscriber-mgmt local-user-db ipoe host interface service-id
configure subscriber-mgmt local-user-db ipoe host match-radius-proxy-cache server
configure subscriber-mgmt local-user-db ipoe host msap-defaults service
configure subscriber-mgmt local-user-db ipoe host retail-service-id

configure subscriber-mgmt local-user-db ppp host interface service-id
configure subscriber-mgmt local-user-db ppp host l2tp group service-id
configure subscriber-mgmt local-user-db ppp host msap-defaults service
configure subscriber-mgmt local-user-db ppp host retail-service-id

configure subscriber-mgmt msap-policy vpls-only-sap-parameters igmp-snooping mvr 
from-vpls

configure service vpls sap msap-defaults service

Miscellaneous:

configure vrrp policy
configure service vprn interface vrrp bfd-enable

configure service vprn interface ipv6 vrrp bfd-enable
configure router l2tp group ppp default-group-interface service-id
configure router l2tp group tunnel ppp default-group-interface service-id
configure service vprn l2tp group ppp default-group-interface service-id
configure service vprn l2tp group tunnel ppp default-group-interface service-id

configure redundancy multi-chassis peer mc-ring l3-ring in-band-control-path 
service-id
configure redundancy multi-chassis peer mc-ring l3-ring ring-node connectivity-
verify service-id
configure redundancy multi-chassis peer mc-ring ring in-band-control-path service-id
configure redundancy multi-chassis peer mc-ring ring ring-node connectivity-verify 
service-id

configure open-flow of-switch of-controller vprn

Strict routing policy validation

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

ARP and ND in the Base router and VPRN instances
BGP in the Base router and VPRN instances
global and local variables in main policies and sub-policies
IGMP, MLD, and PIM in the Base router and VPRN instances
IS-IS in the Base router and VPRN instances
LDP
OSPF and OSPFv3 in the Base router and VPRN instances
policy-option in from, to, action, and default-action statements
policy-option in sub-policies, prefix-list, as-path, as-path-group, damping, and community policies
RIP and RIPng in the Base router and VPRN instances
RSVP
single policy-statement or logical policy expressions
static routes in the Base router and VPRN instances
subscriber management, except for in mld-policy configuration for a local user database (LUDB) host
VPLS for BGP VSI
VPRN for GRT, MVPN, and VRF

String names as keys

Many elements use string names as keys in model-driven interfaces instead of the numerical identifiers used in the classic CLI and SNMP.

Note: The string name can only be assigned or modified for these elements in releases before Release 15.1.R1. Elements without names are automatically assigned a name (the identifier 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.

It is recommended that you assign names to the following elements before an upgrade to Release 15.1 or later:

all services including the following;

configure service vprn
configure service vpls
configure service epipe

the following mirror element
```
configure mirror mirror-dest
```
the following service elements
```
configure service pw-templates
configure service customer
```

the following filter elements

configure filter ip-filter
configure filter ipv6-filter
configure filter mac-filter

the following QoS elements
```
configure qos network
configure qos sap-ingress
configure qos sap-egress
```
the following Ethernet CFM elements
```
configure eth-cfm domain
configure eth-cfm association
```

Commit history

The commit history provides a persistent history of configuration changes committed in model-driven interfaces. A separate history of the last commits (default 50, up to 200) is maintained for each configuration region (bof, configure, debug, and li). Each commit is uniquely identified by a numerical sequential incrementing commit ID assigned by the system.

In the MD-CLI, use the following show command to view the commit history or use the state model:

show system management-interface commit-history
state system management-interface configuration-region commit-history

The saved configuration file header also displays the commit history from the last configuration save.

An optional commit comment can be entered using the MD-CLI commit comment command or the NETCONF <commit> RPC. Newline separators (\n) can be entered in the comment string to display multiple comment lines.

The following example shows the first commit made by the system when the router boots, followed by two commits by a user with the MD-CLI.

System and user commits with MD-CLI

[ex:/configure]
A:admin@node-2# commit comment "Second commit with the MD-CLI."

[ex:/configure]
A:admin@node-2# commit comment "Third commit with the MD-CLI."

[ex:/configure]
A:admin@node-2# show system management-interface commit-history

===============================================================================
Commit History
===============================================================================
Total Commits : 3

3
  Committed 2022-02-01T11:01:03.8-05:00 by admin (MD-CLI) from 10.1.145.205
  Comment   "Third commit with the MD-CLI."
  Location  "cf3:\config.cfg"
2
  Committed 2022-02-01T11:00:47.7-05:00 by admin (MD-CLI) from 10.1.145.205
  Comment   "Second commit with the MD-CLI."
  Location  "cf3:\config.cfg.1"
1
  Committed 2022-02-01T10:56:01.3-05:00 by system (MD-CLI) from Console
  Log       "System booted version B-22.2.R1."
  Location  "Configuration is not saved to startup."

The following example shows a fourth commit made by automation using the NETCONF <commit> RPC with the <comment> augmentation.

NETCONF <commit> RPC with <comment> augmentation

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <commit>
        <comment>Fourth commit with NETCONF.</comment>
    </commit>
 </rpc>
]]>]]>

Use the following command to display the commit history after the preceding activity.

show system management-interface commit-history

===============================================================================
Commit History
===============================================================================
Total Commits : 4

4
  Committed 2022-02-01T11:13:38.7-05:00 by admin (NETCONF) from 10.1.236.68
  Comment   "Fourth commit with NETCONF."
  Location  "cf3:\config.cfg"
3
  Committed 2022-02-01T11:01:03.8-05:00 by admin (MD-CLI) from 10.1.145.205
  Comment   "Third commit with the MD-CLI."
  Location  "cf3:\config.cfg.1"
2
  Committed 2022-02-01T11:00:47.7-05:00 by admin (MD-CLI) from 10.1.145.205
  Comment   "Second commit with the MD-CLI."
  Location  "cf3:\config.cfg.2"
1
  Committed 2022-02-01T10:56:01.3-05:00 by system (MD-CLI) from Console
  Log       "System booted version 22.2.R1."
  Location  "Configuration is not saved to startup."

The following usage guidelines apply to the commit history.

The commit history is supported in model-driven configuration mode only.
The system files located in the cf3:\.commit-history directory must not be edited or deleted, and user files must not be stored there.
Saved configuration files that are referenced by the commit must not be edited or deleted.
Editing the BOF from the boot loader does not create a commit history entry.
Nokia recommends setting the commit history value to at least 50, which is the default value. The commit history can be disabled by setting the value to 0.
Use the MD-CLI environment time-format and environment time-display options to change the time formats displayed in the output of the following commands.
```
show system management-interface commit-history
info state system management-interface <region-name> commit-history
admin show configuration 
```
The time formats in admin show configuration are in the generated and finished lines.
The MD-CLI environment commands do not change any time formats in the saved configuration file header or footer. These time formats are always written in RFC 3339 format in the Coordinated Universal Time (UTC) or local time zone. Use the following command to configure the value.
```
configure system time prefer-local-time
```

Incremental saved configuration files

When incremental saved configuration files are enabled, the system saves each configuration commit to the configure configuration region in a separate incremental saved configuration file, instead of saving a complete saved configuration file each time. This mechanism makes commits over model-driven interfaces (the MD-CLI, NETCONF and gRPC/gNMI) much faster, because less configuration needs to be saved.

When the system boots or the rollback command is issued, the last complete saved configuration file is loaded first, and then any required incremental saved configuration files are loaded in the sequence they were committed to apply the previous saved configuration.

The commit history displays information about incremental and complete saved configuration files. The "Location" field displays the complete saved configuration file location, and the "Increment" field displays the incremental saved configuration file location. When the "Location" field is not displayed, the incremental saved configuration file in the "Increment" field is loaded as described above.

Use the following command to show the commit history.

show system management-interface commit-history

Commit history showing the incremental saved configuration file location

===============================================================================
Commit History
===============================================================================
Total Commits : 2

2
  Committed 2022-06-21T12:55:05.4-04:00 by admin (MD-CLI) from 192.168.0.10
  Increment "cf3:\.commit-history\config-2022-06-21T16-55-05.4Z-4.is"
1
  Committed 2022-06-21T12:49:31.4-04:00 by admin (MD-CLI) from 192.168.0.10
  Increment "cf3:\.commit-history\config-2022-06-21T16-49-31.4Z-3.is"
  Location  "cf3:\config.cfg"

A background process generates a complete saved configuration file periodically to reduce the number of incremental saved configuration files that are needed by system. The commit history is updated with a "Location" field like in the following example.

Commit history showing the complete saved configuration file location

===============================================================================
Commit History
===============================================================================
Total Commits : 2

2
  Committed 2022-06-21T12:55:05.4-04:00 by admin (MD-CLI) from 192.168.0.10
  Increment "cf3:\.commit-history\config-2022-06-21T16-55-05.4Z-4.is"
  Location  "cf3:\config.cfg"
1
  Committed 2022-06-21T12:49:31.4-04:00 by admin (MD-CLI) from 192.168.0.10
  Increment "cf3:\.commit-history\config-2022-06-21T16-49-31.4Z-3.is"
  Location  "cf3:\config.cfg.1"

Incremental saved configuration files are enabled with the configure system management-interface configuration-save incremental-saves command, and must be configured together with the following commands.

configure system management-interface configuration-mode must be model-driven
configure system grpc gnmi auto-config-save must be set to true
configure system management-interface cli md-cli auto-config-save must be set to true
configure system management-interface netconf auto-config-save must be set to true
configure system management-interface commit-history must be ≧ 50
configure system management-interface configuration-save configuration-backup must be ≧ configure system management-interface commit-history
configure redundancy synchronize must be config or boot-env on systems that support redundancy

The following usage guidelines apply:

The commit history and incremental saved configuration files in the cf3:\.commit-history directory must not be edited by the user
Multiple configuration save and synchronization events occur because additional system files are saved and synchronized between the active and standby CPM
The first commit after a system boot or ISSU is followed by a complete save if an admin save command was not executed
The configuration must be saved by executing the admin save command before executing the admin redundancy force-switchover command

YANG-modeled operations

In addition to YANG-based configuration and state, the SR OS also supports YANG-based operations (for example, admin reboot, file remove).

The SR OS YANG-modeled operations infrastructure applies to MD-CLI and NETCONF interfaces and is supported in any management interface configuration mode (classic, mixed, or model-driven). It is not applicable to operations requested in classic CLI, SNMP, or gRPC interfaces.

YANG-based operations are allocated an operation ID. You can examine the details of an operation, including the following information:

execution status of the operation: in-progress, terminated, or terminated-incomplete
start-time of the operation
timeouts associated with the operation

Use the following command to configure the operation ID as an index into the global operations table to examine the details of an operation.

state system management-interface operations operation

Contents of the global operations table when a file remove-directory command is in progress

[/]
A:admin@node-2# info state system management-interface operations
    oldest-operation-id 4
    newest-operation-id 4
    operation 4 {
        asynchronous false
        status in-progress
        start-time 2021-04-13T16:13:18.1+00:00
        request-path "/file/remove-directory"
        session-id 13
        user "admin"
    }

Configure and use the operation ID to remove an operation. Use the following command to remove an operation:

admin system management-interface operations delete-operation

In the case where the global operations table is full, the delete-operation command can optionally be requested with the op-table-bypass option to avoid allocating an operation-id and requiring an empty entry in the table.

Asynchronous versus synchronous operations

SR OS supports the following basic response modes for YANG-modeled operations:

synchronous

This is the default response mode. This mode is supported on MD-CLI and NETCONF.
asynchronous

This mode is supported only on NETCONF.

In synchronous mode, the response to the operation request contains the complete result data and is held until the operation is complete. No additional operations can be initiated in the same management session (MD-CLI or NETCONF) until the previous operation completes. This behavior is evident in MD-CLI, for example, where the MD-CLI prompt does not return and no input is accepted until the currently running operation is completed.

In asynchronous mode, the response to the operation request does not contain the result data and is sent without waiting for the operation to complete. The request only starts the operation and the client (requester) obtains the result later. Users can perform other commands in the management session while the asynchronous operation runs in the background.

The response to an asynchronous operation request contains an operation ID. This ID is a handle for the operation and allows users to:

query the status of the operation
stop or delete the operation

Synchronous operations require a management session (NETCONF or MD-CLI) for each concurrent operation, whereas a single management session can manage hundreds of concurrent asynchronous operations.

Only a subset of SR OS operational commands are supported in the asynchronous response mode. See the SR OS nokia-oper-*.yang files for actions with the ‟asynchronous” leaf as part of the input to identify operations that support asynchronous mode.

The following figure shows a typical flow for an asynchronous operation.

A stopped asynchronous operation (for example, stopped using the stop-operation command) stays in the global operations table until it is explicitly deleted using a delete-operation command or the retention timeout expires. Synchronous operations are automatically removed from the global operations table when they are completed or stopped.

Note:

Because of the parallel processing nature of asynchronous operations, it is possible that an operation completes before the original requester of the operation receives a reply to the request. This means a client could receive a notification about an operation ID that the client does not yet know about.

Examples of operations in the MD-CLI

All operations in the MD-CLI execute in synchronous response mode.

The following example shows an operation with no specific result data to return.

MD-CLI operation with no result data to return

[/]
A:admin@mode-2# admin clear security password-history all

The following examples show operations that return result data.

MD-CLI operation with result data

[/]
A:admin@node-2# file version cf3://image/both.tim
TiMOS-C-21.5.R1 for x86_64
Wed May 19 15:02:26 PDT 2021 by builder in /builds/c/215B/R1/panos/main/sros

The following example shows another operation that returns result data.

[/]
A:node-2# oam eth-cfm loopback aa:bb:cc:dd:ee:22 md-admin-name MyDomain 
ma-admin-name MyAssociation mep-id 1 size 0 send-count 5 interval 10 timeout 5

Eth-Cfm Loopback Test Initiated: Mac-Address: aa:bb:cc:dd:ee:22, out sap: 2/2/1:20

38 bytes; lb_seq=1 passed
38 bytes; lb_seq=2 passed
38 bytes; lb_seq=3 passed
38 bytes; lb_seq=4 passed
38 bytes; lb_seq=5 passed

Sent 5 packets, received 5 packets [0 out-of-order, 0 Bad Msdu]
Packet loss 0.00%

Examples of synchronous operations in NETCONF

The following example shows synchronous operation that returns no result data.

synchronous operation that returns no result data

Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <action xmlns="urn:ietf:params:xml:ns:yang:1">
    <admin xmlns="urn:nokia.com:sros:ns:yang:sr:oper-admin">
        <clear>
            <security>
                <password-history>
                    <all/>
                </password-history>
            </security>
        </clear>
    </admin>
  </action>
</rpc>
]]>]]>

Response:

<?xml version="1.0" encoding="UTF-8"?>  
       xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-admin">
    <nokiaoper:operation-id>12</nokiaoper:operation-id>
    <nokiaoper:start-time>2021-06-16T20:11:44.9Z</nokiaoper:start-time>
    <nokiaoper:status>completed</nokiaoper:status>
    <nokiaoper:end-time>2021-06-16T20:11:44.9Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>

The following example shows a synchronous operation that returns result data.

synchronous operation that returns result data

Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <action xmlns="urn:ietf:params:xml:ns:yang:1">
    <file xmlns="urn:nokia.com:sros:ns:yang:sr:oper-file">
        <version>
            <url>cf3://image/both.tim</url>
        </version>
    </file>
  </action>
</rpc>
]]>]]>

Response:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
       xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-file">
    <nokiaoper:operation-id>17</nokiaoper:operation-id>
    <nokiaoper:start-time>2021-06-16T20:37:40.3Z</nokiaoper:start-time>
    <nokiaoper:results>
        <nokiaoper:version>
             <nokiaoper:version-number>C-21.5.R1</nokiaoper:version-number>
             <nokiaoper:version-string>TiMOS-C-21.5.R1 for x86_64 Wed May 19 15:02:26
             PDT 2021 by builder in /builds/c/215B/R1/panos/main/sros</nokiaoper:
             version-string>
        </nokiaoper:version>
    </nokiaoper:results>
    <nokiaoper:status>completed</nokiaoper:status>
    <nokiaoper:end-time>2021-06-16T20:37:40.4Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>

To see log events for synchronous operations, MGMT_CORE event #2006 (syncOperationsStatusChange) must first be enabled by configuring it to generate events using the following command:

MD-CLI

configure log log-events mgmt-core event syncOperationStatusChange generate

classic CLI

configure log event-control "mgmt_core" syncOperationStatusChange generate

Examples of asynchronous operations in NETCONF

The following example shows asynchronous operations in NETCONF.

asynchronous operations in NETCONF

Request:

<?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <action xmlns="urn:ietf:params:xml:ns:yang:1">
        <global-operations xmlns="urn:nokia.com:sros:ns:yang:sr:oper-global">
          <oam>
            <eth-cfm>
              <loopback>
                <asynchronous>true</asynchronous>
                <destination>aa:bb:cc:dd:ee:22</destination>
                <md-admin-name>MyDomain</md-admin-name>
                <ma-admin-name>MyAssociation</ma-admin-name>
                <mep-id>1</mep-id>
                <send-count>5</send-count>
                <timeout>5</timeout>
                <interval>10</interval>
              </loopback>
            </eth-cfm>
          </oam>
        </global-operations>
      </action>
    </rpc>
  ]]>]]>

Response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
       xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-global">
    <nokiaoper:operation-id>111</nokiaoper:operation-id>
    <nokiaoper:start-time>2021-06-16T14:17:18.3Z</nokiaoper:start-time>
    <nokiaoper:status>in-progress</nokiaoper:status>
</rpc-reply>
]]>]]>

The following example shows the global operations table status while the operation is running.

global operations table status while an operation is running

[/]
A:admin@node-2# info state system management-interface operations
    oldest-operation-id 111
    newest-operation-id 111
    operation 111 {
        asynchronous true
        status in-progress
        start-time 2021-06-16T10:17:18.3-04:00
        request-path "/global-operations/oam/eth-cfm/loopback"
        session-id 21
        user "admin"
        execution-timeout {
            time 2021-06-16T11:17:18.3-04:00
            remaining 3599
        }
    }
    next-execution-timeout {
        operation-id 111
        time 2021-06-16T11:17:18.3-04:00
        remaining 3599
    }

Use the following command to display log event output when the operation is completed.

show log log-id 99

The following example shows the log event output.

Note: Log events for asynchronous actions are enabled by default, but for synchronous operations, the log events are disabled by default. For more information, see Examples of synchronous operations in NETCONF.

Display log event output for completed operations

===============================================================================
Event Log 99 log-name 99
===============================================================================
Description : Default System Log
Memory Log contents  [size=500   next event=5  (not wrapped)]

4 2021/06/16 10:17:22.400 EDT WARNING: MGMT_CORE #2005 Base Operation
"operation-id 111 finished with status completed. Presence of messages in the global operations 
table: error-messages false, warning-messages false, info-messages false."

The following is an example of the results available in the state branch.

Results available in the state branch

[/]
A:admin@node-2# info state eth-cfm domain MyDomain association MyAssociation mep 1
    loopback-results {
        unicast-latest-run {
            test-status completed
            start-time 2021-06-16T10:17:18.0-04:00
            end-time 2021-06-16T10:17:22.0-04:00
            destination-mac-address aa:bb:cc:dd:ee:22
            statistics {
                sent-packets 5
                received-in-order 5
                received-out-of-order 0
                received-bad-msdu 0
                packet-loss 0.0
            }
        }
        multicast-latest-run {
            statistics {
                sent-packets 0
                received-packets 0
            }
        }
    }

The following example shows the delete operation usage to clean up.

Delete operation usage to clean up

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <action xmlns="urn:ietf:params:xml:ns:yang:1">
    <admin xmlns="urn:nokia.com:sros:ns:yang:sr:oper-admin">
        <system>
            <management-interface>
                <operations>
                    <delete-operation>
                       <delete-id>111</delete-id>
                     </delete-operation>
                </operations>
            </management-interface>
        </system>
   </admin>
  </action>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
       xmlns:nokiaoper="urn:nokia.com:sros:ns:yang:sr:oper-admin">
    <nokiaoper:operation-id>112</nokiaoper:operation-id>
    <nokiaoper:start-time>2021-06-16T14:17:38.5Z</nokiaoper:start-time>
    <nokiaoper:status>completed</nokiaoper:status>
    <nokiaoper:end-time>2021-06-16T14:17:38.6Z</nokiaoper:end-time>
</rpc-reply>
]]>]]>