Cisco NCS 1001 User manual

Data Models Configuration Guide for Cisco NCS 1001
First Published: 2017-07-14
Last Modified: 2018-03-29
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: [phone]
800 553-NETS (6387)
Fax: [phone]

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright ©1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https:/
/www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1721R)
©2018 Cisco Systems, Inc. All rights reserved.

CONTENTS
CHAPTER 1 Data models 1
Data Models - Programmatic and Standards-based Configuration 1
YANG model 2
Components of a YANG Model 2
Structure of YANG models 3
Data Types 4
Supported YANG models 4
Introduction to NETCONF 4
Subtree Filtering 6
Subtree Filter Components 6
gRPC 7
CHAPTER 2 Using Data models 9
Using Data models 9
Enabling Netconf 10
Enabling gRPC 11
CHAPTER 3 Configuring NCS 1001 Using Data Models 13
Supported YANG Models in NCS 1001 13
Configure Amplifier Module 14
Remove Amplifier Configuration 14
Configure Protection Switching Module 15
Remove Protection Switching Module Configuration 16
Configure OTS Controller 17
Display Parameters of OTS Controllers 23
Display Parameters of OTS OCH Controllers 24
View PM Parameters for OTS Controllers 25
Data Models Configuration Guide for Cisco NCS 1001
iii

CHAPTER 4 Configuring NCS 1001 Using OpenConfig Data Model 27
Openconfig Optical Amplifier Model 28
Openconfig Protection Switching Model 29
Openconfig Channel Monitoring Model 30
Data Models Configuration Guide for Cisco NCS 1001
iv
Contents

CHAPTER 1
Data models
Data modeling is standard based approach to model configuration and operational data in networking devices.
Using data models, customers can automate and simplify network wide visibility and configuration.
•Data Models - Programmatic and Standards-based Configuration , page 1
•YANG model, page 2
•Supported YANG models, page 4
•Introduction to NETCONF , page 4
•gRPC, page 7
DataModels-ProgrammaticandStandards-basedConfiguration
Cisco IOS XR software supports the automation of configuration of multiple routers across the network using
Data models. Configuring routers using data models overcomes drawbacks posed by traditional router
management techniques.
CLIs are widely used for configuring a router and for obtaining router statistics. Other actions on the router,
such as, switch-over, reload, process restart are also CLI-based. Although, CLIs are heavily used, they have
many restrictions.
Customer needs are fast evolving. Typically, a network center is a heterogenous mix of various devices at
multiple layers of the network. Bulk and automatic configurations need to be accomplished. CLI scraping is
not flexible and optimal. Re-writing scripts many times, even for small configuration changes is cumbersome.
Bulk configuration changes through CLIs are error-prone and may cause system issues. The solution lies in
using data models - a programmatic and standards-based way of writing configurations to any network device,
replacing the process of manual configuration. Data models are written in a standard, industry-defined language.
Although configurations using CLIs are easier (more human-friendly), automating the configuration using
data models results in scalability.
Cisco IOS XR supports the YANG data modeling language. YANG can be used with Network Configuration
Protocol (NETCONF) to provide the desired solution of automated and programmable network operations.
Data Models Configuration Guide for Cisco NCS 1001
1

