3. Model-Driven Management Interfaces

SR OS supports two classes of management interfaces:

Classic management interfaces
1. SNMP
2. the classic CLI
Model-driven management interfaces
1. the MD-CLI (model-driven CLI)
2. NETCONF
3. 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. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide for information about classic CLI commands.

The MD-CLI is a model-driven CLI introduced in SR OS Release 16.0.R1. Refer to 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 for information about MD-CLI commands.

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 String 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.
1. In classic configuration mode, the default handling is similar to RFC 6243 “trim” mode. Configuration values are not reported if they are equal to the default value, even if the user explicitly configured the value.
2. 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.
3. 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. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information about RFC behavior.

3.1. Management Interface Configuration Modes

SR OS routers can be in different management interface configuration modes, which affects the management interfaces that can be used to configure the router. The following interfaces are available for configuration on SR OS:

classic (default) — configuration via the classic CLI and SNMP, no model-driven interfaces are supported
model-driven — configuration via model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via the classic CLI and SNMP
mixed — configuration via the classic CLI and model-driven interfaces: the MD-CLI, NETCONF, and gRPC/gNMI, read-only access via SNMP

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

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 21).

Table 21: 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 1			✓
	Explicit non-deletable SPC objects 2			✓
	Configuration changes accepted immediately after a CPM high-availability switchover 3	✓		✓
	Named route policy entries			✓
	gRPC MD-CLI service for the NISH client			✓
	Remote management using the NISH manager			✓

Notes:

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.

3.2. 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) take 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

3.2.1. 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 classic CLI clear, show, monitor, and tools branches of the CLI 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-based Operations for more information.

3.2.2. OpenConfig YANG Data Models

OpenConfig presents a vendor-neutral set of YANG models. OpenConfig YANG model elements are mapped to application-specific SR OS configuration and state.

3.2.2.1. Basic Configuration

OpenConfig YANG models are available in model-driven interfaces, including the MD-CLI, gNMI, and NETCONF when enabled with the configure system management-interface yang-modules openconfig-modules command. Access to the OpenConfig models is different depending on the model-driven interface.

MD-CLI
1. OpenConfig configuration statements are located in the configure openconfig context.
2. OpenConfig state information is located in the state openconfig context.
3. 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.
4. The operator must set openconfig-modules to true and perform the validate or commit action again. Assuming the configuration is complete and there are no other errors, the transaction succeeds.
5. The system checks openconfig-modules to determine whether OpenConfig state elements can be accessed.
gNMI and NETCONF
1. 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.
2. 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
1. 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.
2. 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.

3.2.2.2. Shared Model Management Support

3.2.2.2.1. Introduction

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

3.2.2.2.2. Merging Configuration Statements

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

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

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

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

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

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

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 pushed to the application. These partial configurations remain in the OpenConfig configuration tree as they are syntactically correct, however, without an application mapping event, they remain outside of the operating configuration. When a partial configuration is stored in the OpenConfig configuration tree, it does not show as an active element under the SR OS specific application, that is, via show commands or in the /state tree.

3.2.2.2.3. Application Support

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

sros-ext:shared-model-management {

sros-ext:openconfig false;

}

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

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

[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. For example, the commands in the configure policy-options policy-statement context display the following:

*[ex:/configure policy-options policy-statement "policy-1"]

A:admin@node-2# entry ?

[entry-id] <number>

Entry ID of 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.

3.2.2.2.4. Validating and Committing

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

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

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.

configure port 1/1/4 ethernet access - OpenConfig and Nokia condition mismatch - failed condition

3.2.2.2.5. Error Reporting

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. A sample error message is shown below.

- <error message>

3.2.2.2.6. Using the info Command

Several variations of the info command are available in order to collect the required operational data required to view the configuration. These include:

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

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

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

info inheritance - Include configuration inherited from configuration groups.

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

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

3.2.2.2.7. Deviating and Augmenting

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

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

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

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

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

3.3. 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 show system management-interface datastore-locks 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.

3.3.1. NMDA Support

SR OS supports the Network Management Datastore Architecture (NMDA) for the intended datastore. When nmda-support 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, and 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, and ietf-origin.

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

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.
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.
The following are examples of deletable SPC objects (in classic CLI format).

configure system security profile default

configure system security profile default entry 10-100

configure system security profile administrative

configure system security profile administrative entry 10-112

configure system security user "admin"

configure system security user console member "default"

configure system security ssh client-cipher-list protocol-version 1 cipher 200-210

configure system security ssh client-cipher-list protocol-version 2 cipher 190-235

configure system security ssh server-cipher-list protocol-version 1 cipher 200-205

configure system security ssh server-cipher-list protocol-version 2 cipher 190-235

configure log filter 1001

configure log filter 1001 entry 10

configure log log-id 99 & 100

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.
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 configure service customer 1 name “1” and configure system security cpu-protection policy 254.
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 cannot be deleted in the classic CLI. A deletion attempt returns an error.
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.
The following are examples of non-deletable SPC objects (in classic CLI format).

configure system security cpu-protection policy 254 & 255

configure system security user-template {tacplus_default|radius_default}

configure system security snmp view iso …

configure system security snmp view li-view …

configure system security snmp view mgmt-view …

configure system security snmp view vprn-view …

configure system security snmp view no-security-view …

configure system security snmp access group xyz (a set of access groups)

configure log event-control …

configure filter log 101

configure qos … various default policies cannot be deleted

configure card <x>

configure router "Base"

configure router "management"

configure router network-domains network-domain “default”

configure oam-pm bin-group 1

configure call-trace trace-profile “default”

configure eth-cfm default-domain bridge-identifier <x>

configure service customer 1 name "1"

3.5. Prerequisites for Using Model-Driven Management Interfaces

Note:

Before configuration editing is permitted in model-driven interfaces, the management interface configuration-mode must be set to model-driven or mixed after the prerequisites described in this section are completed.

3.5.1. 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, the configure service pw-template 23 egress filter ip 37 can be configured even if ip-filter 37 does not exist in the configuration.

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 (configure service vprn, vpls, epipe, and so on)
configure mirror mirror-dest
configure service pw-templates
configure service customer
configure filter ip-filter, ipv6-filter, and mac-filter
configure qos network, sap-ingress, and sap-egress
configure eth-cfm domain and 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 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 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 configuration example:

configure service pw-template 23 egress filter ip 37

the configuration can be changed to:

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, it may be desirable 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 default-domain bridge-identifier

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

3.5.2. String 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

3.5.3. 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 prior to 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 the following elements are assigned names prior to an upgrade to Release 15.1 or later.

all services (configure service vprn, vpls, epipe, and so on)
configure mirror mirror-dest
configure service pw-templates
configure service customer
configure filter ip-filter, ipv6-filter, and mac-filter
configure qos network, sap-ingress, and sap-egress
configure eth-cfm domain and association

3.6. 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, refer to section “Unsupported Configuration in MD Interfaces” in the SR OS 21.x.Rx Software Release Notes, part number 3HE 17177 000x TQZZA.
Update the system configuration to meet the prerequisites described in Prerequisites for Using Model-Driven Management Interfaces.

Perform a mode change configuration check as follows.

Use the tools perform system management-interface configuration-mode check 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.

Note:

The command does not check if the configuration contains commands that are unsupported in model-driven interfaces. For more information, refer to section “Unsupported Configuration in MD Interfaces” in the SR OS 21.x.Rx Software Release Notes, part number 3HE 17177 000x TQZZA.

The following example shows several incompatible configuration commands.

A:node-2# tools perform system management-interface configuration-mode model-

driven check

===============================================================================

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.

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.
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.
1. In mixed mode, issue admin save from the classic CLI.
2. In model-driven mode, issue admin save from the MD-CLI.

3.6.1. 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. Table 22 summarizes the CLI engines for the management interface configuration modes.

Table 22: 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 parameter is a user-ordered list, and the first engine from that list is configured as the preferred CLI engine. Leaving the cli-engine parameter unconfigured (or deleting the cli-engine values) maintains or reverts to the dynamic default. Table 23 summarizes the supported actions for the MD-CLI cli-engine configuration.

Note:

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

Table 23: 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

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

The user can display the commit history with the MD-CLI show system management-interface commit-history command and also in the state model, in state system management-interface configuration-region <region-name> commit-history. The saved configuration file header also displays the commit history from the last configuration save.

An optional commit comment may be entered using the MD-CLI commit comment command or the NETCONF <commit> RPC.

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.

[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

Committed 2021-08-16T15:25:51.5-05:00 by admin (MD-CLI) from 10.1.145.205

Comment "Third commit with the MD-CLI."

Location "cf3:\config.cfg"

Committed 2021-08-16T15:25:45.1-05:00 by admin (MD-CLI) from 10.1.145.205

Comment "Second commit with the MD-CLI."

Location "cf3:\config.cfg.1"

Committed 2021-08-16T08:59:34.8-05:00 by system (MD-CLI) from Console

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:

<comment>Fourth commit with NETCONF.</comment>

</commit>

</rpc>

]]>]]>