YANG model
YANG is a data modeling language used to describe configuration and operational data, remote procedure
calls and notifications for network devices. The salient features of YANG are:
•Human-readable format, easy to learn and represent
•Supports definition of operations
•Reusable types and groupings
•Data modularity through modules and submodules
•Supports the definition of operations (RPCs)
•Well-defined versioning rules
•Extensibility through augmentation
For more details of YANG, refer RFC 6020 and 6087.
NETCONF and gRPC (Google Remote Procedute Call) provide a mechanism to exchange configuration and
operational data between a client application and a router and the YANG models define a valid structure for
the data (that is being exchanged).
Encoding/ DecodingTransportProtocol
XMLSSHNETCONF
XML, JSONHTTP/2gRPC
Each feature has a defined YANG model. Cisco-specific YANG models are referred to as synthesized models.
Some of the standard bodies, such as IETF , IEEE and Open Config, are working on providing an industry-wide
standard YANG models that are referred to as common models.
Components of a YANG Model
A module defines a single data model. However, a module can reference definitions in other modules and
submodules by using the import statement to import external modules or the include statement to include
one or more submodules. A module can provide augmentations to another module by using the augment
statement to define the placement of the new nodes in the data model hierarchy and the when statement to
define the conditions under which the new nodes are valid. Prefix is used when referencing definitions in the
imported module.
YANG models are available for configuring a feature and to get operational state (similar to show commands)
This is the configuration YANG model for AAA (denoted by - cfg)
(snippet)
module Cisco-IOS-XR-aaa-locald-cfg {
/*** NAMESPACE / PREFIX DEFINITION ***/
namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-cfg";
Data Models Configuration Guide for Cisco NCS 1001
2
Data models
YANG model

prefix "aaa-locald-cfg";
/*** LINKAGE (IMPORTS / INCLUDES) ***/
import Cisco-IOS-XR-types { prefix "xr"; }
import Cisco-IOS-XR-aaa-lib-cfg { prefix "a1"; }
/*** META INFORMATION ***/
organization "Cisco Systems, Inc.";
.........................
......................... (truncated)
This is the operational YANG model for AAA (denoted by -oper)
(snippet)
module Cisco-IOS-XR-aaa-locald-oper {
/*** NAMESPACE / PREFIX DEFINITION ***/
namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-oper";
prefix "aaa-locald-oper";
/*** LINKAGE (IMPORTS / INCLUDES) ***/
import Cisco-IOS-XR-types { prefix "xr"; }
include Cisco-IOS-XR-aaa-locald-oper-sub1 {
revision-date 2015-01-07;
}
/*** META INFORMATION ***/
organization "Cisco Systems, Inc.";
........................
........................ (truncated)
A module may include any number of sub-modules, but each sub-module may belong to only one module.
The names of all standard modules and sub-modules must be unique.
Note
Structure of YANG models
YANG data models can be represented in a hierarchical, tree-based structure with nodes, which makes them
more easily understandable. YANG defines four nodes types. Each node has a name, and depending on the
node type, the node might either define a value or contain a set of child nodes. The nodes types (for data
modeling) are:
•leaf node - contains a single value of a specific type
•list node - contains a sequence of list entries, each of which is uniquely identified by one or more key
leafs
•leaf-list node - contains a sequence of leaf nodes
•container node - contains a grouping of related nodes containing only child nodes, which can be any of
the four node types
Data Models Configuration Guide for Cisco NCS 1001
3
Data models
Structure of YANG models

Data Types
YANG defines data types for leaf values. These data types help the user in understanding the relevant input
for a leaf.
DescriptionName
Any binary databinary
A set of bits or flagsbits
"true" or "false"boolean
64-bit signed decimal numberdecimal64
A leaf that does not have any valueempty
Enumerated stringsenumeration
A reference to an abstract identityidentityref
References a data tree nodeinstance-identifier
8-bit, 16-bit, 32-bit, 64-bit signed integersint (integer-defined values)
A reference to a leaf instanceleafref
8-bit, 16-bit, 32-bit, 64-bit unsigned intergersuint
Human-readable stringstring
Choice of member typesunion
Supported YANG models
The complete list of the supported IOSXR YANG models are:
https://github.com/YangModels/yang/tree/master/vendor/cisco/xr
Introduction to NETCONF
NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. It
uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the
protocol messages. NETCONF uses a simple RPC-based (Remote Procedure Call) mechanism to facilitate
communication between a client and a server. The client can be a script or application typically running as
part of a network manager. The server is typically a network device (router).
For more NETCONF details, refer RFC 6241.
Data Models Configuration Guide for Cisco NCS 1001
4
Data models
Data Types

NETCONF sessions
A NETCONF session is the logical connection between a network administrator or network configuration
application and a network device. Global configuration attributes can be changed during any authorized
session, and the effects are visible in all sessions. NETCONF is connection-oriented, with SSH as the underlying
transport. NETCONF sessions are established with a hello message, where features and capabilities are
announced. Sessions are terminated using the close or kill messages.
NETCONF Layers
Figure 1: NETCONF Layers
NETCONF can be partitioned into four layers:
•Content layer - includes configuration and notification data
•Operations layer - defines a set of base protocol operations invoked as RPC methods with XML-encoded
parameters
•Messages layer - provides a simple, transport-independent framing mechanism for encoding RPCs and
notifications
•Secure Transport layer- provides a communication path between the client and server
NETCONF Operations
NETCONF defines the existence of one or more configuration datastores and allows configuration operations
on them. A configuration datastore is defined as the complete set of configuration data that is required to get
a device from its initial default state into a desired operational state. The configuration datastore does not
include state data or executive commands.
IOS XR NETCONF supports the following operations:
•<get-config>—Retrieves all or part of a specified configuration from a named data store
•<get>—Retrieves running configuration and device state information
•<edit-config>—Loads all or part of a specified configuration to the specified target configuration
•<get-schema>—Retrieves the required schema from the router
NETCONF Operations: Example
Data Models Configuration Guide for Cisco NCS 1001
5
Data models
Introduction to NETCONF

This example shows how a NETCONF <get-config> request works.
Figure 2: <get-config> request
The send message request is to get the current configuration of CDP running on the router. The return message
includes the current CDP configuration.
NETCONF reply (server to client)NETCONF request (client to server)
<?xml version="1.0"?>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
<data>
<cdp
xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-cdp-cfg">
<timer>10</timer>
<enable>true</enable>
<log-adjacency></log-adjacency>
<hold-time>200</hold-time>
<advertise-v1-only></advertise-v1-only>
</cdp>
</data>
</rpc-reply>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
<get-config>
<source><running/></source>
<filter>
<cdp
xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-cdp-cfg"/>
</filter>
</get-config>
</rpc>
The RPC element is used to enclose a NETCONF request sent from the client to the server. The <rpc> element
has a mandatory attribute message-id, which is a string chosen by the sender of the RPC that will commonly
encode a monotonically increasing integer. The receiver of the RPC does not decode or interpret this string
but simply saves it to be used as a message-id attribute in any resulting <rpc-reply> message. The sender
MUST ensure that the message-id value is normalized. The RPC reply message contains the same message-id
when the client receives information from the server.
Subtree Filtering
XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include
in the <rpc-reply> for a <get> or <get-config> operation.
Subtree Filter Components
A subtree filter is comprised of XML elements and their XML attributes. Elements that can be present in a
subtree filter are:
•Namespace selection - A namespace is considered to match (for filter purposes) if the XML namespace
associated with a particular node within the filter element is the same as in the underlying data model.
Data Models Configuration Guide for Cisco NCS 1001
6
Data models
Subtree Filtering

A namespace selection cannot be used by itself; at least one element must be specified in the filter if
any elements are to be included in the filter output.
Example:
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>
•Attribute match expressions -Filtering is done by matching a specified attribute value. This filtering with
the Match attribute can be specified only in Table classes.
Example:
ifName is the attribute match expression
<filter type="subtree">
<t:top xmlns:t="http://example.com/schema/1.2/config">
<t:interfaces>
<t:interface t:ifName="eth0"/>
</t:interfaces>
</t:top>
</filter>
•Containment Nodes - Filtering is done by specifying nodes (classes) that have child nodes (classes).
This filtering is by specifying container classes.
Example: top is a containment node
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
•Selection Nodes - Filtering is done by specifying leaf nodes. This filtering specifies leaf classes.
Example: users is a selection node (in the containment node - top)
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users/>
</top>
</filter>
•Content Match Nodes - Filtering is done by exactly matching the content of a leaf node. This filtering
is done by specifying naming the class value for table classes.
Example: name is the content match node (in the containment node - top and the selection
node - user)
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<users>
<user>
<name>fred</name>
</user>
</users>
</top>
</filter>
gRPC
gRPC is a language-neutral, open source, RPC (Remote Procedute Call) system developed by Google. By
default, it uses protocol buffers as the binary serialization protocol. It can be used with other serialization
protocols as well such as JSON, XML etc. The user needs to define the structure by defining protocol buffer
message types in.proto files. Each protocol buffer message is a small logical record of information, containing
a series of name-value pairs.
gRPC encodes requests and responses in binary. Although Protobufs was the only format supported in the
initial release, gRPC is extensible to other content types. The Protobuf binary data object in gRPC is transported
Data Models Configuration Guide for Cisco NCS 1001
7
Data models
gRPC

using HTTP/2 (RFC 7540). HTTP/2 is a replacement for HTTP that has been optimized for high performance.
HTTP/2 provides many powerful capabilities including bidirectional streaming, flow control, header
compression and multi-plexing. gRPC builds on those features, adding libraries for application-layer
flow-control, load-balancing and call-cancellation.
gRPC supports distributed applications and services between a client and server. gRPC provides the
infrastructure to build a device management service to exchange configuration and operational data between
a client and a server in which the structure of the data is defined by YANG models.
Cisco gRPC IDL
The protocol buffers interface definition language (IDL) is used to define service methods, and define parameters
and return types as protocol buffer message types.
gRPC requests can be encoded and sent across to the router using JSON. gRPC IDL also supports the exchange
of CLI.
For gRPC transport, gRPC IDL is defined in .proto format. Clients can invoke the RPC calls defined in the
IDL to program XR. The supported operations are - Get, Merge, Delete, Replace. The gRPC JSON arguments
are defined in the IDL.
syntax = "proto3";
package IOSXRExtensibleManagabilityService;
service gRPCConfigOper {
rpc GetConfig(ConfigGetArgs) returns(stream ConfigGetReply) {};
rpc MergeConfig(ConfigArgs) returns(ConfigReply) {};
rpc DeleteConfig(ConfigArgs) returns(ConfigReply) {};
rpc ReplaceConfig(ConfigArgs) returns(ConfigReply) {};
rpc CliConfig(CliConfigArgs) returns(CliConfigReply) {};
}
gRPC Operations
•oper get-config—Retrieves a configuration
•oper merge-config—Appends to an existing configuration
•oper delete-config—Deletes a configuration
•oper replace-config—Modifies a part of an existing configuration
•oper get-oper—Gets operational data using JSON
•oper cli-config—Performs a configuration
•oper showcmdtextoutput
Data Models Configuration Guide for Cisco NCS 1001
8
Data models
gRPC

CHAPTER 2
Using Data models
This section explains the required configurations and procedures for using data models.
•Using Data models , page 9
•Enabling Netconf, page 10
•Enabling gRPC, page 11
Using Data models
Figure 3: Workflow for using Data models
The above illustration gives a quick snap shot of how YANG can be used with Netconf in configuring a
network device using a client application.
The tasks that help the user to implement Data model configuration are listed here.
1Load the software image ; the YANG models are a part of the software image. Alternatively, the YANG
models can also be downloaded from:
https://github.com/YangModels/yang/tree/master/vendor/cisco/xr
Users can also query using NETCONF to get the list of models.
<?xml version="1.0" encoding="utf-8"?>
<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas/>
</netconf-state>
</filter>
</get>
</rpc>
Data Models Configuration Guide for Cisco NCS 1001
9

2Communication between the router and the application happens by SSH on Netconf. Enable Netconf on
the router on a suitable port.
3From the client application, connect to the router using Netconf on SSH. Run Netconf operations to make
configuration changes or get operational data.
Figure 4: Lane Diagram to show the router and client application operations
Enabling Netconf
This task enables Netconf over SSH.
Data Models Configuration Guide for Cisco NCS 1001
10
Using Data models
Enabling Netconf

Before You Begin
•Install the required packages (k9sec and mgbl)
•Generate relevant crypto keys
Step 1 netconf-yang agent ssh
Enables the Netconf agent process.
Step 2 ssh server netconf
Enables Netconf.
Step 3 ssh server v2
Enables SSH on the device and enables Netconf on port 22 if the Netconf agent process is enabled.
What to Do Next
The netconf-yang agent session command enables the user to set session parameters.
netconf-yang agent session {limit value | absolute-timeout value | idle-timeout value}
where,
•limit value- sets the maximum count for concurrent netconf-yang sessions. Range is 1 to 1024. The
default value is 50.
•absolute-timeout value- sets the absolute session lifetime. Range is 1 to 1440 (in minutes).
•idle-timeout value- sets the idle session lifetime. Range is 1 to 1440 (in minutes).
Enabling gRPC
Use the following procedure to enable gRPC over HTTPS/2. gRPC supports both, the IPv4 and IPv6 address
families (default is IPv4).
Step 1 Install the GO client. For more details on installing the GO client, see https://golang.org/doc/install.
Step 2 Configure the gRPC port, using the grpc port command.
RP/0/RP0/CPU0:ios(config)#grpc
RP/0/RP0/CPU0:ios(config)#port 57400
RP/0/RP0/CPU0:ios(config)#tls
RP/0/RP0/CPU0:ios(config)#commit
Port can range from 57344 to 57999. If a port is unavailable, an error is displayed.
Data Models Configuration Guide for Cisco NCS 1001
11
Using Data models
Enabling gRPC

Data Models Configuration Guide for Cisco NCS 1001
12
Using Data models
Enabling gRPC

CHAPTER 3
Configuring NCS 1001 Using Data Models
This section includes examples for configuring NCS 1001 using Data models.
•Supported YANG Models in NCS 1001, page 13
•Configure Amplifier Module, page 14
•Remove Amplifier Configuration, page 14
•Configure Protection Switching Module, page 15
•Remove Protection Switching Module Configuration, page 16
•Configure OTS Controller, page 17
•Display Parameters of OTS Controllers, page 23
•Display Parameters of OTS OCH Controllers, page 24
•View PM Parameters for OTS Controllers, page 25
Supported YANG Models in NCS 1001
The supported configuration and operational YANG models for NCS 1001 are listed below.
Oper. yangCfg. yang
Cisco-IOS-XR-controller-optics-oper.yangCisco-IOS-XR-ncs1001-ots-cfg.yang
Cisco-IOS-XR-pmengine-oper.yangCisco-IOS-XR-ifmgr-cfg.yang
Cisco-IOS-XR-plat-chas-invmgr-oper.yangCisco-IOS-XR-controller-optics-cfg.yang
Cisco-IOS-XR-alarmgr-server-oper.yangCisco-IOS-XR-pmengine-cfg.yang
Data Models Configuration Guide for Cisco NCS 1001
13

Configure Amplifier Module
Use the Cisco-IOS-XR-ncs1001-ots-cfg.yang YANG model to configure the grid mode parameter of the amplifier module
as 100GHz or 50GHz.
ExampleParameter
<?xml version="1.0"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<hardware-module xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ncs1001-ots-cfg">
<node>
<location>0_RP0_CPU0</location>
<slot>
<slot-id>0x2</slot-id>
<amplifier>
<grid-mode >100g-hz</grid-mode>
</amplifier>
</slot>
</node>
</hardware-module>
</config>
</edit-config>
</rpc>
grid-mode
Remove Amplifier Configuration
Use the Cisco-IOS-XR-ncs1001-ots-cfg.yang YANG model to remove the amplifier configuration.
Data Models Configuration Guide for Cisco NCS 1001
14
Configuring NCS 1001 Using Data Models
Configure Amplifier Module

ExampleParameter
<?xml version="1.0"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<hardware-module xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ncs1001-ots-cfg">
<node>
<location>0_RP0_CPU0</location>
<slot>
<slot-id>0x2</slot-id>
<amplifier>
<grid-mode xc:operation = "delete">100g-hz</grid-mode>
</amplifier>
</slot>
</node>
</hardware-module>
</config>
</edit-config>
</rpc>
grid-mode
Configure Protection Switching Module
Use the Cisco-IOS-XR-ncs1001-ots-cfg.yang YANG model to configure the protection switching module.
Data Models Configuration Guide for Cisco NCS 1001
15
Configuring NCS 1001 Using Data Models
Configure Protection Switching Module

ExampleParameter
<?xml version="1.0"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<hardware-module xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ncs1001-ots-cfg">
<node>
<location>0_RP0_CPU0</location>
<slot>
<slot-id>0x3</slot-id>
<psm>
<lockout-from>protected</lockout-from>
</psm>
</slot>
</node>
</hardware-module>
</config>
</edit-config>
</rpc>
lockout-from
<?xml version="1.0"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<hardware-module xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ncs1001-ots-cfg">
<node>
<location>0_RP0_CPU0</location>
<slot>
<slot-id>0x3</slot-id>
<psm>
<manual-switch-to>working</manual-switch-to>
</psm>
</slot>
</node>
</hardware-module>
</config>
</edit-config>
</rpc>
manual-switch-to
Remove Protection Switching Module Configuration
Use the Cisco-IOS-XR-ncs1001-ots-cfg.yang YANG model to remove the protection switching module configuration.
Data Models Configuration Guide for Cisco NCS 1001
16
Configuring NCS 1001 Using Data Models
Remove Protection Switching Module Configuration