The following example displays the commit history after the preceding activity:

[/]

A:admin@node-2# show system management-interface commit-history

===============================================================================

Commit History

===============================================================================

Total Commits : 4

Committed 2021-08-16T15:27:42.9-05:00 by admin (NETCONF) from 10.1.236.68

Comment "Fourth commit with NETCONF."

Location "cf3:\config.cfg"

Committed 2021-08-16T15:25:51.5-05:00 by admin (MD-CLI) from 10.1.145.205

Comment "Third commit with the MD-CLI."

Location "cf3:\config.cfg.1"

Committed 2021-08-16T15:25:45.1-05:00 by admin (MD-CLI) from 10.1.145.205

Comment "Second commit with the MD-CLI."

Location "cf3:\config.cfg.2"

Committed 2021-08-16T08:59:34.8-05:00 by system (MD-CLI) from Console

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.
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.
The MD-CLI environment time-format and environment time-display parameters can be used to change the time formats displayed in the output of the following commands:
1. the Generated and Finished lines in admin show configuration
2. show system management-interface commit-history
3. info state system management-interface <region-name> commit-history
The MD-CLI environment parameters 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) time zone.

3.8. YANG-based 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-based 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. Configure the state system management-interface operations operation operation-id command to use the operation ID as an index into the global operations table to examine the details of an operation, including the following information:

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

The following is a sample output that shows the contents of the global operations table while a file remove-directory command is in progress.

[/]

A:admin@router-a23# 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 using the admin system management-interface operations delete-operation command. 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.

3.8.1. Asynchronous Versus Synchronous Operations

SR OS supports the following basic response modes for YANG-based 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 do the following:

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.

Figure 12 shows a typical flow for an asynchronous operation.

Figure 12: Asynchronous Operation Flow

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.

3.8.1.1. Examples of Operations in MD-CLI

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

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

[/]

A:admin@bkvm30# admin clear security password-history all

[/]

A:admin@bkvm30#

The following example shows an operation that returns result data.

[/]

A:admin@bkvm30# 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

[/]

A:admin@bkvm30#

The following example shows another operation that returns result data.

[/]

A:admin@bkvm30# 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%

[/]

3.8.1.2. Examples of Synchronous Operations in NETCONF

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

Request:

<?xml version="1.0" encoding="UTF-8"?>

<clear>

<password-history>

<all/>

</password-history>

</security>

</clear>

</admin>

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

Request:

<?xml version="1.0" encoding="UTF-8"?>

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

]]>]]>

3.8.1.3. Examples of Asynchronous Operations in NETCONF

The following example shows an asynchronous operation in NETCONF.

Request:

<?xml version="1.0" encoding="UTF-8"?>

<global-operations xmlns="urn:nokia.com:sros:ns:yang:sr:oper-global">

<oam>

<eth-cfm>

<md-admin-name>MyDomain</md-admin-name>

<ma-admin-name>MyAssociation</ma-admin-name>

<mep-id>1</mep-id>

<send-count>5</send-count>

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

[/]

A:admin@bkvm30# 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

}

The following example shows log event output when the operation is completed.

[/]

A:admin@bkvm30# show log log-id 99

===============================================================================

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 a sample of the results available in the state branch.

[/]

A:admin@bkvm30# 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.

<?xml version="1.0" encoding="UTF-8"?>

<management-interface>

<delete-operation>

<delete-id>111</delete-id>

</delete-operation>

</operations>

</management-interface>

</system>

</admin>

</action>

</rpc>

]]>]]>

<rpc-reply message-id="102" 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>

]]>]]>