Cisco NSO Transport SDN Function Pack Bundle User Guide Version 1 0 0 PDF

Cisco NSO Transport SDN Function Pack
Bundle
User Guide
Version 1.0.0
May 2020
Cisco NSO Transport SDN Function Pack Bundle - User Guide
Total page: 186
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: 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)
Copyright
© 2020 Cisco Systems, Inc. All rights reserved.
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.
Contents Page 3
1 Contents
1 Contents ....................................................................................... iii
2 Preface ........................................................................................... 6
3 Getting Started............................................................................... 7
3.1 Cisco Network Services Orchestrator - Overview ................................. 7
3.2 Cisco NSO Transport SDN Function Pack Bundle - Overview ............... 9
3.3 T-SDN Function Packs Bundle Architecture ........................................ 10
4 SR-TE Core Function Pack ............................................................. 13
4.1 SR-TE ODN........................................................................................... 13
4.2 SR-Policy ............................................................................................. 13
5 Example Function Packs ............................................................... 15
5.1 SR-Settings .......................................................................................... 15
5.2 SR-PCE ................................................................................................. 15
5.3 L2VPN.................................................................................................. 15
5.4 L3VPN.................................................................................................. 16
6 Configuration ............................................................................... 17
6.1 Creating SR-TE Services ...................................................................... 17
6.1.1 Creating SR-ODN ................................................................. 17
6.1.2 Creating SR-Policies ............................................................. 19
6.2 Creating SR-Settings Services ............................................................. 20
6.2.1 Allocating Resources by Using Resource Pools ................... 22
6.3 Creating SR-PCE Services .................................................................... 30
6.4 Creating Flat L2VPN Services with the L2VPN Example Function Pack
............................................................................................................ 32
6.4.1 Creating Flat L2VPN-P2P ..................................................... 32
6.4.2 Creating Flat L2VPN – EVPN ................................................ 34
6.5 Creating Flat L3VPN Services with the L3VPN Example Function Pack
............................................................................................................ 39
6.5.1 Creating Flat L3VPN ............................................................. 39
6.5.2 Creating L3VPN SR-TE ODN ................................................. 41
6.5.3 Creating BVI L3VPN ............................................................. 44
7 Working with Action Commands .................................................. 46
7.1 Service Cleanup Actions...................................................................... 46
7.1.1 SR-ODN ................................................................................ 47
7.1.2 SR-Policy .............................................................................. 48
7.1.3 SR-Settings........................................................................... 48
7.1.4 SR-PCE ................................................................................. 49
7.1.5 L2VPN Example Services ..................................................... 50
7.2 Auto Cleanup ...................................................................................... 51
7.3 get-modifications Action .................................................................... 53
7.3.1 SR-ODN ................................................................................ 53
7.3.2 SR-Policy .............................................................................. 55
7.3.3 SR-Settings........................................................................... 55
Rev. 1.0.0 Cisco NSO Transport SDN Function Pack Bundle User Guide
Contents Page 4
7.3.4 SR-PCE ................................................................................. 58

7.4 Service Redeploy Action ..................................................................... 71
7.4.1 SR-ODN ................................................................................ 71
7.4.2 SR-Policy .............................................................................. 72
7.4.3 SR-Settings........................................................................... 73
7.4.4 SR-PCE ................................................................................. 74
8 Using Custom-Templates .............................................................. 78
8.1 Turning Custom-Templates On/Off .................................................... 78
9 Supporting Multi-Vendor Services ................................................ 79
10 Deleting Services .......................................................................... 80
11 Notifications ................................................................................ 81
11.1 SR-ODN Notifications .......................................................................... 81
11.2 SR-Policies Notifications ..................................................................... 83
11.2.1 SR-TE Policy with Static Explicit Route Object..................... 83
11.3 SR-Settings Notifications .................................................................... 85
11.3.1 SR-Settings Notifications ..................................................... 85
11.3.2 SR Flex Algo Notifications .................................................... 87
11.4 SR-PCE Notifications ........................................................................... 88
11.5 Flat L2VPN Example Notifications ...................................................... 90
11.5.1 Flat L2VPN P2P Notifications ............................................... 90
11.5.2 Flat L2VPN VPWS Notifications ........................................... 92
11.5.3 L2VPN SR-TE – Preferred Path Notifications ....................... 94
11.5.4 L2VPN SR-TE – ODN ............................................................. 96
11.6 Flat L3VPN Example Notifications ...................................................... 98
11.6.1 Flat L3VPN Notifications ...................................................... 98
11.6.2 Flat -L3VPN SR TE Color ..................................................... 100
12 Handling Zombies ....................................................................... 102
13 Appendix A: Package Categories and Packages ........................... 104
14 Appendix B - Yang Models .......................................................... 105
14.1 Cisco SR-TE-CFP-ODN........................................................................ 105
14.2 Cisco SR-TE-CFP-POLICY .................................................................... 106
14.3 SR-Setting Function Pack .................................................................. 108
14.4 SR-PCE Function Pack ....................................................................... 112
14.5 Flat-L2VPN Function Pack ................................................................. 114
14.6 Flat-L3VPN Function Pack ................................................................. 118
15 Appendix C - Payloads and XML Outputs .................................... 120
15.1 Custom-Template Payloads .............................................................. 120
15.1.1 SR-ODN .............................................................................. 120
15.1.2 SR-Policy ............................................................................ 121
15.1.3 SR-Settings......................................................................... 121
15.1.4 SR-PCE ............................................................................... 123
Contents Page 5
15.1.5 L2VPN Example Services ................................................... 124

15.2 XML Output – get-modifications Action ........................................... 127
15.2.1 SR-ODN .............................................................................. 127
15.2.2 SR-Policy ............................................................................ 129
15.2.3 SR-Settings......................................................................... 130
15.2.4 SR-PCE ............................................................................... 133
16 Appendix D: Use Cases ............................................................... 147
16.1 Use Cases .......................................................................................... 150
16.1.1 Use Case 1: Instantiating Example L3VPN over SR-TE for
Color 30 ............................................................................. 150
16.1.2 Use Case 2: Flat- L3VPN Route Policy for Color 20 by Using
SR ODN with Flex Algo....................................................... 156
16.1.3 Use Case 3: Instantiating L2VPN over SR-TE for Color 40 . 169
16.1.4 Instantiating SR-Policy with SR-PCE for Color 50 .............. 177
Preface Page 6
2 Preface
Abstract
This document serves as the documentation reference and user guide for the
NSO Transport SDN Function Pack (T-SDN FP) Bundle. This document is
applicable to T-SDN FP Bundle version 1.0.0.
Audience
This document describes how to configure and use the T-SDN function packs.
This document is intended for Cisco Advanced Services developers, network
engineers, and system engineers who install, configure, and deliver the T-SDN
automation functionalities to Cisco customers.
Additional Documentation
This documentation requires the reader to have a good understanding of
Cisco NSO and its usage as described in the Cisco NSO documentation. For
documentation on additional Cisco products, see the Cisco documentation
website.
Sl. No. Documentation

1. Cisco NSO Transport SDN FP Bundle
Installation Guide
2. Cisco NSO Installation Guide
3. Cisco NSO User Guide
Cisco Transport SDN Function Pack Bundle User Guide

Getting Started Page 7
3 Getting Started
This topic provides an overview of Cisco Network Services Orchestration
(NSO) and an understanding of Cisco Transport SDN function packs.
3.1 Cisco Network Services Orchestrator - Overview

This section gives a brief overview of Cisco NSO.
Network engineers use NSO as a central point of management for the entire
network by using a network command line interface (CLI). NSO enables
service providers to dynamically adopt their orchestration solution with
changes in the offered service portfolio. NSO is built on a Model-Driven
Architecture which supports the dynamic addition and modification of service
definitions. The service models are written in the YANG modeling language
(RFC 6020).
You can also upload the configuration information to NSO by using the
payloads. These payloads contain the desired service configurations in an XML
format. Each service can have a single file or multiple files. Deploy the
configuration information by using payloads through the NSO CLI or by
invoking the Northbound interface to create and modify service
configurations. This documentation uses both network CLI and sample XML
payloads.
From a Linux console, invoke the Network Configuration Protocol NETCONF

NBI command to push or load the XML payload into NSO.

# netconf-console --port=[port_number]--host=[host_IP_address] -u
[username] -p [password] --edit-config payload.xml
Example
# netconf-console --port=830 --host=127.0.0.1 -u admin -p Fr3eB!rd$ --
edit-config payload.xml
Run the following command to get the configuration details from the
configuration database in the NSO. For more information about NETCONF, see
Cisco Networking Services Configuration Guide.
# netconf-console --port=[port_number]--host=[host_IP_address] -u
[host_username] -p [host_password] –get get-config
Example
# netconf-console --port=830 --host=127.0.0.1 -u admin -p Fr3eB!rd$ –get get-
config
NETCONF supports the following operations:
• <get-config>
• <edit-config> (operation="create")
• <edit-config> (operation="replace")
• <edit-config> (operation="merge")
• <edit-config> (operation="delete")
The typical workflow when using the network CLI in NSO is as follows:
• All changes are initially made to a (logical) copy of the NSO database of
configurations.
• You can view and verify the changes prior to committing them.
• The changes are committed, meaning that the changes are copied to
the NSO database and pushed out to the network. Changes that
violate integrity constraints or network policies are not committed.
The changes to the devices are done in a holistic distributed atomic
transaction, across all devices in parallel.
Changes either succeed and remain committed or fail and are rolled back as a
whole, returning the entire network to the uncommitted state.

3.2 Cisco NSO Transport SDN Function Pack Bundle - Overview

The NSO T-SDN FP Bundle is part of the Cisco Crosswork Network Controller
solution, or can be used as part of a customer solution. NSO T-SDN FP Bundle
is based on the SDN architecture to control and manage the transport
networks in a multi-layer and multi-vendor environment. Cisco SDN provides
choice in automation and programmability across data centers, campuses,
and wide-area networks. Use Cisco software-defined solutions to build intent
based networks (IBN).
IBN transforms a hardware-centric, manual network into a controller-led
network that captures business intent and translates it into policies that can
be automated and applied consistently across the network. The goal is for the
network to continuously monitor and adjust network performance to help
assure desired business outcomes.
The NSO T-SDN FPs forms an extension of SDN, which allows the higher level
network controllers to reroute the network traffic. The NSO T-SDN FPs extend
the Cisco Crosswork solution, which is designed to help service providers gain
the mass awareness, augmented intelligence, and proactive control for a
comprehensive data-driven, intent-based automated network.
The NSO T-SDN FPs are installed on the NSO platform. The NSO T-SDN FPs use
orchestration to push services and network configurations. The NSO T-SDN
FPs utilize NSO Reactive FastMap (RFM) nano services to manage the full
life-cycle of a service.
The NSO T-SDN FP Bundle consists of:
1. SR-TE Core Function Pack (CFP) – a productized and supported
implementation of SR-TE automation
2. Example function packs for Layer 2 and Layer 3 VPNs, intended to be
customized for each customer deployment by Cisco Customer Experience
(CX).
Without having to modify the SR-TE CFP, it allows you to add additional
configurations into a device by using custom-templates.
SR-TE CFP comprises the following modules/services:
➢ SR-TE on-Demand-Network (ODN)
➢ SR-TE Policies
SR policy path computation of SR-TE CFP supports service specific constraints,
such as bandwidth, latency, path diversity, and traffic engineering constraints,
such as affinity, bandwidth, cost, latency coming from the network.

SR-TE CFP configures the SR-TE policies and instantiates services. Using the
network topology and inventory collected, SR-TE CFP solution supports the
example function packs SR-Settings and SR-PCE. L3VPN and L2VPN services
can then be provisioned with specified segment routing policy. These example
function packs utilize SR-TE policies for service instantiation.
3.3 T-SDN Function Packs Bundle Architecture

The following diagram shows the architecture of the T-SDN function packs.
NSO provides Service Provisioning functionality of T-SDN FPs by:

• Provisioning SR-Policy
• Provisioning SR-Settings, SR-PCE, L2VPN, and L3VPN over an existing
SR-Policy (ODN or Preferred Path option)
T-SDN FPs are implemented by using the SR-TE CFP and the example function
packs – SR-Settings, SR-PCE, L2VPN, and L3VPN.
A router in a SR network is capable of selecting any path to forward traffic,
whether it is explicit or Interior Gateway Protocol (IGP) shortest path.
Each segment is an end-to-end path from the source to the destination, and
instructs the routers in the provider core network to follow the specified path
instead of the shortest path calculated by the IGP. Segments represent
subpaths that a router can combine to form a complete route to a network
destination.

SR-TE CFP provides the SR-TE policies and SR-ODN services. T-SDN FPs
configure the SR-TE policies and instantiates services, such as the SR-Settings,
SR-PCE, L2VPN and/or L3VPN function packs that utilize these SR-TE policies.
Note: The example function packs can be used for reference
implementations.
SR-TE Settings allows you to configure the following on the head-end:
➢ Affinity
➢ Interface affinity
➢ PCC
➢ Flex-algo
➢ SRLG
➢ Performance Measurement
➢ IGP Metric
SR-PCE service helps configure path computation element related
configuration on nodes.
L2VPN allows you to configure point-to-point pseudowire (PW):
➢ Static PW or Ethernet VPN Virtual Private Wire Service (EVPN VPWS)
➢ Association of SR-TE Policy
The following diagram shows the workflow to instantiate the L2VPN EPVN
VPWS. It represents the logical flow of deployment, which can be deployed
either separately or in a single commit.
L3VPN allows you to configure:

➢ VPN

➢ Interface
➢ BGP Neighbor
➢ Association of SR-TE Policy
The following diagram shows the workflow to instantiate the L3VPN over
SR-TE. It represents the logical flow of deployment, which can be deployed
either separately or in a single commit.

SR-TE Core Function Pack Page 13
4 SR-TE Core Function Pack

Segment Routing prepares networks for business models, where applications
can direct network behavior. SR provides the right balance between
distributed intelligence and centralized optimization and programming.
SR-TE takes place between a source and destination pair. SR-TE uses the
concept of source routing, where the source calculates the path and encodes
it in the packet header as a segment. Each segment is an end-to-end path
from the source to the destination, and instructs the routers in the provider
core network to follow the specified path instead of the shortest path
calculated by the IGP.
SR-TE requires minimal configuration on the source router. The SR-TE CFP
provides the SR-TE policies and SR-TE ODN. This chapter discusses each of
these SR-TE CFP services.
For information about yang models and payloads, see Appendix B - Yang
Models and Appendix C - Payloads and XML Outputs respectively in this
documentation. For information on how to create SR-Policy, see chapter
Configuration in this documentation.
4.1 SR-TE ODN

SR-TE ODN service helps configure an SR Policy template for each color for
which on-demand SR Policy instantiation is desired.
4.2 SR-Policy
SR-TE uses a policy to steer traffic through the network. An SR-TE policy path
is expressed as a list of segments that specifies the path, called a segment ID
(SID) list.
An SR-TE policy uses one or more candidate paths. A candidate path is a single
segment list (SID-list) or a set of weighted SID-lists. If a packet is steered into
an SR-TE policy, the SID list is pushed on the packet by the head-end. The rest
of the network executes the instructions embedded in the SID list.
Each segment is an end-to-end path from the source to the destination, and
instructs the routers in the network to follow the specified path instead of the
shortest path calculated by the IGP.
An SR policy is uniquely identified by a tuple - head-end, color, and end-point.
The head-end is where the SR policy is instantiated or implemented. At a
given head-end, an SR policy is uniquely identified by a tuple (color, end-
point).

SR-TE Core Function Pack Page 14
There are two types of SR-TE policies:

➢ Local Dynamic SR-TE policy: When you configure local dynamic SR-TE
policy, the head-end locally calculates the path to the destination address.
Dynamic path calculation results in a list of interface IP addresses that
traffic engineering maps to adj-SID labels. Routes are learned by way of
forwarding adjacencies over the TE tunnel.
➢ Explicit SR-TE policy: An explicit path is a list of IP addresses or labels,
each representing a node or link in the explicit path. This feature is
enabled through the explicit-path command that allows you to create an
explicit path and enter a configuration submode to specify the path.

Example Function Packs Page 15
5 Example Function Packs

SR-Settings, SR-PCE, L2VPN, and L3VPN are example function packs to
illustrate how SR-TE policies are used to instantiate a service with T-SDN FPs.
It is optional to install/use these example function packs.
For more information on how to install these function packs, see the
Cisco NSO Transport SDN Function Pack Bundle Installation Guide.
For information about the yang models and payloads, see Appendix B - Yang
Models and Appendix C - Payloads and XML Outputs respectively in this
documentation.
For information on how to create these services, see chapter Configuration in
this documentation.
5.1 SR-Settings
Set the segment routing parameters to define the routing path/direction for
the segments.
In this service, you can use resource pools to logically allocate or share an
available set of resources. Resource pools provide the flexibility to manage
the existing resources and adjust the services to the needs of the customer.
For information on how to create SR-Settings and how to allocate resource
pools, see chapter Configuration in this documentation.
5.2 SR-PCE
SR-PCE describes a set of procedures by which a Path Computation Client
(PCC) can report and delegate control of a policy head-end.
For information on how to create SR-PCE, see chapter Configuration in this
documentation.
5.3 L2VPN
L2 Virtual Private Network (L2VPN) establishes an end-to-end layer 2
connection. L2VPN allows disparate systems to be connected in a way that it
appears as if they are connected by using a single physical connection, or are
using the same LAN.
L2VPNs employ L2 services over MPLS in order to build a topology of point-to-
point connections that connect end customer sites in a VPN.

Example Function Packs Page 16
5.4 L3VPN
L3VPN uses virtual routing and forwarding techniques to forward VPN traffic
over a network. For every endpoint, e-bgp can be configured to ODN.
The L3VPN service allows you to configure:
• VPN
• Interface
• BGP Neighbor
• Association of SR-TE Policy

Configuration Page 17
6 Configuration
The topics in this chapter provide information on how to configure the
services by using the T-SDN FPs. T-SDN FPs comprise SR-TE CFP. The SR-TE CFP
consists of SR-TE ODN services and SR-TE Policy.
Segment Routing integrates with multi-service capabilities of MPLS, including
Layer 3 VPN (L3VPN), Virtual Private Wire Service (VPWS), Virtual Private LAN
Service (VPLS), and Ethernet VPN (EVPN).
SR-Settings, SR-Policy, L2VPN, and L3VPN are example function packs used to
demonstrate SR-TE CFP. You can choose to install the required packages for
these function packs during or after T-SDN FPs installation.
For more information on the list of packages extracted during T-SDN FP
installation, see Appendix A: Package Categories and Packages in this
documentation. For more information on how to install the packages, see the
Cisco NSO Transport SDN Function Pack Bundle Installation Guide.
6.1 Creating SR-TE Services

SR-TE takes place through a tunnel between a source and destination pair. In
SR-TE, the source calculates the path and encodes it in the packet header as a
segment.
SR-TE CFP comprises the SR-ODN and SR-Policy modules to allow you to
configure the SR-TE policy at different stages.
6.1.1 Creating SR-ODN

SR-TE ODN service helps to configure an ODN template for a color for which
to instantiate the on-demand SR Policy.
To create SR-ODN:
1. The following sample payload shows how to create the SR-ODN service. For
the yang model, see Appendix B - Yang Models in this documentation.
<config xmlns="http://tail-f.com/ns/config/1.0">
<sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te">
<odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-odn">
<odn-template>
<name>SR-ODN</name>
<head-end>
<name>P-0</name>
</head-end>
<head-end>
<name>PIOSXR-0</name>
</head-end>
<maximum-sid-depth>6</maximum-sid-depth>

<color>300</color>
<bandwidth>200</bandwidth>
<dynamic>
<metric-type>igp</metric-type>
<pce/>
<flex-alg>200</flex-alg>
<disjoint-path>
<type>node</type>
<group-id>10</group-id>
<sub-id>5</sub-id>
</disjoint-path>
<affinity>
<rule>
<action>exclude-any</action>
<color>BLUE</color>
</rule>
</affinity>
</dynamic>
</odn-template>
</odn>
</sr-te>
</config>
2. Display the plan to view the status of the service. The following table
discusses certain plan components unique to this service. For a detailed
description of plan components, see NSO documentation.
Plan
Value Description
Component
Represents the connected
cisco-sr-te-cfp-sr-odn-nano-
Type node(device) of the nano plan of a
plan-services:head-end
service.
Represents acceptance of service
cisco-sr-te-cfp-sr-odn-nano-
State intent and respective configuration
plan-services:config-apply
application on device
admin@ncs% run show sr-te cisco-sr-te-cfp-sr-odn:odn odn-template-plan
POST
BACK STATUS
ACTION
TYPE NAME TRACK GOAL CODE STATE
STATUS WHEN ref STATUS
------------------------------------------------------------------------------------------
self self false - - init
reached 2020-04-22T21:26:01 - -
ready
reached 2020-04-22T21:27:44 - -
cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end P-0 false - - init
reached 2020-04-22T21:26:01 - -
cisco-
sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:27:44 - -
ready
reached 2020-04-22T21:27:44 - -
cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 false - - init
reached 2020-04-22T21:26:01 - -
cisco-
ready
reached 2020-04-22T21:27:44 - -

6.1.2 Creating SR-Policies

Use SR-Policies to instruct the routers in the network to follow a specified
path instead of the shortest path calculated by the IGP. If a packet is steered
into an SR-TE policy, the SID list is pushed on the packet by the head-end. The
rest of the network executes the instructions embedded in the SID list.
To create SR-policies:
1. The following is a sample payload to create the SR-Policies service. For the
yang model, see Appendix B - Yang Models in this documentation.
<policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-
policies">
<policy>
<name>SR-CLI-DYNAMIC</name>
<head-end>
</head-end>
<tail-end>1.1.1.1</tail-end>
<color>111</color>
<path>
<preference>111</preference>
<dynamic>
<metric-type>te</metric-type>
<constraints>
<affinity>
<rule>
<action>include-all</action>
<color>GREEN</color>
<color>RED</color>
</rule>
</affinity>
<segments>
<sid-algorithm>128</sid-algorithm>
</segments>
</constraints>
</dynamic>
</path>
</policy>
</policies>
</sr-te>
</config>

Plan
Value Description
Component
Represents a connected node (device) of
Type head-end
the nano plan of a service.
cisco-sr-te-cfp-sr- Represents acceptance of service intent
State policies-nano-plan- and respective config application on device.
services:config-apply
admin@ncs% run show sr-te cisco-sr-te-cfp-sr-policies:policies policy-

plan SR-CLI-DYNAMIC plan
POST
BACK
ACTION
TYPE NAME TRACK GOAL STATE
----------------------------------------------------------------------
self self false - init
reached 2020-04-03T19:46:14 - -
ready
reached 2020-04-03T19:48:57 - -
cisco-sr-te-cfp-sr-policies-nano-plan-services:head-end PIOSXR-0 false - init
reached 2020-04-03T19:46:14 - -
cisco-sr-
te-cfp-sr-policies-nano-plan-services:config-apply reached 2020-04-03T19:48:57 - -
ready
reached 2020-04-03T19:48:57 - -
6.2 Creating SR-Settings Services

SR-TE Settings service allows you to configure the following on the head-end:
• Affinity
• Interface affinity
• PCC
• Flex-algo
• SRLG
• Performance Measurement
• IGP Metric
To create SR-Settings service:

1. The following is a sample payload to create the SR-Settings service. For the
<sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-
sr-te-settings">
<name>SETTING-1</name>
<affinity-map-te>
<color>
<name>BLUE</name>

<bit-position>1</bit-position>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map-te>
<pcc>
<pce>
<address>
<ipv4>
<address>1.1.1.1</address>
<precedence>128</precedence>
</ipv4>
<ipv4>
</ipv4>
</address>
</pce>
</pcc>
<node>
<interface>
<if-type>GigabitEthernet</if-type>
<if-id>5</if-id>
<te>
<affinity>
<color>
<name>GREEN</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
<source-address>192.168.2.1</source-address>
</pcc>
</node>
<node>
<interface>
<if-id>7</if-id>
<te>
<affinity>
<color>
<name>BLUE</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
<disable/>
</pcc>
</node>
</sr-setting>
</config>

Plan
Value Description
Component
cisco-sr-te-settings- Represents a connected node (device) of
Type fp-nano-plan- the nano plan of a service.
services:node
cisco-sr-te-settings- Represents acceptance of service intent
State fp-nano-plan- and respective configuration application on
services:config-apply device.
admin@ncs% run show sr-setting-plan

POST
BACK STATUS
ACTION
----------------------------------------------------------------------
reached 2020-04-22T22:17:08 - -
ready
reached 2020-04-22T22:17:12 - -
cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init
reached 2020-04-22T22:17:08 - -
cisco-sr-
te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:17:12 - -
ready
reached 2020-04-22T22:17:12 - -
reached 2020-04-22T22:17:08 - -
cisco-sr-
ready
reached 2020-04-22T22:17:12 - -
6.2.1 Allocating Resources by Using Resource Pools

Use resource pools to logically allocate or share an available set of resources.
You can add a range of resource values to the pool. You can allocate flex-algo
absolute and index values from the pool.
To allocate resources:
Run the following commands:
admin@ncs% set resource-pools id-pool SRGB_POOL range start 18000 end
18010
admin@ncs% commit
Commit complete.

Sample Payloads – Resource Pools

In the following example, the first payload shows a service deployment. The
second payload shows an update to the service deployment payload (first
payload) with auto-assign-absolute and auto-assign-index features.
Service deployment payload

<settings xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-
settings">
<setting>
<node>
<name>P-0</name>
<interface>
<if-id>5</if-id>
<te>
<affinity>
<color>
<name>BLUE</name>
</color>
<color>
<name>RED</name>
</color>
</affinity>
</te>
</interface>
<pcc>
</pcc>
</node>
<node>
<name>P-1</name>
<interface>
<if-id>3</if-id>
<te>
<affinity>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity>
</te>
</interface>
<pcc>
<disable/>
</pcc>
</node>
<node>

<interface>
<if-id>5</if-id>
<te>
<affinity>
<color>
<name>GREEN</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
</pcc>
</node>
<node>
<interface>
<if-id>7</if-id>
<te>
<affinity>
<color>
<name>BLUE</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
<disable/>
</pcc>
</node>
<affinity-map-te>
<color>
<name>BLUE</name>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map-te>
<pcc>
<pce>
<address>
<ipv4>
</ipv4>
<ipv4>
</ipv4>
</address>
</pce>

</pcc>
</setting>
</settings>
</sr-te>
</config>
The following payload shows an update to the service deployment payload

with the auto-assign-absolute and auto-assign-index features.
<settings xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-
settings">
<setting>
<sr-global-block>
<sr-pool>
<sr-pool-name>SRGB_POOL</sr-pool-name>
</sr-pool>
</sr-global-block>
<igp-metric>
<metric>1001</metric>
<metric-level>
<metric>
<level>1</level>
<value>1002</value>
</metric>
</metric-level>
</igp-metric>
<interface-igp-metric>
<metric-level>
<metric>
<level>1</level>
<value>1008</value>
</metric>
</metric-level>
</interface-igp-metric>
<slice>
<flex-algo>
<name>128</name>
<affinity-exclude-any>RED</affinity-exclude-any>
<affinity-exclude-any>BLUE</affinity-exclude-any>
<metric-type>delay</metric-type>
<priority>100</priority>
</flex-algo>
<flex-algo>
<name>129</name>
<affinity-exclude-any>GREEN</affinity-exclude-any>
</flex-algo>
<isis>
<instance-name>CORE</instance-name>
<node>
<flex-algo>
<name>128</name>
<algorithm-prefix-sid>
<auto-assign-absolute/>
</algorithm-prefix-sid>
</flex-algo>

<flex-algo>
<name>129</name>
<index>4</index>
</flex-algo>
<loopback>
<id>1</id>
<flex-algo>
<name>128</name>
</flex-algo>
<flex-algo-enabled-flag>select</flex-algo-enabled-
flag>
</loopback>
<loopback>
<id>2</id>
<flex-algo>
<name>129</name>
</flex-algo>
<flex-algo-enabled-flag>select</flex-algo-enabled-
flag>
</loopback>
</node>
<address-family>both</address-family>
<igp-metric>
<metric-level>
<metric>
<level>1</level>
<value>1005</value>
</metric>
</metric-level>
</igp-metric>
<mpls-preference>sr-prefer</mpls-preference>
</isis>
<isis>
<instance-name>CORE-2</instance-name>
<node>
<flex-algo>
<name>128</name>
<absolute>18006</absolute>
</flex-algo>
<flex-algo>
<name>129</name>
<auto-assign-index/>
</flex-algo>
<loopback>
<id>3</id>
</loopback>
</node>
<node>
<name>P-0</name>
<flex-algo>
<name>128</name>

</flex-algo>
<flex-algo>
<name>129</name>
<index>7</index>
</flex-algo>
<loopback>
<id>3</id>
</loopback>
</node>
</isis>
</slice>
<node>
<isis>
<loopback>
<id>1</id>
<prefix-sid>
<auto-assign-index/>
<n-flag-clear/>
</prefix-sid>
</loopback>
<loopback>
<id>2</id>
<prefix-sid>
<index>10</index>
</prefix-sid>
</loopback>
</isis>
<isis>
<loopback>
<id>3</id>
<prefix-sid>
<index>8</index>
</prefix-sid>
</loopback>
</isis>
<interface>
<if-id>5</if-id>
<isis>
</isis>
</interface>
<interface>
<if-id>7</if-id>
<isis>

<affinity>
<color>
<name>BLUE</name>
</color>
<color>
<name>RED</name>
</color>
</affinity>
<metric-level>
<metric>
<level>2</level>
<value>1006</value>
</metric>
</metric-level>
</isis>
</interface>
</node>
<node>
<name>P-0</name>
<isis>
<loopback>
<id>3</id>
<prefix-sid>
<auto-assign-absolute/>
</prefix-sid>
</loopback>
</isis>
<interface>
<if-id>5</if-id>
<isis>
</isis>
</interface>
</node>
<affinity-map-isis>
<color>
<name>BLUE</name>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map-isis>
</setting>
</settings>
</sr-te>
</config>

6.2.1.1 Verifying Allocation

Verify the allocation status from NSO.
admin@ncs% run show sr-setting-prefix-sid-allocation
ISIS ALGO
NODE INSTANCE LOOPBACK PREFIX PREFIX
NAME NAME NODE NAME ID SID NAME SID
-------------------------------------------------------------------------
SETTING-1 P-0 P-0 CORE-2 3 18000 128 18009
129 7
SETTING-1 PIOSXR-0 PIOSXR-0 CORE 1 2 128 18001
2 10 129 4
CORE-2 3 8 128 18006
129 3
The following plan displays a successful allocation.

POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------------
reached 2020-04-22T23:29:25 - -
ready
reached 2020-04-22T23:31:02 - -
cisco-sr-te-settings-fp-nano-plan-services:node P-0 false - - init
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:31:02 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:30:59 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:31:02 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:30:59 - -
6.2.1.2 Adding Resources to the Pool

The following commands show how to add resources to a resource pool.
admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback
3 prefix-sid auto-assign-index n-flag-clear


admin@ncs% commit
Commit complete.

If you add resources to a resource pool beyond a specified range, the plan
fails with an error message.

POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------------
reached 2020-04-22T23:29:25 - -
ready
failed 2020-04-22T23:33:20 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:31:02 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:30:59 - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
te-settings-fp-nano-plan-services:config-apply failed 2020-04-22T23:33:20 - -
ready
not-reached - - -
reached 2020-04-22T23:29:25 - -
cisco-sr-
ready
reached 2020-04-22T23:30:59 - -
plan failed
plan error-info message "com.tailf.pkg.idpool.exceptions.PoolExhaustedException: ID pool
SRGB_POOL exhausted"
6.3 Creating SR-PCE Services

SR-PCE service helps set up path computation element related configuration
information on devices.
To create SR-PCE service:
1. The following is a sample payload to create the SR-PCE service. For the yang
model, see Appendix B - Yang Models in this documentation.
<sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-
pce">
<name>PCE-0</name>
<node>
<pce>
<disjoint-path>
<group-id>
<id>60000</id>

<type>srlg</type>
<strict/>
<lsp>
<id>1</id>
<pcc-address>2.2.2.2</pcc-address>
<lsp-name>LSP-NAME</lsp-name>
<shortest-path/>
</lsp>
</group-id>
</disjoint-path>
<timers>
<reoptimization>600</reoptimization>
<keepalive>20</keepalive>
<minimum-peer-keepalive>21</minimum-peer-keepalive>
</timers>
<state-sync>
<ipv4>
</ipv4>
</state-sync>
<password>
<type>clear</type>
<secret>password123</secret>
</password>
<backoff>
<ratio>11</ratio>
<difference>10</difference>
<threshold>12</threshold>
</backoff>
<segment-routing>
<strict-sid-only/>
<te-latency/>
</segment-routing>
</pce>
</node>
</sr-pce>
</config>
Plan
Value Description
Component
cisco-sr-te-sr-pce- Represents a connected node (device) of
Type nano-plan- the nano plan of a service.
services:node
cisco-sr-te-sr-pce- Represents acceptance of service intent
State nano-plan- and respective configuration application on
services:config-apply device.
admin@ncs% run show sr-pce-plan

POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------
reached 2020-04-22T16:57:54 - -
ready
reached 2020-04-22T16:57:57 - -
cisco-sr-te-pce-fp-nano-plan-services:node PIOSXR-0 false - - init
reached 2020-04-22T16:57:54 - -
cisco-sr-te-
pce-fp-nano-plan-services:config-apply reached 2020-04-22T16:57:57 - -
ready
reached 2020-04-22T16:57:57 - -
6.4 Creating Flat L2VPN Services with the L2VPN Example Function
Pack
You can implement a custom L2VPN function pack to meet specific
requirements. Use the example function pack as a starting point or for design
patterns.
There are two types of example L2VPN services: L2VPN P2P and L2VPN EVPN
VPWS. Each service requires a mandatory Local Site and an optional Remote
Site to create the service.
For the Flat L2VPN yang model, see Appendix B - Yang Models in this
documentation.
6.4.1 Creating Flat L2VPN-P2P

To create the Flat L2VPN-P2P service:
1. The following is a sample payload to create a Flat L2VPN-P2P service.
<flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-
tsdn-flat-L2vpn">
<name>P2P-DOT1Q</name>
<service-type>p2p</service-type>
<flat-L2vpn-p2p>
<pw-id>100</pw-id>
<local-site>
<pe>PIOSXR-0</pe>
<if-type>HundredGigE</if-type>
<if-id>0/0/0/8</if-id>
<if-encap>dot1q</if-encap>
<vlan-id>100</vlan-id>
<sub-if-id>100</sub-if-id>
<rewrite>
<ingress>
<translate>1-to-1</translate>
<dot1q>123</dot1q>
<mode>symmetric</mode>
</ingress>
</rewrite>
<xconnect-group-name>P2P-DOT1Q</xconnect-group-name>

<xconnect-encapsulation>mpls</xconnect-encapsulation>
<p2p-name>P2P-DOT1Q</p2p-name>
<control-word>no</control-word>
<pw-class>P2P-DOT1Q</pw-class>
<xconnect-local-ip>12.0.0.0</xconnect-local-ip>
<xconnect-remote-ip>14.0.0.0</xconnect-remote-ip>
<mpls-local-label>101</mpls-local-label>
<mpls-remote-label>202</mpls-remote-label>
</local-site>
<remote-site>
<pe>PIOSXR-1</pe>
<if-id>0/0/0/8</if-id>
<rewrite>
<ingress>
<dot1q>123</dot1q>
</ingress>
</rewrite>
<xconnect-group-name>P2P-DOT1Q</xconnect-group-name>
<p2p-name>P2P-DOT1Q</p2p-name>
</remote-site>
</flat-L2vpn-p2p>
</flat-L2vpn>
</config>
2. Display the plan to view the status of the service. For detailed service-
state-changes notifications, see chapter Notifications in this
documentation.
The following table discusses certain plan components unique to this
service. For a detailed description of plan components, see
NSO documentation.
Plan
Value Description
Component
This represents the Local-site (mandatory
local-site
site) of the L2VPN service.
Type
This represents the remote-site (optional
remote-site
site) of the L2VPN service.
cisco-flat-L2vpn- This represents the device configuration
fp-nano-plan- state in the nano-plan of a service.
State
services:config-
apply

admin@ncs% run show flat-L2vpn-plan L2vpn-p2p-1 plan

BACK
POST ACTION
TYPE NAME TRACK GOAL
STATE STATUS WHEN
ref STATUS
--------------------------------------------------------------------------------------
self self false -
init reached 2020-03-
03T22:06:26 - -
ready reached 2020-03-
03T22:07:01 - -
local-site PIOSXR-0 false -
03T22:06:26 - -
cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-03-
03T22:06:30 - -
03T22:06:30 - -
remote-site PIOSXR-1 false -
03T22:06:26 - -

03T22:06:30
03T22:06:30 - -
6.4.2 Creating Flat L2VPN – EVPN

Virtual Private Wire Service is the EVPN service provisioned by L2VPN.
For every site (local/remote), you can configure BGP in EVPN service. SR-ODN
allows a service head-end router to automatically instantiate an SR-policy to a
BGP next-hop when required for EVPN service.
Note: You must create the L2VPN-EVPN service to create the L2VPN
SR-TE preferred path service and the L2VPN SR-TE-ODN service.
To create the Flat L2VPN –EVPN-VPWS:
1. The following is a sample payload to create the service.

<flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-
flat-L2vpn">
<name>L2vpn-dynamic-02</name>
<service-type>evpn-vpws</service-type>
<flat-L2vpn-evpn-vpws>
<evi-id>1000</evi-id>
<local-site>
<pe>PIOSXR-0</pe>
<if-id>0/0/1/0</if-id>
<if-description>L2VPN-Dynamic-02</if-description>
<if-encap>untagged</if-encap>
<xconnect-group-name>evpn_vpws_nso</xconnect-group-name>
<p2p-name>EVPN-PIOSXR-0</p2p-name>
<evi-source>1</evi-source>
<evi-target>2</evi-target>
</local-site>
<remote-site>

<pe>PIOSXR-1</pe>
<if-type>TenGigE</if-type>
<if-id>0/0/0/35</if-id>
</remote-site>
</flat-L2vpn-evpn-vpws>
</flat-L2vpn>
</config>
2. Display the plan to view the status of the service. For detailed
service-state-changes notifications, see chapter Notifications in this
documentation.
The following table discusses certain plan components unique to
this service. For a detailed description of plan components, see
NSO documentation.
Plan
Value Description
Component
This represents the Local-site
local-site (mandatory site) of the L2VPN
Type service.
This represents the remote-site
remote-site
(optional site) of the L2VPN service.
cisco-flat-L2vpn-fp-nano- This represents the device
State plan-services:config- configuration state in the nano-plan
apply of a service.
admin@ncs% run show flat-L2vpn-plan L2vpn-dynamic-02 plan component

BACK
POST ACTION
TYPE NAME TRACK GOAL
STATE STATUS WHEN
ref STATUS
--------------------------------------------------------------------------------------
self self false -

15T00:53:46 - -
15T00:53:51 - -
local-site PIOSXR-0 false -
15T00:53:46 - -
15T00:53:50 - -
15T00:53:50 - -
remote-site PIOSXR-1 false -
15T00:53:46 - -


15T00:53:50 - -
15T00:53:50 - -
6.4.2.1 Creating L2VPN SR-TE ODN

On-Demand Next Hop (ODN) for L2VPN creates a SR-TE auto-tunnel and uses
the auto-tunnel for pseudowire dataplane. You must create the L2VPN route
policy to use the SR-TE ODN service. For more information, see section
Creating Flat L2VPN – EVPN in this documentation.
To create L2VPN SR-TE ODN:

1. The following is a sample payload to create the route-policy.
<l2vpn-route-policy
xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn">
<name>L2-RP-local</name>
<color>
<id>100</id>
<ipv4>
<rd>1.1.1.1:1</rd>
<rd>1.1.1.2:1</rd>
</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
<rd>2.1.1.1:1</rd>
<rd>2.1.1.2:1</rd>
</ipv4>
</color>
</l2vpn-route-policy>
<l2vpn-route-policy
<name>L2-RP-remote</name>
<color>
<id>100</id>
<ipv4>
<rd>3.1.1.1:1</rd>
<rd>3.1.1.2:1</rd>
</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
<rd>4.1.1.1:1</rd>
<rd>4.1.1.2:1</rd>
</ipv4>
</color>
</config>

2. The following is a sample payload to create the service.

flat-L2vpn">
<local-site>
<pe>PIOSXR-0</pe>
<if-id>0/0/1/0</if-id>
<bgp>
<as-no>65001</as-no>
<remote-as-no>2</remote-as-no>
<neighbor-ipv4>9.9.9.9</neighbor-ipv4>
<update-source>
<if-type>Loopback</if-type>
<if-id>3</if-id>
</update-source>
</bgp>
<sr-te>
<odn>
<route-policy>L2-RP-local</route-policy>
</odn>
</sr-te>
</local-site>
<remote-site>
<pe>PIOSXR-1</pe>
<if-id>0/0/0/35</if-id>
<bgp>
<remote-as-no>2</remote-as-no>
<update-source>
<if-id>3</if-id>
</update-source>
</bgp>
<sr-te>
<odn>
<route-policy>L2-RP-remote</route-policy>
</odn>
</sr-te>
</remote-site>
</flat-L2vpn>
</config>
3. Display the plan to view the status of the service.

6.4.2.2 Creating L2VPN SR-TE Preferred Path

A candidate path has a preference. If two policies have same {color, endpoint}
but different preferences, the policy with the highest preference is selected.
An SR-TE policy initiates a single (selected) path, which is the preferred valid
candidate path.
You must create the L2VPN SR-TE preferred path service on top of the L2VPN-
EVPN-VPWS service. For more information, see section Creating Flat L2VPN –
EVPN in this documentation.
To create L2VPN SR-TE preferred path:
1. The following is a sample payload to create the SR-TE preferred path.
flat-L2vpn">
<local-site>
<pe>PIOSXR-0</pe>
<if-id>0/0/1/0</if-id>
<sr-te>
<preferred-path>
<policy>SR-CLI-ERO-VPWS-PIOSXR-0</policy>
</preferred-path>
</sr-te>
<pw-class>ero-nso</pw-class>
</local-site>
<remote-site>
<pe>PIOSXR-1</pe>
<if-id>0/0/0/35</if-id>
<sr-te>
<preferred-path>
<policy>SR-CLI-ERO-VPWS-PIOSXR-1</policy>
</preferred-path>
</sr-te>
<pw-class>ero-nso</pw-class>
</remote-site>
</flat-L2vpn>
</config>
3. Verify the configuration on the device by running the sh run l2vpn command.

6.5 Creating Flat L3VPN Services with the L3VPN Example Function
Pack
You can implement a custom L3VPN function pack to meet specific
requirements. Use the example function pack as a starting point or for design
patterns.
The example Flat L3VPN service allows you to configure:
• VPN
• Interface
• BGP Neighbor
• Association of SR-TE Policy
The following table describes the L3VPN plan components.
Plan
Value Description
Component
This component represents one
Type endpoint of the endpoints of L3VPN
service.
This represents the device
cisco-flat-L3vpn-fp-nano-plan-
State configuration state in the nano-
services:config-apply
plan of a service.
6.5.1 Creating Flat L3VPN

1. The following is a sample payload to create the Flat L3VPN service. For the
flat-L3vpn">
<name>L3-NC</name>
<endpoint>
<endpoint-name>nc-0</endpoint-name>
<access-pe>PIOSXR-0</access-pe>
<if-type>BVI</if-type>
<if-id>168</if-id>
<pe-ip-addr>169.1.1.1/28</pe-ip-addr>
<ce-pe-prot>
<e-bgp>
<remote-as-ipv4>65002</remote-as-ipv4>
</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN-0</vrf-definition>
<route-distinguisher>1:2</route-distinguisher>
<address-family>

<address-family>ipv4</address-family>
<vpn-target>
<rt-value>100:101</rt-value>
<rt-type>export</rt-type>
</vpn-target>
<vpn-target>
<rt-type>import</rt-type>
</vpn-target>
<vpn-target>
<rt-type>both</rt-type>
</vpn-target>
</address-family>
</vrf>
<sr-te>
<route-policy>L3-RP-EP1</route-policy>
</sr-te>
<l2-attachment-circuit>
<name>AC1</name>
<if-id>0/0/0/6</if-id>
<rewrite>
<ingress>
<push/>
<dot1q>123</dot1q>
</ingress>
</rewrite>
</l2-attachment-circuit>
<name>AC2</name>
<if-id>0/0/0/5</if-id>
<rewrite>
<ingress>
<pop>1</pop>
</ingress>
</rewrite>
</endpoint>
</flat-L3vpn>
<l3vpn-route-policy
<name>L3-RP-EP1</name>
<color>
<id>100</id>
<ipv4>
<prefix>1.1.1.1/32</prefix>
</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
</ipv4>
</color>

<l3vpn-route-policy
<color>
<id>100</id>
<ipv4>
</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
</ipv4>
</color>
</config>
2. Display the plan to view the status of the service. For detailed service-state-
changes notifications, see chapter Notifications in this documentation.
admin@ncs% run show flat-L3vpn-plan

POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------------
reached 2020-05-02T00:45:30 - -
ready
reached 2020-05-02T00:45:33 - -
endpoint nc-0 false - - init
reached 2020-05-02T00:45:30 - -
cisco-flat-L3vpn-fp-nano-plan-services:config-apply
reached 2020-05-02T00:45:33 - -
ready
reached 2020-05-02T00:45:33 - -
6.5.2 Creating L3VPN SR-TE ODN

On-Demand Next Hop (ODN) for L2VPN creates a SR-TE auto-tunnel and uses
the auto-tunnel for pseudowire dataplane.
To create L3VPN SR-TE ODN:

1. Use the following payload to create the route-policy. You must create the
L3VPN route-policy to use SR-TE ODN in L3VPN service.
<l3vpn-route-policy
<color>
<id>100</id>
<ipv4>

</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
</ipv4>
</color>
<l3vpn-route-policy
<color>
<id>100</id>
<ipv4>
</ipv4>
</color>
<color>
<id>101</id>
<ipv4>
</ipv4>
</color>
</config>
2. The following is a sample payload to create the SR-ODN service for L3VPN.
flat-L3vpn">
<name>L3</name>
<endpoint>
<access-pe>P-0</access-pe>
<if-id>3</if-id>
<ce-pe-prot>
<e-bgp>
</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN</vrf-definition>
<vpn-id>11:13</vpn-id>
<address-family>
<vpn-target>

</vpn-target>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
<sr-te>
<route-policy>L3-RP-EP2</route-policy>
</sr-te>
</endpoint>
<endpoint>
<if-id>3</if-id>
<ce-pe-prot>
<e-bgp>
</e-bgp>
</ce-pe-prot>
<vrf>
<address-family>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
</endpoint>
</flat-L3vpn>
</config>
3. To verify the configuration:

a. Display and verify the plan is in the reached state.
b. Log in to the device and verify the route-policy is pushed to the device.
c. Verify the VPN is created under the BGP router.

6.5.3 Creating BVI L3VPN

A Bridge Virtual Interface (BVI) is a virtual interface within the router that acts
like a normal routed interface that does not support bridging, but represents
the comparable bridge group to routed interfaces within the router. When
you configure and enable routing on the BVI, packets that come in on a routed
interface, which are destined for a host on a segment in a bridge group, are
routed to the BVI. From BVI, the packet is forwarded to the bridging engine,
which forwards it through a bridged interface. Essentially, a BVI acts as the
routed interface for the merged interfaces that are actually bridged.
You can configure a BVI interface as a routing interface for the bridge domain
for a L3VPN service.
To create BVI L3VPN:
1. The following is a sample payload to create the BVI interface for L3VPN.
flat-L3vpn">
<name>L3-CLI</name>
<endpoint>
<access-pe>PIOSXR-0</access-pe>
<if-type>BVI</if-type>
<if-id>168</if-id>
<ce-pe-prot>
<e-bgp>
</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN-0</vrf-definition>
<address-family>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
<name>AC1</name>

<if-id>0/0/0/6</if-id>
<rewrite>
<ingress>
<push/>
<dot1q>123</dot1q>
</ingress>
</rewrite>
<name>AC2</name>
<if-id>0/0/0/5</if-id>
<rewrite>
<ingress>
<pop>1</pop>
</ingress>
</rewrite>
</endpoint>
</flat-L3vpn>
</config>
2. Log in to the device and verify the configuration.

admin@ncs% show cisco-flat-L3vpn-fp:flat-L3vpn VPN

Working with Action Commands Page 46
7 Working with Action Commands

Use the action commands to perform specific tasks on services, such as
service cleanup, to get the latest service modifications, and to redeploy
services.
7.1 Service Cleanup Actions

When you try to perform a regular service deletion, it may fail for various
factors, such as the device being unreachable. This leaves the internal CDB
with stale entries of the service and the plan may reflect the failures. When
the regular service deletion fails to delete the service elements, use the
Cleanup action to clean up all the data created by the service.
Note: You must use the Cleanup action only if the regular service deletion fails
and no other recovery mechanisms are available.
The following table discusses the command arguments for the various
services.
Arguments Description
service-type This is the type of the service, such as SR-TE ODN.
service This is the name of the service to clean.
device This is the name of the device to clean under a given service. This
parameter is optional. If you do not provide the device name, it cleans
up the entire service.
service-name This is the name of the service to clean.
local-site-only This can point to an unreachable local-site that is replaced by another
reachable local site device in the service.
remote-site-only This can point to an unreachable remote-site that is removed from the
service.
endpoint This is the endpoint name in the service. If you do not provide any
other parameter, it cleans up the entire service.
No-networking This flag indicates if NSO must delete the service components from
network devices. By default, it is set to true.
When true, NSO cleanup does not remove configuration from network
devices. When false, NSO cleansup the device configuration

7.1.1 SR-ODN
Perform the Cleanup action to clean up either a specific device in the service
or the entire service. Cleaning up the entire service cleans up all the devices in
the service.
To clean up SR-ODN service per device

The following command shows how to clean up the SR-ODN service for a
device.
admin@ncs% request sr-te cleanup service-type sr-odn service SR-ODN
device PIOSXR-0 no-networking true
success true
detail Cleaning up SR TE service: SR-ODN
Removed all plan components
Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-
odn:odn/cisco-sr-te-cfp-sr-odn:odn-template{SR-ODN}
Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-
odn:odn/cisco-sr-te-cfp-sr-odn:odn-template{SR-ODN}
Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN P-0}
Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN P-0}
Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN
PIOSXR-0}
Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN
PIOSXR-0}
Removing service oper: /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/odn-template-oper-data{SR-ODN P-0 service-commit}
Removing service oper: /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/odn-template-oper-data{SR-ODN PIOSXR-0 service-commit}
Removed service oper
Removed side-effects
Removed kickers
Removed kickers
Removed kickers
Cleanup Successful
To clean up the SR-ODN service

The following command cleans up all the devices in the entire service.
admin@ncs% request sr-te cleanup service-type sr-odn service SR-ODN
no-networking true
success true
detail Cleaning up SR TE service: SR-ODN
Removed kickers
Removed kickers
Cleanup Successful

7.1.2 SR-Policy
A policy service can have only one head-end. Therefore, you can clean up only
the service, even if you provide a device name.
The following action command shows how to clean up the service.
admin@ncs% request sr-te cleanup service-type sr-policy service SR-
CLI-DYNAMIC no-networking true
success true
detail Cleaning up SR TE service: SR-CLI-DYNAMIC
Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-
policies:policies/cisco-sr-te-cfp-sr-policies:policy{SR-CLI-DYNAMIC}
Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-
policies:policies/cisco-sr-te-cfp-sr-policies:policy{SR-CLI-DYNAMIC}
Removed kickers
Removed kickers
Cleanup Successful
7.1.3 SR-Settings
Perform the Cleanup action either on a specific device or on the entire
service. Cleaning up the entire service cleans up all the devices in the service.
To clean up SR-Settings service per device
admin@ncs% request sr-setting-action cleanup service SETTING-1 device
PIOSXR-1 no-networking true
success true
detail Cleaning up SR TE service: SETTING-1
Removing service oper: /cisco-sr-te-settings-fp-internal:sr-setting-
internal/sr-setting-oper-data{SETTING-1 PIOSXR-1}
Removed kickers
Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-sr-te-
settings-fp-internal:sr-setting-internal/sr-setting-plan{SETTING-1
PIOSXR-1}/plan/component{ncs:self self}/state{cisco-sr-te-settings-fp-
nano-services:config-apply}"}
Removed kickers
Cleanup Successful
To clean up the SR-Settings service

admin@ncs% request sr-setting-action cleanup service SETTING-1 no-
networking true
success true
detail Cleaning up SR TE service: SETTING-1
Removing service oper: /cisco-sr-te-settings-fp-internal:sr-setting-
internal/sr-setting-oper-data{SETTING-1 PIOSXR-1}

Removed kickers
Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-sr-te-
settings-fp-internal:sr-setting-internal/sr-setting-plan{SETTING-1
PIOSXR-1}/plan/component{ncs:self self}/state{cisco-sr-te-settings-fp-
nano-services:config-apply}"}
Removed kickers
Cleanup Successful
7.1.4 SR-PCE
Perform the Cleanup action either on a specific device or on the entire
service. Cleaning up the entire service cleans up all the devices in the service.
To clean up SR-PCE service per device
admin@ncs% request sr-te cleanup service-type sr-pce service PCE-0
device PIOSXR-0 no-networking true
admin@ncs% request sr-pce-action cleanup service PCE-0 no-networking
true
success true
detail Cleaning up SR TE service: PCE-0
Removing service /cisco-sr-te-pce-fp:sr-pce{PCE-0}
Removed service /cisco-sr-te-pce-fp:sr-pce{PCE-0}
Removing service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0}
Removed service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0}
Removing service oper: /cisco-sr-te-pce-fp-internal:sr-pce-
internal/sr-pce-oper-data{PCE-0 PIOSXR-0}
Removed kickers
Removed kickers
Cleanup Successful
To clean up the SR-Settings service

admin@ncs% request sr-pce-action cleanup service PCE-0 no-networking
true
success true
detail Cleaning up SR TE service: PCE-0
Removing service /cisco-sr-te-pce-fp:sr-pce{PCE-0}
Removed service /cisco-sr-te-pce-fp:sr-pce{PCE-0}
Removing service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0}
Removed service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0}
Removing service oper: /cisco-sr-te-pce-fp-internal:sr-pce-
internal/sr-pce-oper-data{PCE-0 PIOSXR-0}
Removed kickers
Removed kickers
Cleanup Successful

7.1.5 L2VPN Example Services

You can clean up the service only for a remote site. You cannot clean up the
local site since it is a mandatory entity for the existence of L2VPN service.
You can clean up a specific remote site in the service or clean up the entire
service. Cleaning up the entire service cleans up all the remote sites and local
sites in the service.
To cleanup the service for a specific remote site

admin@ncs% request flat-L2vpn-actions cleanup service P2P-DOT1Q
remote-site-only PIOSXR-1
success true
detail Cleaning up L2vpn service: P2P-DOT1Q
Removing service /cisco-flat-L2vpn-fp:flat-L2vpn{P2P-DOT1Q}/flat-
L2vpn-p2p/remote-site
Removed service /cisco-flat-L2vpn-fp:flat-L2vpn{P2P-DOT1Q}/flat-
L2vpn-p2p/remote-site
Removing service /cisco-flat-L2vpn-fp-internal-remote-site:flat-
L2vpn-internal-remote-site-service{P2P-DOT1Q PIOSXR-1}
Removed service /cisco-flat-L2vpn-fp-internal-remote-site:flat-L2vpn-
internal-remote-site-service{P2P-DOT1Q PIOSXR-1}
Removing service oper: /cisco-flat-L2vpn-fp-internal-remote-
site:flat-L2vpn-internal-remote-site/flat-L2vpn-oper-data{P2P-DOT1Q
PIOSXR-1}
Removed kickers
Cleanup Successful
To cleanup the entire L2VPN service

The following command shows how to clean up the service.
admin@ncs% request flat-L2vpn-actions cleanup service P2P-DOT1Q no-
networking true
success true
detail Cleaning up L2vpn service: P2P-DOT1Q
Removed kickers
Cleanup Successful


Perform the Cleanup action to clean up a specific endpoint or the entire
service. Cleaning up the entire service cleans up all the endpoints in the
service.
To clean up the service for a specific endpoint
admin@ncs% request flat-L3vpn-actions cleanup service L3 device nc-0
no-networking true
success true
detail Cleaning up L3vpn service: L3
Removing service oper: /cisco-flat-L3vpn-fp-internal:flat-L3vpn-
internal/flat-L3vpn-oper-data{L3 nc-0}
Removed kickers
Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-flat-
L3vpn-fp-internal:flat-L3vpn-internal/flat-L3vpn-plan{L3 nc-
0}/plan/component{ncs:self self}/state{cisco-flat-L3vpn-fp-nano-
services:config-apply}"}
Removed kickers
Cleanup Successful
To clean up the L3VPN service

admin@ncs% run request flat-L3vpn-actions cleanup service L3 no-
networking true
success true
detail Cleaning up L3vpn service: L3
Removed kickers
Cleanup Successful
7.2 Auto Cleanup

You must use the Cleanup action only if the regular service deletion fails and
no other recovery mechanisms are available.
Note: Use the auto-cleanup action only after you have tried the manual
service cleanup operation discussed in section Service Cleanup Actions.
With the auto-cleanup action, you can automatically clean up the device
related configuration from NSO when the device is not reachable. Set the
auto-cleanup flag to true as follows to use this feature. By default, this flag is
set to false.

After the clean up is complete, depending on whether the NSO or the device
holds the correct configuration, perform a sync-to or sync-from to synchronize
NSO and the device, when the device is active.
This topic contains information for the following services in the order listed.
➢ SR-TE CFP
➢ Example Function Packs
SR-TE CFP
admin@ncs% set cisco-sr-te-cfp:cfp-configurations auto-cleanup true

admin@ncs% commit
Commit complete.
Example Function Packs

SR-Settings
admin@ncs% set cisco-sr-te-settings-fp:cfp-configurations auto-cleanup
true
admin@ncs% commit
Commit complete.
SR-PCE
admin@ncs% set cisco-sr-te-pce-fp:cfp-configurations auto-cleanup true
admin@ncs% commit
Commit complete.
L2VPN
admin@ncs% set cisco-flat-L2vpn-fp:cfp-configurations auto-cleanup
true
admin@ncs% commit
Commit complete.
L3VPN
admin@ncs% set cisco-flat-L3vpn-fp:cfp-configurations auto-cleanup
true
admin@ncs% commit
Commit complete.

7.3 get-modifications Action

The get-modifications action is similar to the service get-modifications action.
You can perform this action either at the service level or at the device level.
This action returns the data the service modified in the CDB (whether it is
device configuration or internal data), either in the CLI curly bracket format or
NETCONF XML edit configuration format. By default, the output format is CLI.
This data is available only if the parameter /services/global-settings/collect-
forward-diff is set to true as follows before you create the service.
admin@ncs% show services global-settings collect-forward-diff
collect-forward-diff true;
Note: Setting this parameter to true can have severe performance

implications. For more information about this parameter, see the NSO User
Guide.
This section provides the output in CLI format, which is the default format for
the SR-TE CFP services. To view the XML format of the output, see Appendix C
- Payloads and XML Outputs in this documentation.
7.3.1 SR-ODN
Perform the get-modifications action either at the service level or at the
device level.
get-modifications action for the service
admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-
ODN action get-modifications outformat cli
message devices {
device P-0 {
config {
segment-routing-ms-cfg:sr {
traffic-engineering {
on-demand-colors {
+ on-demand-color 300 {
+ on-demand-color-dyn-mpls {
+ on-demand-color-dyn-mpls-metric {
+ metric-type igp;
+ enable;
+ }
+ on-demand-color-dyn-mpls-pce {
+ enable;
+ }
+ disjoint-path {
+ group-id 10;
+ disjointness-type node;
+ sub-id 5;
+ }
+ on-demand-color-dyn-mpls-flex-
algorithm 200;
+ enable;
+ affinity-rules {

+ affinity-rule affinity-exclude-
any {
+ affinity-name BLUE;
+ }
+ }
+ }
+ bandwidth 200;
+ maximum-sid-depth 6;
+ enable;
+ }
}
}
}
}
}
}
get-modifications action per device

ODN action get-modifications device P-0 outformat cli
message devices {
device P-0 {
config {
segment-routing-ms-cfg:sr {
traffic-engineering {
on-demand-colors {
+ on-demand-color 300 {
+ on-demand-color-dyn-mpls {
+ on-demand-color-dyn-mpls-metric {
+ metric-type igp;
+ enable;
+ }
+ on-demand-color-dyn-mpls-pce {
+ enable;
+ }
+ disjoint-path {
+ group-id 10;
+ disjointness-type node;
+ sub-id 5;
+ }
+ on-demand-color-dyn-mpls-flex-
algorithm 200;
+ enable;
+ affinity-rules {
+ affinity-rule affinity-exclude-
any {
+ affinity-name BLUE;
+ }
+ }
+ }
+ bandwidth 200;
+ enable;
+ }
}
}
}
}
}
}

7.3.2 SR-Policy
get-modifications action for service
admin@ncs% request sr-te cisco-sr-te-cfp-sr-policies:policies policy
SR-CLI-DYNAMIC action get-modifications outformat cli
devices {
device PIOSXR-0 {
config {
cisco-ios-xr:segment-routing {
traffic-eng {
+ segment-list mysidlist {
+ index 1 {
+ mpls {
+ label 17001;
+ }
+ }
+ index 2 {
+ mpls {
+ label 18001;
+ }
+ }
+ }
policy SR-CLI-DYNAMIC {
color {
end-point {
- ipv4 127.0.0.1;
+ ipv4 1.1.1.1;
}
}
candidate-paths {
+ preference 200 {
+ explicit {
+ segment-list mysidlist {
+ weight 10;
+ }
+ }
+ }
}
}
}
}
}
}
}
7.3.3 SR-Settings
device level.
get-modifications action for a service
admin@ncs% request sr-setting SETTING-1 action get-modifications
outformat cli
message devices {
device PIOSXR-0 {
config {
+ cisco-ios-xr:segment-routing {

+ traffic-eng {
+ interface GigabitEthernet5 {
+ affinity {
+ color GREEN;
+ }
+ metric 2;
+ }
+ affinity-map {
+ color BLUE {
+ prefix name;
+ bit-position 1;
+ }
+ color GREEN {
+ prefix name;
+ bit-position 2;
+ }
+ color RED {
+ prefix name;
+ bit-position 0;
+ }
+ }
+ pcc {
+ source-address {
+ ipv4 192.168.2.1;
+ }
+ pce {
+ address {
+ ipv4 1.1.1.1 {
+ precedence 128;
+ }
+ ipv4 2.2.2.2 {
+ precedence 255;
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}
devices {
device PIOSXR-1 {
config {
+ traffic-eng {
+ affinity {
+ color BLUE;
+ }
+ metric 2;
+ }
+ affinity-map {
+ color BLUE {
+ prefix name;
+ bit-position 1;
+ }
+ color GREEN {
+ prefix name;

+ bit-position 2;
+ }
+ color RED {
+ prefix name;
+ bit-position 0;
+ }
+ }
+ }
+ }
}
}
}
get-modifications action for a device

device PIOSXR-0 outformat cli
message devices {
device PIOSXR-0 {
config {
+ traffic-eng {
+ affinity {
+ color GREEN;
+ }
+ metric 2;
+ }
+ affinity-map {
+ color BLUE {
+ prefix name;
+ bit-position 1;
+ }
+ color GREEN {
+ prefix name;
+ bit-position 2;
+ }
+ color RED {
+ prefix name;
+ bit-position 0;
+ }
+ }
+ pcc {
+ source-address {
+ ipv4 192.168.2.1;
+ }
+ pce {
+ address {
+ ipv4 1.1.1.1 {
+ precedence 128;
+ }
+ ipv4 2.2.2.2 {
+ precedence 255;
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}

7.3.4 SR-PCE
device level.
admin@ncs% request sr-pce PCE-0 action get-modifications outformat cli
message devices {
device PIOSXR-0 {
config {
+ cisco-ios-xr:pce {
+ address {
+ ipv4 100.1.1.1;
+ }
+ disjoint-path {
+ group-id 60000 srlg {
+ sub-id 1;
+ strict;
+ lsp 1 {
+ pcc {
+ ipv4 2.2.2.2;
+ }
+ lsp-name LSP-NAME;
+ shortest-path;
+ }
+ }
+ }
+ timers {
+ reoptimization 600;
+ keepalive 20;
+ minimum-peer-keepalive 21;
+ }
+ state-sync {
+ ipv4 3.3.3.3;
+ }
+ password {
+ type clear;
+ secret password123;
+ }
+ backoff {
+ ratio 11;
+ difference 10;
+ threshold 12;
+ }
+ segment-routing {
+ strict-sid-only;
+ te-latency;
+ }
+ }
}
}
}

Get-modifications action for a device

admin@ncs% request sr-pce PCE-0 action get-modifications device
PIOSXR-0 outformat cli
message devices {
device PIOSXR-0 {
config {
+ address {
+ ipv4 100.1.1.1;
+ }
+ disjoint-path {
+ group-id 60000 srlg {
+ sub-id 1;
+ strict;
+ lsp 1 {
+ pcc {
+ ipv4 2.2.2.2;
+ }
+ lsp-name LSP-NAME;
+ shortest-path;
+ }
+ }
+ }
+ timers {
+ keepalive 20;
+ }
+ state-sync {
+ ipv4 3.3.3.3;
+ }
+ password {
+ type clear;
+ secret password123;
+ }
+ backoff {
+ ratio 11;
+ difference 10;
+ threshold 12;
+ }
+ segment-routing {
+ strict-sid-only;
+ te-latency;
+ }
+ }
}
}
}


In L2VPN, perform the get-modifications action at the service/site level.
admin@ncs% request flat-L2vpn P2P-DOT1Q action get-modifications
outformat cli
message devices {
device PIOSXR-0 {
config {
cisco-ios-xr:interface {
+ HundredGigE 0/0/0/8 {
+ description "T-SDN Interface";
+ }
HundredGigE-subinterface {
+ HundredGigE 0/0/0/8.100 {
+ mode l2transport;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ rewrite {
+ ingress {
+ tag {
+ translate 1-to-1;
+ dot1q 123;
+ mode symmetric;
+ }
+ }
+ }
+ }
}
}
+ cisco-ios-xr:l2vpn {
+ pw-class P2P-DOT1Q {
+ encapsulation {
+ mpls {
+ }
+ }
+ }
+ xconnect {
+ group P2P-DOT1Q {
+ p2p P2P-DOT1Q {
+ interface HundredGigE0/0/0/8.100;
+ neighbor 14.0.0.0 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 101;
+ remote 202;
+ }
+ }
+ }
+ pw-class P2P-DOT1Q;
+ }
+ }
+ }

+ }
+ }
}
}
}
devices {
device PIOSXR-1 {
config {
+ }
+ mode l2transport;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ rewrite {
+ ingress {
+ tag {
+ translate 1-to-1;
+ dot1q 123;
+ mode symmetric;
+ }
+ }
+ }
+ }
}
}
+ encapsulation {
+ mpls {
+ }
+ }
+ }
+ xconnect {
+ group P2P-DOT1Q {
+ p2p P2P-DOT1Q {
+ neighbor 12.0.0.0 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 202;
+ remote 101;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}

get-modifications action for a remote-site

outformat cli site-type remote
message devices {
device PIOSXR-1 {
config {
+ }
+ mode l2transport;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ rewrite {
+ ingress {
+ tag {
+ translate 1-to-1;
+ dot1q 123;
+ mode symmetric;
+ }
+ }
+ }
+ }
}
}
+ encapsulation {
+ mpls {
+ }
+ }
+ }
+ xconnect {
+ group P2P-DOT1Q {
+ p2p P2P-DOT1Q {
+ neighbor 12.0.0.0 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 202;
+ remote 101;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}

get-modifications action for a local-site

outformat cli site-type local
message devices {
device PIOSXR-0 {
config {
+ }
+ mode l2transport;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ rewrite {
+ ingress {
+ tag {
+ translate 1-to-1;
+ dot1q 123;
+ mode symmetric;
+ }
+ }
+ }
+ }
}
}
+ encapsulation {
+ mpls {
+ }
+ }
+ }
+ xconnect {
+ group P2P-DOT1Q {
+ p2p P2P-DOT1Q {
+ neighbor 14.0.0.0 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 101;
+ remote 202;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}


In L3VPN, perform the get-modifications action at the service level or at the
endpoint level.
admin@ncs% request flat-L3vpn L3 action get-modifications outformat
cli
message devices {
device P-0 {
config {
ifmgr-cfg:interface-configurations {
+ interface-configuration act Loopback3 {
+ interface-virtual;
+ vrf L3VPN;
+ ipv4-network {
+ addresses {
+ primary {
+ address 169.1.1.1;
+ netmask 255.255.255.255;
+ }
+ }
+ }
+ }
}
infra-rsi-cfg:vrfs {
+ vrf L3VPN {
+ create;
+ afs {
+ af ipv4 unicast default {
+ create;
+ bgp {
+ import-route-targets {
+ route-targets {
+ route-target as {
+ as-or-four-byte-as 0 100
102 0;
100 0;
+ }
+ }
+ }
+ export-route-targets {
+ route-targets {
+ route-target as {
101 0;
100 0;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
ipv4-bgp-cfg:bgp {
+ instance default {

+ instance-as 0 {
+ four-byte-as 65001 {
+ vrfs {
+ vrf L3VPN {
+ vrf-global {
+ route-distinguisher {
+ type as;
+ as-xx 0;
+ as 1;
+ as-index 2;
+ }
+ vrf-global-afs {
+ vrf-global-af ipv4-
unicast {
+ enable;
+ }
+ }
+ exists;
+ }
+ vrf-neighbors {
+ vrf-neighbor 169.1.1.2 {
+ vrf-neighbor-afs {
+ vrf-neighbor-af ipv4-
unicast {
+ activate;
+ route-policy-in
PASS_ALL;
+ route-policy-out
PASS_ALL;
+ }
+ }
+ remote-as {
+ as-xx 0;
+ as-yy 65002;
+ }
+ }
+ }
+ }
+ }
+ bgp-running;
+ }
+ }
+ }
}
policy-repository-cfg:routing-policy {
route-policies {
+ route-policy PASS_ALL {
+ rpl-route-policy "route-policy PASS_ALL\n
pass\n end-policy\n ";
+ }
}
}
}
}
}
devices {
device P-1 {
config {

+ vrf L3VPN;
+ ipv4-network {
+ addresses {
+ primary {
+ address 169.1.1.1;
+ netmask 255.255.255.255;
+ }
+ }
+ }
+ }
}
+ vrf L3VPN {
+ create;
+ afs {
+ create;
+ bgp {
+ route-targets {
+ route-target as {
102 0;
100 0;
+ }
+ }
+ }
+ route-targets {
+ route-target as {
101 0;
100 0;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
ipv4-bgp-cfg:bgp {
+ instance-as 0 {
+ vrfs {
+ vrf L3VPN {
+ vrf-global {
+ type as;
+ as-xx 0;
+ as 1;
+ as-index 2;
+ }
+ vrf-global-afs {
unicast {
+ enable;
+ }

+ }
+ exists;
+ }
+ vrf-neighbors {
unicast {
+ activate;
+ route-policy-in
PASS_ALL;
+ route-policy-out
PASS_ALL;
+ }
+ }
+ remote-as {
+ as-xx 0;
+ as-yy 65002;
+ }
+ }
+ }
+ }
+ }
+ bgp-running;
+ }
+ }
+ }
}
route-policies {
+ }
}
}
}
}
}
get-modifications action for an endpoint

admin@ncs% request flat-L3vpn L3 action get-modifications endpoint nc-
0 outformat cli
message devices {
device P-0 {
config {
+ vrf L3VPN;
+ ipv4-network {
+ addresses {
+ primary {
+ address 169.1.1.1;
+ netmask 255.255.255.255;
+ }
+ }
+ }
+ }

}
+ vrf L3VPN {
+ create;
+ afs {
+ create;
+ bgp {
+ route-targets {
+ route-target as {
102 0;
100 0;
+ }
+ }
+ }
+ route-targets {
+ route-target as {
101 0;
100 0;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
ipv4-bgp-cfg:bgp {
+ instance-as 0 {
+ vrfs {
+ vrf L3VPN {
+ vrf-global {
+ type as;
+ as-xx 0;
+ as 1;
+ as-index 2;
+ }
+ vrf-global-afs {
unicast {
+ enable;
+ }
+ }
+ exists;
+ }
+ vrf-neighbors {
unicast {
+ activate;

+ route-policy-in
PASS_ALL;
+ route-policy-out
PASS_ALL;
+ }
+ }
+ remote-as {
+ as-xx 0;
+ as-yy 65002;
+ }
+ }
+ }
+ }
+ }
+ bgp-running;
+ }
+ }
+ }
}
route-policies {
+ }
}
}
}
}
}

0 outformat cli
message devices {
device P-0 {
config {
+ vrf L3VPN;
+ ipv4-network {
+ addresses {
+ primary {
+ address 169.1.1.1;
+ netmask 255.255.255.255;
+ }
+ }
+ }
+ }
}
+ vrf L3VPN {
+ create;
+ afs {
+ create;
+ bgp {

+ route-targets {
+ route-target as {
102 0;
100 0;
+ }
+ }
+ }
+ route-targets {
+ route-target as {
101 0;
100 0;
+ }
+ }
+ }
+ }
+ }
+ }
+ }
}
ipv4-bgp-cfg:bgp {
+ instance-as 0 {
+ vrfs {
+ vrf L3VPN {
+ vrf-global {
+ type as;
+ as-xx 0;
+ as 1;
+ as-index 2;
+ }
+ vrf-global-afs {
unicast {
+ enable;
+ }
+ }
+ exists;
+ }
+ vrf-neighbors {
unicast {
+ activate;
+ route-policy-in
PASS_ALL;
+ route-policy-out
PASS_ALL;
+ }
+ }
+ remote-as {
+ as-xx 0;
+ as-yy 65002;
+ }
+ }
+ }

+ }
+ }
+ bgp-running;
+ }
+ }
+ }
}
route-policies {
+ }
}
}
}
}
}
7.4 Service Redeploy Action

Use the service redeploy action to re-run the service when a device comes
back up after going down during the inital service creation. Use this action to
enable redeploying a service, a device, a site, or an endpoint.
Redeploying a service redeploys all the devices/sites/endpoints in the service.
Redeploying a device/site/endpoint redeploys the service only on the
requested device/site/endpoint.
When the device is not-reachable and the plan fails, run the redeploy action
for a specific device to push the configuration again when the device is up.
7.4.1 SR-ODN
Redeploying a service redeploys all the devices in the service. Redeploying a
device redeploys the service only on the requested device. When the device is
not-reachable and the plan fails, run the redeploy action for a specific device
to push the configuration again when the device is up.
Redeploying at service level

The following command shows how to redeploy a service.
ODN action redeploy
status SUCCESS
message Service Redeployed.
View the plan and observe the timestamp to verify the service redeployment.

POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------------
reached 2020-04-22T21:26:01 - -
ready
reached 2020-04-22T21:33:38 - -
reached 2020-04-22T21:26:01 - -
cisco-
ready
reached 2020-04-22T21:33:38 - -
reached 2020-04-22T21:26:01 - -
cisco-
ready
reached 2020-04-22T21:33:38 - -
Redeploying service for a given device

The following command redeploys a device in a service.
ODN head-end P-0 action redeploy
status SUCCESS
View the plan and observe the timestamp to verify the device redeployment.
POST
BACK STATUS
ACTION
------------------------------------------------------------------------------------------
reached 2020-04-22T21:26:01 - -
ready
reached 2020-04-22T21:34:46 - -
reached 2020-04-22T21:26:01 - -
cisco-
ready
reached 2020-04-22T21:34:46 - -
reached 2020-04-22T21:26:01 - -
cisco-
ready
reached 2020-04-22T21:33:38 - -
7.4.2 SR-Policy
SR-CLI-DYNAMIC action redeploy
status SUCCESS

admin@ncs% run show sr-te cisco-sr-te-cfp-sr-policies:policies policy-
plan
POST
BACK
ACTION
----------------------------------------------------------------------
reached 2020-02-11T22:30:16 - -
ready
reached 2020-02-11T22:31:52 - -
head-end PIOSXR-0 false - init
reached 2020-02-11T22:30:16 - -
cisco-sr-te-cfp-sr-policies-nano-plan-services:config-
apply reached 2020-02-11T22:31:22 - -
ready
reached 2020-02-11T22:31:52 - -
7.4.3 SR-Settings
admin@ncs% request sr-setting SETTING-1 action redeploy
status SUCCESS
POST
BACK STATUS
ACTION
----------------------------------------------------------------------
reached 2020-04-22T22:41:07 - -
ready
reached 2020-04-22T22:47:10 - -
reached 2020-04-22T22:41:07 - -
cisco-sr-
ready
reached 2020-04-22T22:47:10 - -
reached 2020-04-22T22:41:07 - -
cisco-sr-
ready
reached 2020-04-22T22:47:10 - -

admin@ncs% request sr-setting SETTING-1 node PIOSXR-0 action redeploy
status SUCCESS


POST
BACK STATUS
ACTION
----------------------------------------------------------------------
reached 2020-04-22T22:41:07 - -
ready
reached 2020-04-22T22:48:25 - -
reached 2020-04-22T22:41:07 - -
cisco-sr-
ready
reached 2020-04-22T22:48:25 - -
reached 2020-04-22T22:41:07 - -
cisco-sr-
ready
reached 2020-04-22T22:47:10 - -
7.4.4 SR-PCE
admin@ncs% request sr-pce PCE-0 action redeploy
status SUCCESS
admin@ncs% run show sr-pce-plan PCE-0 plan component
POST
BACK STATUS
ACTION
----------------------------------------------------------------------
reached 2020-04-22T17:50:05 - -
ready
reached 2020-04-22T17:59:46 - -
reached 2020-04-22T17:50:05 - -
cisco-sr-te-
ready
reached 2020-04-22T17:59:46 - -

admin@ncs% request sr-pce PCE-0 node PIOSXR-0 action redeploy
status SUCCESS
admin@ncs% run show sr-pce-plan PCE-0 plan component
POST

BACK STATUS
ACTION
----------------------------------------------------------------------
reached 2020-04-22T17:50:05 - -
ready
reached 2020-04-22T18:04:02 - -
reached 2020-04-22T17:50:05 - -
cisco-sr-te-
ready
reached 2020-04-22T18:04:02 - -

In L2VPN, the service redeploy action enables service/site redeployment. The
following custom actions enable service / site redeployment.
Redeploying services redeploys all the sites in the service.
Redeploying sites redeploys only the requested sites in the service. When the
site is not-reachable and the plan fails, run the redeploy action to push the
configuration again when the site is Up.

The following command shows how to redeploy a service on all the sites.
admin@ncs% request flat-L2vpn L2vpn01 action redeploy
status SUCCESS
View the plan to verify the service redeployment.

BACK
POST ACTION
------------------------------------------------------------------------------------------
reached 2020-02-11T22:10:06 - -
ready
reached 2020-02-11T22:12:43 - -
local-site PIOSXR-0 false - init
reached 2020-02-11T22:10:06 - -
cisco-
flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-02-11T22:12:11 - -
ready
reached 2020-02-11T22:12:11 - -
remote-site PIOSXR-1 false - init
reached 2020-02-11T22:10:06 - -
cisco-
ready
reached 2020-02-11T22:12:11 - -

To redeploy a local site/remote site:

admin@ncs% request flat-L2vpn L2vpn01 flat-L2vpn-p2p local-site action
redeploy
status SUCCESS
admin@ncs% request flat-L2vpn L2vpn01 flat-L2vpn-p2p remote-site

action redeploy
status SUCCESS
View the plan to verify the site redeployment. The following displays a plan
for a local-site redeployment.
BACK
POST ACTION
------------------------------------------------------------------------------------------
reached 2020-02-11T22:10:06 - -
ready
reached 2020-02-11T22:20:01 - -
local-site PIOSXR-0 false - init
reached 2020-02-11T22:10:06 - -
cisco-
ready
reached 2020-02-11T22:19:29 - -
remote-site PIOSXR-1 false - init
reached 2020-02-11T22:10:06 - -
cisco-
ready
reached 2020-02-11T22:12:11 - -

In L3VPN, the service redeploy action enables service/endpoint redeployment.
Redeploying services redeploys or reconfigures all the endpoints in the
service. Redeploying endpoints redeploys only the requested endpoints in the
service. When the service is not-reachable and the plan fails, run the redeploy
action to push the configuration again when the service is up.

The following command shows how to redeploy a requested service.
admin@ncs% request flat-L3vpn L3 action redeploy
status SUCCESS
View the plan to verify the endpoint redeployment. The following displays a
plan for an endpoint redeployment.


BACK
POST ACTION
------------------------------------------------------------------------------------------
reached 2020-02-20T02:40:26 - -
ready
reached 2020-02-20T02:45:14 - -
endpoint nc-0 false - init
reached 2020-02-20T02:40:26 - -
cisco-
ready
reached 2020-02-20T02:45:13 - -
reached 2020-02-20T02:40:26 - -
cisco-
ready
reached 2020-02-20T02:40:28 - -
Redeploying service for a given endpoint

The following command shows how to redeploy an endpoint in a service.
admin@ncs% request flat-L3vpn L3 endpoint nc-0 action redeploy
status SUCCESS
View the plan to verify the service redeployment.

BACK
POST ACTION
------------------------------------------------------------------------------------------
reached 2020-02-21T00:36:11 - -
ready
reached 2020-02-21T02:18:25 - -
reached 2020-02-21T00:36:11 - -
cisco-
ready
reached 2020-02-21T02:18:23 - -
reached 2020-02-21T00:36:11 - -
cisco-
ready
reached 2020-02-21T02:17:55 - -

Using Custom-Templates Page 78
8 Using Custom-Templates
You can configure the devices directly by using custom-templates. With
custom-templates, you can also apply additional configurations that are not
supported by SR-TE CFP.
To use this feature, the apply-custom-template flag must be set to true. By
default, this flag is set to true. The plan for the service displays the status of
the custom-templates.
You can also turn this feature on/off. For more information on turning this flag
on/off, see section Turning Custom-Templates On/Off in this chapter.
While installing the CFP packages, the installer extracts and saves the custom-
templates-utils package in the /var/opt/ncs/packages directory.
If the custom-templates-utils package is not saved in the
/var/opt/ncs/packages directory, do the following:
1. Download the ncs-5.2.1-custom-template-utils-1.2.0-e5f4603.tar.gz file from
Cisco website.
2. Copy the file to the /var/opt/ncs/packages directory and extract the file.
3. Load the custom-templates packages to ncs in any of the following ways as
required.
a. If ncs is stopped, start ncs with the package reload option.
b. If ncs is running, execute request packages reload in ncs_cli.
Custom-templates must adhere to a naming convention. The custom-
templates name must start with either ct- or CT-. The device name variable in
configuration templates must be either DEVICE_NAME or DEVICE. These
variable names are reserved only for the device name in templates and hence
must not be used for anything else in a template.
For sample custom-templates for each service, see section Custom-Template
Payloads in this documentation.
8.1 Turning Custom-Templates On/Off

You can turn the custom-templates feature on/off at any time and custom
redeploy the service for the change to take effect.
To turn off the custom-template feature:
Set the apply-custom-template flag to false to turn off the custom-template
feature. The default value is true.
admin@ncs% set apply-custom-template false
commit

Supporting Multi-Vendor Services Page 79
9 Supporting Multi-Vendor Services

SR-TE CFP is an extendable CFP, which allows you to write your own extension
package and hook it to the CFP. This allows you to map the CFP service models
to device configurations for the NED packages and/or the device versions not
supported by CFP. This concept of Multi-Vendor Support Services (MVSS) thus
allows you to provide services to the devices or NED packages you already
have.
For more information, contact your Cisco representative.

Deleting Services Page 80
10 Deleting Services
You may want to delete a service when the devices in the service are down or
when there is policy discrepancies. Use the following commands to delete the
services.
SR-ODN
delete sr-te cisco-sr-te-cfp-sr-odn:odn odn-template <service-name>
SR-Policy
delete sr-te cisco-sr-te-cfp-sr-policies:policies policy <service-
name>
SR-Settings
delete sr-setting <service-name>
SR-PCE
delete sr-pce <service-name>
L2VPN
delete flat-L2vpn <service-name>
L3VPN
delete flat-L3vpn <service-name>

Notifications Page 81
11 Notifications
SR-TE CFP generates the following notifications that communicate important
information about the various events. Use this information to modify and
examine the payload content for a specific event.
11.1 SR-ODN Notifications

This topic includes the create and delete notifications for the SR-ODN service.
Create Notification
notification {
eventTime 2020-04-24T17:26:51.198717+00:00
plan-state-change {
service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-
template[name='SR-ODN']
component PIOSXR-0
state cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T17:26:51.198761+00:00
plan-state-change {
component PIOSXR-0
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T17:26:54.428729+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T17:26:54.428848+00:00
plan-state-change {
component P-0
operation modified
status reached
}
}

notification {
eventTime 2020-04-24T17:26:54.428909+00:00
plan-state-change {
component P-0
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T17:26:54.429021+00:00
plan-state-change {
component PIOSXR-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T17:26:54.429094+00:00
plan-state-change {
component PIOSXR-0
state ready
operation modified
status reached
}
}
Delete Notifications
notification {
eventTime 2020-04-24T17:27:58.800174+00:00
plan-state-change {
operation deleted
}
}
The following notification displays if the delete operation fails.

notification {
eventTime 2020-04-24T17:28:47.18566+00:00
plan-state-change {
operation deleted
status failed
}
}

11.2 SR-Policies Notifications

This topic includes the create and delete notifications for SR-policies.
11.2.1 SR-TE Policy with Static Explicit Route Object

Create Notification
notification {
eventTime 2020-04-26T20:25:10.00268+00:00
plan-state-change {
service /sr-te/cisco-sr-te-cfp-sr-
policies:policies/policy[name='SR-CLI-DYNAMIC']
component self
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-26T20:25:10.002815+00:00
plan-state-change {
component PIOSXR-0
state init
operation created
status reached
}
}
notification {
eventTime 2020-04-26T20:25:10.00292+00:00
plan-state-change {
component PIOSXR-0
state cisco-sr-te-cfp-sr-policies-nano-plan-services:config-
apply
operation created
status not-reached
}
}
notification {
eventTime 2020-04-26T20:25:10.002985+00:00
plan-state-change {
component PIOSXR-0
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-26T20:25:12.262296+00:00
plan-state-change {
component self

state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-26T20:25:12.262427+00:00
plan-state-change {
component PIOSXR-0
state cisco-sr-te-cfp-sr-policies-nano-plan-services:config-
apply
operation modified
status reached
}
}
notification {
eventTime 2020-04-26T20:25:12.262501+00:00
plan-state-change {
component PIOSXR-0
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-26T13:27:18.478531+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-26T13:28:04.550181+00:00
plan-state-change {
operation deleted
status failed
}
}

11.3 SR-Settings Notifications

This topic includes the create and delete notifications for SR-Settings and
SR-Flex Algo.
11.3.1 SR-Settings Notifications

Create Notification
notification {
eventTime 2020-04-24T22:23:49.485567+00:00
plan-state-change {
service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1']
component P-1
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T22:23:49.485695+00:00
plan-state-change {
component PIOSXR-0
state init
operation created
status reached
}
}
notification {
eventTime 2020-04-24T22:23:49.485746+00:00
plan-state-change {
component PIOSXR-0
state cisco-sr-te-settings-fp-nano-plan-services:config-apply
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T22:23:49.48579+00:00
plan-state-change {
component PIOSXR-0
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T22:23:49.485919+00:00
plan-state-change {
component PIOSXR-1
state init
operation created
status reached
}

}
notification {
eventTime 2020-04-24T22:23:49.485967+00:00
plan-state-change {
component PIOSXR-1
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T22:23:49.486011+00:00
plan-state-change {
component PIOSXR-1
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T15:24:31.965713+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T15:29:06.636872+00:00
plan-state-change {
operation deleted
status failed
}
}

11.3.2 SR Flex Algo Notifications

This topic includes notifications for SR Flex Algo create and delete operations.
Create Notification
notification {
eventTime 2020-04-24T20:57:47.97983+00:00
plan-state-change {
service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1']
component self
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T20:57:47.979971+00:00
plan-state-change {
component PIOSXR-0
state init
operation created
status reached
}
}
notification {
eventTime 2020-04-24T20:57:47.980017+00:00
plan-state-change {
component PIOSXR-0
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T20:57:47.98006+00:00
plan-state-change {
component PIOSXR-0
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T20:57:50.587655+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T20:57:50.587769+00:00
plan-state-change {
component PIOSXR-0

operation modified
status reached
}
}
notification {
eventTime 2020-04-24T20:57:50.587842+00:00
plan-state-change {
component PIOSXR-0
state ready
notification {
eventTime 2020-04-24T20:59:56.64972+00:00
plan-state-change {
operation deleted
}
}
11.4 SR-PCE Notifications

This section includes the create and delete notifications for SR-PCE.
Create Notification
notification {
eventTime 2020-04-27T23:13:43.877658+00:00
plan-state-change {
service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0']
component self
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-27T23:13:43.877775+00:00
plan-state-change {
component P-0
state init
operation created
status reached
}
}
notification {
eventTime 2020-04-27T23:13:43.877816+00:00
plan-state-change {
component P-0
state cisco-sr-te-pce-fp-nano-plan-services:config-apply
operation created
status not-reached
}
}
notification {

eventTime 2020-04-27T23:13:43.877877+00:00
plan-state-change {
component P-0
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-27T23:13:45.198269+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-27T23:13:45.19838+00:00
plan-state-change {
component P-0
state cisco-sr-te-pce-fp-nano-plan-services:config-apply
operation modified
status reached
}
}
notification {
eventTime 2020-04-27T23:13:45.198445+00:00
plan-state-change {
component P-0
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-27T16:17:18.761193+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-27T16:19:55.017591+00:00
plan-state-change {
operation deleted
status failed
}
}

11.5 Flat L2VPN Example Notifications

This topic includes the create and delete notifications for L2VPN P2P, and
L2VPN VPWS.
11.5.1 Flat L2VPN P2P Notifications

This topic discusses the notifications for the create and delete operations for
L2VPN P2P.
Create Notification
notification {
eventTime 2020-04-24T18:46:03.713054+00:00
plan-state-change {
service /flat-L2vpn[name='L2vpn01-nc']
component P-1
state cisco-flat-L2vpn-fp-nano-plan-services:config-apply
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T18:46:03.7131+00:00
plan-state-change {
component P-1
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T18:46:07.027717+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T18:46:07.027856+00:00
plan-state-change {
component P-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T18:46:07.027971+00:00
plan-state-change {

component P-0
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T18:46:07.028137+00:00
plan-state-change {
component P-1
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T18:46:07.028216+00:00
plan-state-change {
component P-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T11:48:54.258083+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T11:52:25.590248+00:00
plan-state-change {
operation deleted
status failed
}
}

11.5.2 Flat L2VPN VPWS Notifications

L2VPN VPWS.
Create Notification
notification {
eventTime 2020-04-24T19:04:38.620857+00:00
plan-state-change {
service /flat-L2vpn[name='L2vpn-dynamic-02-nc']
component P-1
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T19:04:38.620913+00:00
plan-state-change {
component P-1
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T19:04:40.766288+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:04:40.766411+00:00
plan-state-change {
component P-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:04:40.766538+00:00
plan-state-change {
component P-0
state ready
operation modified
status reached
}
}
notification {

eventTime 2020-04-24T19:04:40.76666+00:00
plan-state-change {
component P-1
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:04:40.766727+00:00
plan-state-change {
component P-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T12:16:07.883587+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T12:07:52.33263+00:00
plan-state-change {
operation deleted
status failed
}
}

11.5.3 L2VPN SR-TE – Preferred Path Notifications

L2VPN SR-TE – preferred path.
Create Notification
notification {
eventTime 2020-04-24T19:17:23.181496+00:00
plan-state-change {
component P-1
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T19:17:23.181557+00:00
plan-state-change {
component P-1
state ready
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T19:17:24.918581+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:17:24.918739+00:00
plan-state-change {
component P-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:17:24.918823+00:00
plan-state-change {
component P-0
state ready
operation modified
status reached

}
}
notification {
eventTime 2020-04-24T19:17:24.918995+00:00
plan-state-change {
component P-1
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:17:24.919065+00:00
plan-state-change {
component P-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T12:18:30.345774+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T12:19:22.056673+00:00
plan-state-change {
operation deleted
status failed
}
}

11.5.4 L2VPN SR-TE – ODN

L2VPN SR-TE – ODN.
Create Notification
notification {
eventTime 2020-04-24T19:46:34.412326+00:00
plan-state-change {
component P-1
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T19:46:34.412384+00:00
plan-state-change {
component P-1
state ready
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T19:46:36.2144+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:46:36.214512+00:00
plan-state-change {
component P-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:46:36.214574+00:00
plan-state-change {
component P-0
state ready
operation modified
status reached

}
}
notification {
eventTime 2020-04-24T19:46:36.214668+00:00
plan-state-change {
component P-1
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:46:36.21472+00:00
plan-state-change {
component P-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T12:47:30.237791+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T12:48:54.139273+00:00
plan-state-change {
operation deleted
status failed
}
}

11.6 Flat L3VPN Example Notifications

This topic includes the create and delete notifications for L3VPN service.
11.6.1 Flat L3VPN Notifications

Create Notification
notification {
eventTime 2020-04-24T19:53:26.07081+00:00
plan-state-change {
service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3']
component nc-1
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T19:53:26.070852+00:00
plan-state-change {
component nc-1
state ready
operation created
status not-reached
}
}
notification {
eventTime 2020-04-24T19:53:28.989988+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:53:28.990111+00:00
plan-state-change {
component nc-0
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:53:28.990186+00:00
plan-state-change {
component nc-0
state ready
operation modified
status reached
}
}

notification {
eventTime 2020-04-24T19:53:28.990296+00:00
plan-state-change {
component nc-1
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T19:53:28.99036+00:00
plan-state-change {
component nc-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T15:05:57.4621+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T15:06:55.885785+00:00
plan-state-change {
operation deleted
status failed
}
}

11.6.2 Flat -L3VPN SR TE Color

Create SR-TE Tunnel-Static
notification {
eventTime 2020-04-24T22:13:36.980087+00:00
plan-state-change {
component nc-1
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T22:13:38.95747+00:00
plan-state-change {
component self
state ready
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T22:13:38.957614+00:00
plan-state-change {
component nc-0
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T22:13:38.957685+00:00
plan-state-change {
component nc-0
state ready
operation modified
status not-reached
}
}
notification {
eventTime 2020-04-24T22:13:40.075873+00:00
plan-state-change {
component self
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T22:13:40.075993+00:00
plan-state-change {
component nc-0
operation modified

status reached
}
}
notification {
eventTime 2020-04-24T22:13:40.076062+00:00
plan-state-change {
component nc-0
state ready
operation modified
status reached
}
}
notification {
eventTime 2020-04-24T15:15:13.831081+00:00
plan-state-change {
operation deleted
}
}

notification {
eventTime 2020-04-24T15:15:49.773008+00:00
plan-state-change {
operation deleted
status failed
}
}

Handling Zombies Page 102
12 Handling Zombies
Zombies are the internal operational data model in NSO to store deleted
service data. Zombies are helpful when performing staged deletions and RFM.
RFM is the NSO version of eventual consistency.
When a service deletion is triggered, NSO maintains references of the deleted
services (zombies) in operational data. The zombies are deleted from CDB
when all the configurations for the service are removed from the devices.
Zombies inform the Northbound the progress of a service deletion. It also
informs the stage it is waiting on, which helps to point to the problematic
area. For more information on nano-services and zombies, see NSO Developer
Guide.
In T-SDN FPs, you trigger a deletion to clean up the configuration on all the
endpoints/nodes in a service. However, depending on the number of nodes or
endpoints in a service, deleting the configuration at once may lock down the
database until the time the slowest device removes the configuration. It is,
therefore, recommended to delete the configurations in separate
transactions, such as per device.
Once the configuration is successfully removed from all the devices in the
service, continue to update the plan state to communicate the progress of
deletion to Nortbound. When the last device configuration is removed,
remove the plan, zombies, and all the service-related operational data from
CDB.
Sometimes, zombies are not deleted in the following scenarios even after
deleting the last device configuration. Some failures may require manual
intervention to delete configuration references from the devices. In such
cases, run the Cleanup action on the device and then run the service cleanup
action on T-SDN FPs. For more information on the Cleanup actions, see
chapter Working with Action Commands in this documentation.
1. Device is not reachable during deletion.
2. Device is reachable, but the configuration removal fails on the device for
other reasons.
To recreate a service with the same name as a deleted service, wait for the
service plan to be deleted. If the Northbound system tries to recreate the
service instance before the zombie/delete is fully processed, the following
error displays, which indicates the deletion process is still in progress.
"Aborted: Operation failed because: Service still in zombie state: 'YYY'".
Note: T-SDN FPs do not support zombie resurrect and redeploy options.

Handling Zombies Page 103
The following are some sample zombies for the SR-ODN service.
admin@ncs% run show zombies
::::::::::::::::::::::::::::INTERNAL ZOMBIE::::::::::::::::::::::::::::
zombies service /sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template[name='SR-
ODN'][head-end='PIOSXR-0']
delete-path /sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template[name='SR-ODN'][head-
end='PIOSXR-0']
POST
BACK
ACTION
TYPE NAME TRACK GOAL STATE STATUS
WHEN ref STATUS
-------------------------------------------------------------------------------
self self true - init reached -
- -
cisco-sr-te-cfp-sr-odn-nano-services:config-apply reached -
- -
ready not-reached -
- -
plan failed
plan error-info message "Failed to connect to device PIOSXR-0: connection refused: NEDCOM
CONNECT: Connection refused (Connection refused) in new state"
plan error-info log-entry "/zombies/service[service-path=\"/sr-te/cisco-sr-te-cfp-sr-odn-
internal:odn/odn-template[name='SR-ODN'][head-end='PIOSXR-0']\"]/log/log-entry[when='2020-
03-26T23:34:12.992768+00:00']"
WHEN TYPE LEVEL MESSAGE
-------------------------------------------------------------------------------
2020-03-26T23:34:12.992768+00:00 service-modified error Failed to connect to device
PIOSXR-0: connection refused: NEDCOM CONNECT: Connection refused (Connection refused) in
new state
::::::::::::::::::::::::::::EXTERNAL ZOMBIE::::::::::::::::::::::::::::
zombies service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN']
delete-path /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN']
POST
BACK
ACTION
-------------------------------------------------------------------------------
self self true - init
not-reached - - -
ready
not-reached - - -
cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 true - init
reached - - -
cisco-sr-te-
cfp-sr-odn-nano-plan-services:config-apply failed - - -
ready
not-reached - - -
plan failed

Appendix A: Package Categories and Packages Page 104
13 Appendix A: Package Categories and Packages

This section provides the list of packages that are extracted during the T-SDN
FP Bundle installation. Different packages from this list are used to install the
T-SDN FPs. For more information on how to extract and copy these packages,
see the Cisco NSO Transport SDN Function Pack Bundle Installation Guide.
Group Package Category Packages

SR-TE CFP Packages ncs-5.2.2-cisco-sr-te-cfp-
1.0.0.tar.gz
ncs-5.2.1-core-fp-plan-notif-
Core Function Pack generator-1.0.0.tar.gz
Packages T-SDN FP Common ncs-5.2.1-custom-template-
Packages utils-2.0.0.tar.gz
ncs-5.2.1-core-fp-common-
1.8.0.tar.gz
NEDs CLI NED ncs-5.2.2-cisco-iosxr-
7.24.tar.gz
L2VPN Example Package ncs-5.2.2-cisco-flat-L2vpn-fp-
EXAMPLE-1.0.0.tar.gz
L3VPN Example Package ncs-5.2.2-cisco-flat-L3vpn-fp-
EXAMPLE-1.0.0.tar.gz
SR-Settings Example ncs-5.2.2-cisco-sr-te-settings-
Package fp-EXAMPLE-1.0.0.tar.gz
Example Packages SR-PCE Example ncs-5.2.2-cisco-sr-te-pce-fp-
Package EXAMPLE-1.0.0.tar.gz
Resource Manager for ncs-5.2.1-resource-manager-
SR-Settings 3.4.0.tar.gz
Shared Delete Handler ncs-5.2.2-core-fp-delete-tag-
Package for L2/L3 service-EXAMPLE-1.0.0.tar.gz
Interfaces

Appendix B - Yang Models Page 105
14 Appendix B - Yang Models

This topic contains the yang models for the SR-TE CFP services and the
example function packs.
14.1 Cisco SR-TE-CFP-ODN

module: cisco-sr-te-cfp-sr-odn
augment /cisco-sr-te-cfp:sr-te:
+--rw odn
+--rw odn-template* [name]
| +--rw name? cisco-sr-te-cfp-sr-
types:Cisco-ios-xr-string
| +--rw head-end* [name]
| | +--rw name? ->
/ncs:devices/device/name
| | +--rw action
| | +---x redeploy
| | +--ro output
| | +--ro status? string
| | +--ro message? string
| +--rw maximum-sid-depth? uint8
| +--rw color uint32
| +--rw bandwidth? uint32
| +--rw dynamic!
| | +--rw metric-type? enumeration
| | +--rw pce!
| | +--rw flex-alg? uint32
| | +--rw disjoint-path!
| | | +--rw type enumeration
| | | +--rw group-id uint16
| | | +--rw sub-id? uint16
| | +--rw affinity!
| | +--rw rule* [action]
| | +--rw action? enumeration
| | +--rw color* string
| +--rw action
| +---x redeploy
| | +--ro output
| +---x get-modifications
| +---w input
| | +---w device? -> ../../../head-end/name
| | +---w outformat? outformat2
| +--ro output
| +--ro message? string

14.2 Cisco SR-TE-CFP-POLICY
module: cisco-sr-te-cfp-sr-policies
module: cisco-sr-te-cfp-sr-policies
augment /cisco-sr-te-cfp:sr-te:
+--rw policies
+--rw policy* [name]
| +--rw name? cisco-sr-te-cfp-sr-
types:Cisco-ios-xr-string
| +--rw head-end* [name]
| | +--rw name? -> /ncs:devices/device/name
| +--rw tail-end inet:ip-address
| +--rw color uint32
| +--rw binding-sid? uint32
| +--rw path* [preference]
| | +--rw preference? uint16
| | +--rw (sr-te-path-choice)?
| | +--:(explicit-path)
| | | +--rw explicit!
| | | +--rw sid-list* [name]
| | | | +--rw name? -> /cisco-sr-te-cfp:sr-
te/cisco-sr-te-cfp-sr-policies:policies/sid-list/name
| | | | +--rw weight? uint32
| | | +--rw constraints
| | | +--rw disjoint-path!
| | | | +--rw type enumeration
| | | | +--rw group-id uint16
| | | | +--rw sub-id? uint16
| | | +--rw affinity!
| | | | +--rw rule* [action]
| | | | +--rw action? enumeration
| | | | +--rw color* string
| | | +--rw segments!
| | | +--rw sid-algorithm? uint16
| | +--:(dynamic-path)
| | +--rw dynamic!
| | +--rw metric-type? enumeration
| | +--rw pce!
| | +--rw constraints
| | +--rw sid-limit? uint32
| | +--rw disjoint-path!
| | | +--rw type enumeration
| | | +--rw group-id uint16
| | | +--rw sub-id? uint16
| | +--rw affinity!
| | | +--rw rule* [action]
| | | +--rw action? enumeration
| | | +--rw color* string
| | +--rw segments!
| | +--rw sid-algorithm? uint16

| +--rw bandwidth? uint32

| +--rw auto-route!
| | +--rw auto-route-metric!
| | | +--rw (metric-choice)?
| | | +--:(metric-relative-value)
| | | | +--rw metric-relative-value? int32
| | | +--:(metric-constant-value)
| | | +--rw metric-constant-value? uint32
| | +--rw include-prefixes!
| | | +--rw include-prefix* [prefix-address]
| | | +--rw prefix-address? tailf:ipv4-address-and-
prefix-length
| | +--rw force-sr-include? empty
| | +--rw forward-class? uint8
| +--rw action
| | +---x redeploy
| | | +--ro output
| | | +--ro status? string
| | | +--ro message? string
| | +---x get-modifications
| | +---w input
| | | +---w outformat? outformat2
| | +--ro output
+--rw sid-list* [name]
| +--rw name? cisco-sr-te-cfp-sr-types:Cisco-ios-xr-
string
| +--rw sid* [index]
| | +--rw index? uint32
| | +--rw (type)
| | +--:(mpls)
| | | +--rw mpls
| | | +--rw label uint32
| | +--:(ipv4)
| | +--rw ipv4
| | +--rw address inet:ipv4-address

14.3 SR-Setting Function Pack

module: cisco-sr-te-settings-fp
+--rw sr-setting* [name]
| +--rw name cisco-sr-te-settings-fp-sr-
types:service-name
| +--rw maximum-sid-depth? uint32
| +--rw affinity-map-te!
| | +--rw color* [name]
| | +--rw name string
| | +--rw bit-position uint8
| +--rw affinity-map-isis!
| | +--rw color* [name]
| | +--rw name string
| | +--rw bit-position uint16
| +--rw pcc!
| | +--rw pce!
| | | +--rw address!
| | | +--rw ipv4* [address]
| | | +--rw address inet:ipv4-address
| | | +--rw precedence? uint8
| | +--rw report-all? empty
| +--rw performance-measurement!
| | +--rw delay-measurement
| | +--rw advertise-delay? uint32
| +--rw srlg!
| | +--rw value* [index]
| | +--rw index uint32
| | +--rw value uint32
| | +--rw priority? enumeration
| +--rw igp-metric!
| | +--rw metric? union
| | +--rw metric-level!
| | +--rw metric* [level]
| | +--rw level uint8
| | +--rw value? union
| +--rw interface-igp-metric!
| +--rw sr-global-block!
| | +--rw (srgb-choice)?
| | +--:(inline)
| | | +--rw inline!
| | | +--rw start uint32
| | | +--rw end uint32
| | +--:(sr-pool)
| | +--rw sr-pool!

| | +--rw sr-pool-name -> /ralloc:resource-

pools/idalloc:id-pool/name
| +--rw slice!
| | +--rw flex-algo* [name]
| | | +--rw name uint32
| | | +--rw affinity-exclude-any* string
| | | +--rw metric-type? enumeration
| | | +--rw priority? uint32
| | | +--rw advertise-definition? empty
| | +--rw isis* [instance-name]
| | +--rw instance-name string
| | +--rw distribute? boolean
| | +--rw node* [name]
| | | +--rw name -> ../../../../node/name
| | | +--rw flex-algo* [name]
| | | | +--rw name -> ../../../../flex-
algo/name
| | | | +--rw algorithm-prefix-sid!
| | | | +--rw (algorithm-prefix-sid-choice)?
| | | | +--:(absolute)
| | | | | +--rw absolute uint32
| | | | +--:(index)
| | | | | +--rw index uint32
| | | | +--:(auto-assign-absolute)
| | | | | +--rw auto-assign-absolute empty
| | | | +--:(auto-assign-index)
| | | | +--rw auto-assign-index empty
| | | +--rw loopback* [id]
| | | +--rw id uint16
| | | +--rw flex-algo-enabled-flag? enumeration
| | | +--rw name -> ../../../flex-algo/name
| | +--rw address-family? enumeration
| | +--rw mpls-preference? enumeration
| | +--rw igp-metric!
| +--rw node* [name]
| | +--rw name -> /ncs:devices/device/name
| | | +--rw instance-name string
| | | +--rw distribute? boolean
| | | +--rw loopback* [id]
| | | | +--rw id uint16
| | | | +--rw prefix-sid!
| | | | | +--rw (prefix-sid-choice)?
| | | | | | +--:(absolute)
| | | | | | | +--rw absolute uint32

| | | | | | +--:(index)
| | | | | | | +--rw index uint32
| | | | | | +--:(auto-assign-absolute)
| | | | | | | +--rw auto-assign-absolute empty
| | | | | | +--:(auto-assign-index)
| | | | | | +--rw auto-assign-index empty
| | | | | +--rw n-flag-clear? empty
| | | | +--rw flex-algo* [name]
| | | | +--rw name -> ../../../flex-algo/name
| | | +--rw address-family? enumeration
| | | +--rw mpls-preference? enumeration
| | | +--rw igp-metric!
| | | | +--rw metric? union
| | | | +--rw metric-level!
| | | | +--rw metric* [level]
| | | | +--rw level uint8
| | | | +--rw value? union
| | | +--rw name uint32
| | | +--rw affinity-exclude-any* string
| | | +--rw metric-type? enumeration
| | | +--rw priority? uint32
| | | +--rw advertise-definition? empty
| | | +--rw algorithm-prefix-sid!
| | | +--rw (algorithm-prefix-sid-choice)?
| | | +--:(absolute)
| | | | +--rw absolute uint32
| | | +--:(index)
| | | | +--rw index uint32
| | | +--:(auto-assign-absolute)
| | | | +--rw auto-assign-absolute empty
| | | +--:(auto-assign-index)
| | | +--rw auto-assign-index empty
| | +--rw interface* [if-type if-id]
| | | +--rw if-type enumeration
| | | +--rw if-id string
| | | +--rw te!
| | | | +--rw affinity!
| | | | | +--rw color* [name]
| | | | | +--rw name -> ../../../../../../affinity-map-
te/color/name
| | | | +--rw metric? uint32
| | | +--rw isis!
| | | | +--rw instance-name string
| | | | +--rw affinity!
| | | | | +--rw color* [name]
| | | | | +--rw name -> ../../../../../../affinity-map-
isis/color/name
| | | | +--rw interface-igp-metric!
| | | | +--rw metric? union
| | | | +--rw metric-level!

| | | | +--rw metric* [level]

| | | | +--rw level uint8
| | | | +--rw value? union
| | | +--rw performance-measurement!
| | | | +--rw delay-measurement
| | | | +--rw advertise-delay? uint32
| | | +--rw srlg!
| | | +--rw value* [index]
| | | +--rw index uint32
| | | +--rw value uint32
| | | +--rw priority? enumeration
| | +--rw pcc!
| | | +--rw disable? empty
| | | +--rw source-address? inet:ipv4-address
| | +--rw action
| | | +---x redeploy
| | | +--ro output
| +--rw action
| | +---x redeploy
| | | +--ro output
| | +---w input
| | | +---w device? -> ../../../node/name
| | +--ro output
+--rw sr-setting-action
| +---x cleanup
| +---w input
| | +---w service string
| | +---w device? string
| | +---w no-networking? boolean
| +--ro output
| +--ro success boolean
| +--ro detail? string
+--rw cfp-configurations
+--rw sr-validation-enabled? boolean
+--rw local-user? string
+--rw auto-cleanup? boolean
+--rw dynamic-device-mapping* [ned-id]
| +--rw ned-id string
| +--rw python-impl-class-name string
+--rw stacked-service-enabled!

14.4 SR-PCE Function Pack

module: cisco-sr-te-pce-fp
+--rw sr-pce* [name]
| +--rw name cisco-sr-te-pce-fp-sr-
types:service-name
| +--rw node* [name]
| | +--rw name -> /ncs:devices/device/name
| | +--rw pce!
| | | +--rw address? inet:ipv4-address
| | | +--rw ipv6-address? inet:ipv6-address
| | | +--rw disjoint-path!
| | | | +--rw group-id* [id type]
| | | | +--rw id uint16
| | | | +--rw type enumeration
| | | | +--rw sub-id? uint16
| | | | +--rw strict? empty
| | | | +--rw lsp* [id]
| | | | +--rw id enumeration
| | | | +--rw pcc-address inet:ipv4-address
| | | | +--rw lsp-name string
| | | | +--rw shortest-path? empty
| | | +--rw timers!
| | | | +--rw reoptimization? uint32
| | | | +--rw keepalive? uint8
| | | | +--rw minimum-peer-keepalive? uint8
| | | +--rw state-sync!
| | | | +--rw ipv4* [address]
| | | | +--rw address inet:ipv4-address
| | | +--rw password
| | | | +--rw type? enumeration
| | | | +--rw secret? string
| | | +--rw backoff!
| | | | +--rw ratio? uint8
| | | | +--rw difference? uint8
| | | | +--rw threshold? uint16
| | | +--rw segment-routing!
| | | +--rw strict-sid-only? empty
| | | +--rw te-latency? empty
| | | +--rw instance-name string
| | | +--rw is-type? enumeration
| | | +--rw netid* [id]
| | | | +--rw id string
| | | +--rw ipv4!
| | | | +--rw metric-style? enumeration
| | | +--rw ipv6!
| | | | +--rw metric-style? enumeration
| | | +--rw interface* [if-type if-id]

| | | +--rw point-to-point? empty

| | +--rw bgp!
| | | +--rw name? string
| | | +--rw as-no as-no-type
| | | +--rw router-id? inet:ipv4-address
| | | +--rw ipv4!
| | | | +--rw table-policy? string
| | | +--rw ipv6!
| | | | +--rw table-policy? string
| | | +--rw link-state? empty
| | | +--rw neighbor-group* [name]
| | | | +--rw name string
| | | | +--rw link-state? empty
| | | | +--rw remote-as as-no-type
| | | | +--rw update-source!
| | | | +--rw if-type enumeration
| | | | +--rw if-id string
| | | +--rw neighbor* [id]
| | | +--rw id inet:ip-address
| | | +--rw neighbor-group -> ../../neighbor-group/name
| | +--rw action
| | | +--ro output
| +--rw action
| | +---x redeploy
| | | +--ro output
| | +---w input
| | | +---w device? -> ../../../node/name
| | +--ro output
+--rw sr-pce-action
| +---x cleanup
| +---w input
| | +---w service string
| | +---w device? string
| | +---w no-networking? boolean
| +--ro output
| +--ro success boolean
| +--ro detail? String

14.5 Flat-L2VPN Function Pack

module: cisco-flat-L2vpn-fp
+--rw l2vpn-route-policy* [name]
| +--rw name service-name
| +--rw color* [id]
| +--rw id uint32
| +--rw ipv4!
| | +--rw rd* asn-ip-type
| +--rw ipv6!
| +--rw rd* asn-ip-type
+--rw flat-L2vpn* [name]
| +--rw service-type enumeration
| +--rw flat-L2vpn-p2p
| | +--rw pw-id uint32
| | +--rw local-site
| | | +--rw pe -> /ncs:devices/device/name
| | | +--rw if-description? string
| | | +--rw if-encap l2-serv-encap-type
| | | +--rw vlan-id int32
| | | +--rw sub-if-id? int32
| | | +--rw rewrite!
| | | | +--rw ingress!
| | | | +--rw (tag-choice)?
| | | | | +--:(pop)
| | | | | | +--rw pop enumeration
| | | | | +--:(push)
| | | | | | +--rw push empty
| | | | | +--:(translate)
| | | | | +--rw translate enumeration
| | | | +--rw dot1q uint16
| | | | +--rw mode? enumeration
| | | +--rw mtu? uint16
| | | +--rw xconnect-group-name string
| | | +--rw xconnect-encapsulation? enumeration
| | | +--rw p2p-name string
| | | +--rw sr-te!
| | | | +--rw preferred-path!
| | | | +--rw policy string
| | | | +--rw fallback? enumeration
| | | +--rw control-word? enumeration
| | | +--rw pw-class string
| | | +--rw xconnect-local-ip? inet:ip-address
| | | +--rw xconnect-remote-ip? inet:ip-address
| | | +--rw mpls-local-label? uint32
| | | +--rw mpls-remote-label? uint32
| | | +--rw action
| | | +--ro output
| | +--rw remote-site!
| | +--rw pe -> /ncs:devices/device/name

| | +--rw if-type enumeration

| | +--rw if-id string
| | +--rw if-description? string
| | +--rw if-encap l2-serv-encap-type
| | +--rw vlan-id int32
| | +--rw sub-if-id? int32
| | +--rw rewrite!
| | | +--rw ingress!
| | | +--rw (tag-choice)?
| | | | +--:(pop)
| | | | | +--rw pop enumeration
| | | | +--:(push)
| | | | | +--rw push empty
| | | | +--:(translate)
| | | | +--rw translate enumeration
| | | +--rw dot1q uint16
| | | +--rw mode? enumeration
| | +--rw mtu? uint16
| | +--rw xconnect-group-name string
| | +--rw xconnect-encapsulation? enumeration
| | +--rw p2p-name string
| | +--rw sr-te!
| | | +--rw preferred-path!
| | | +--rw policy string
| | | +--rw fallback? enumeration
| | +--rw control-word? enumeration
| | +--rw pw-class string
| | +--rw action
| | +---x redeploy
| | +--ro output
| +--rw flat-L2vpn-evpn-vpws
| | +--rw evi-id uint16
| | +--rw local-site
| | | +--rw pe -> /ncs:devices/device/name
| | | +--rw if-description? string
| | | +--rw if-encap l2-serv-encap-type
| | | +--rw multi-home!
| | | | +--rw esi-value string
| | | +--rw vlan-id int32
| | | +--rw sub-if-id? int32
| | | | +--rw ingress!
| | | | +--rw (tag-choice)?
| | | | | +--:(pop)
| | | | | | +--rw pop enumeration
| | | | | +--:(push)
| | | | | | +--rw push empty
| | | | | +--:(translate)
| | | | | +--rw translate enumeration
| | | | +--rw dot1q uint16
| | | | +--rw mode? enumeration
| | | +--rw mtu? uint16

| | | +--rw xconnect-group-name string

| | | +--rw p2p-name string
| | | +--rw bgp!
| | | | +--rw as-no as-no-type
| | | | +--rw remote-as-no as-no-type
| | | | +--rw neighbor-ipv4? inet:ipv4-address
| | | | +--rw neighbor-ipv6? inet:ipv6-address
| | | | +--rw update-source!
| | | | +--rw if-type enumeration
| | | | +--rw if-id string
| | | +--rw sr-te!
| | | | +--rw (type)?
| | | | +--:(odn)
| | | | | +--rw odn!
| | | | | +--rw route-policy -> /l2vpn-route-
policy/name
| | | | +--:(prefered-path)
| | | | +--rw preferred-path!
| | | | +--rw policy string
| | | | +--rw fallback? enumeration
| | | +--rw pw-class string
| | | +--rw action
| | | | +---x redeploy
| | | | +--ro output
| | | | +--ro status? string
| | | | +--ro message? string
| | | +--rw evi-source uint32
| | | +--rw evi-target uint32
| | +--rw remote-site!
| | +--rw pe -> /ncs:devices/device/name
| | +--rw if-description? string
| | +--rw if-encap l2-serv-encap-type
| | +--rw multi-home!
| | | +--rw esi-value string
| | +--rw vlan-id int32
| | +--rw sub-if-id? int32
| | +--rw rewrite!
| | | | +--:(pop)
| | | | +--:(push)
| | | | +--:(translate)
| | +--rw xconnect-group-name string
| | +--rw p2p-name string
| | +--rw bgp!
| | | +--rw as-no as-no-type
| | | +--rw remote-as-no as-no-type
| | | +--rw neighbor-ipv4? inet:ipv4-address


| | | +--rw update-source!
| | +--rw sr-te!
| | | +--rw (type)?
| | | +--:(odn)
| | | | +--rw odn!
| | | | +--rw route-policy -> /l2vpn-route-
policy/name
| | | +--:(prefered-path)
| | | +--rw preferred-path!
| | | +--rw policy string
| | | +--rw fallback? enumeration
| | +--rw pw-class string
| | +--rw action
| | +---x redeploy
| | +--ro output
| +--rw action
| | +---w input
| | | +---w site-type? enumeration
| | +--ro output
| +---x redeploy
| | +--ro output
| +--rw dynamic-device-mapping* [ned-id]
| | +--rw ned-id string
| | +--rw python-impl-class-name string
| +--rw l2vpn-validation-enabled? boolean
| +--rw local-user? string
| +--rw auto-cleanup? boolean
| +--rw stacked-service-enabled!

14.6 Flat-L3VPN Function Pack
module: cisco-flat-L3vpn-fp
+--rw l3vpn-route-policy* [name]
| +--rw color* [id]
| +--rw id uint32
| +--rw ipv4!
| | +--rw prefix* tailf:ipv4-address-and-prefix-length
| +--rw ipv6!
| +--rw ipv6-prefix* tailf:ipv6-address-and-prefix-length
+--rw flat-L3vpn* [name]
| +--rw endpoint* [endpoint-name]
| | +--rw endpoint-name string
| | +--rw access-pe -> /ncs:devices/device/name
| | +--rw pe-ip-addr? tailf:ipv4-address-and-prefix-
length
| | +--rw pe-ipv6-addr? tailf:ipv6-address-and-prefix-
length
| | +--rw as-no? as-no-type
| | +--rw vlan-id? int32
| | +--rw ce-pe-prot
| | | +--rw (routing)?
| | | +--:(e-bgp)
| | | +--rw e-bgp
| | | +--rw remote-as-ipv4 as-no-type
| | | +--rw remote-as-ipv6 as-no-type
| | | +--rw update-source!
| | +--rw vrf
| | | +--rw vrf-definition string
| | | +--rw route-distinguisher? asn-ip-type
| | | +--rw vpn-id? vpn-id-type
| | | +--rw address-family* [address-family]
| | | +--rw address-family address-family-type
| | | +--rw redistribute-connected? empty
| | | +--rw metric? Bgp-default-metric-range
| | | +--rw vpn-target* [rt-value]
| | | +--rw rt-type bgp-rt-type
| | | +--rw rt-value asn-ip-type
| | +--rw sr-te!
| | | +--rw (type)?
| | | +--:(route-policy)
| | | +--rw route-policy -> /l3vpn-route-policy/name
| | +--rw l2-attachment-circuit* [name]
| | | +--rw name string

| | | +--rw vlan-id? int32

| | | | +--:(pop)
| | | | +--:(push)
| | | | +--:(translate)
| | +--rw action
| | | +--ro output
| +--rw action
| +---x redeploy
| | +--ro output
| +---w input
| | +---w endpoint? -> ../../../endpoint/endpoint-name
| | +---w outformat? outformat2
| +--ro output
| +--ro message? string
| +--rw dynamic-device-mapping* [ned-id]
| | +--rw ned-id string
| | +--rw python-impl-class-name string
| +--rw l3vpn-validation-enabled? boolean
| +--rw l3vpn-device-error-validation-enabled? boolean
| +--rw local-user? string
| +--rw auto-cleanup? boolean
| +--rw stacked-service-enabled!
| +--rw global-rd-enabled!
+--rw flat-L3vpn-actions
+---x cleanup
+---w input
| +---w service string
| +---w device? string
| +---w no-networking? boolean
+--ro output
+--ro success boolean
+--ro detail? string

Appendix C - Payloads and XML Outputs Page 120
15 Appendix C - Payloads and XML Outputs
15.1 Custom-Template Payloads

This topic contains sample custom-template payloads for the device
templates mentioned in the chapter Using Custom-Templates in this
documentation.
15.1.1 SR-ODN
Custom-template for all head-ends
<odn-template>
<name>SR-CLI-ODN-300</name>
<custom-template>
=============================================================>
APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL HEAD-ENDs
<name>CT-CLI-banner</name>
<variable>
<name>BANNER_TEXT</name>
<value>Welcome</value>
</variable>
</custom-template>
<head-end>
</head-end>
...
</odn-template>
</odn>
</sr-te>
</config>
Custom-template per head-end

<odn-template>
<name>SR-CLI-ODN-300</name>
<head-end>
<custom-template>
=============================================================>
APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR GIVEN HEAD-END
<variable>
</variable>
</custom-template>
</head-end>
</odn-template>
</odn>
</sr-te>
</config>

15.1.2 SR-Policy
Sample service payload using custom-template
<policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-
policies">
<policy>
=================================================== CUSTOM TEMPLATE
CONFIG FOR SR-POLICY
<custom-template>
<name>CT-CLI-logging</name>
</custom-template>
...
</policy>
</policies>
</sr-te>
</config>
15.1.3 SR-Settings
Custom-templates for all nodes or per node
sr-te-settings">
<custom-template>
=====================================================> APPLYING CT AT
GLOBAL LEVEL FOR ALL THE DEVICES IN A SERVICE
</custom-template>
<affinity-map-te>
<color>
<name>BLUE</name>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map-te>
<pcc>
<pce>
<address>
<ipv4>
</ipv4>
<ipv4>

</ipv4>
</address>
</pce>
</pcc>
<node>
<custom-template>
=====================================================> APPLYING CT AT
LOCAL LEVEL FOR GIVEN THE DEVICE IN A SERVICE
<variable>
</variable>
</custom-template>
<interface>
<if-id>5</if-id>
<te>
<affinity>
<color>
<name>GREEN</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
</pcc>
</node>
<node>
<interface>
<if-id>7</if-id>
<te>
<affinity>
<color>
<name>BLUE</name>
</color>
</affinity>
<metric>2</metric>
</te>
</interface>
<pcc>
<disable/>
</pcc>
</node>
</sr-setting>
</config>

15.1.4 SR-PCE
Custom-template for all nodes or per node
<sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-
pce">
<name>PCE-0</name>
<custom-template> ==========================================>
APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL NODES
</custom-template>
<node>
<custom-template> ==========================================>
APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR GIVEN NODE
<variable>
</variable>
</custom-template>
<pce>
<disjoint-path>
<group-id>
<id>60000</id>
<type>srlg</type>
<strict/>
<lsp>
<id>1</id>
<pcc-address>2.2.2.2</pcc-address>
<shortest-path/>
</lsp>
</group-id>
</disjoint-path>
<timers>
</timers>
<state-sync>
<ipv4>
</ipv4>
</state-sync>
<password>
<type>clear</type>
</password>
<backoff>
<ratio>11</ratio>
</backoff>
<segment-routing>
<strict-sid-only/>
<te-latency/>
</segment-routing>
</pce>
</node>
</sr-pce>
</config>


flat-L2vpn">
<custom-template>
======================================================================
======> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL SITES
</custom-template>
<local-site>
<pe>PIOSXR-0</pe>
<custom-template>
======================================================================
======> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR LOCAL SITE
<variable>
</variable>
</custom-template>
<if-id>1000</if-id>
<p2p-name>c</p2p-name>
</local-site>
<remote-site>
<pe>PIOSXR-1</pe>
<custom-template>
======================================================================
======> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR REMOTE SITE
<variable>
</variable>
</custom-template>
<if-type>FortyGigE</if-type>
<if-id>12</if-id>
</remote-site>
</flat-L2vpn>
</config>


flat-L3vpn">
<name>L3</name>
<custom-template>==============================================
==> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL ENDPOINTS
<name>CT-NETCONF-logging</name>
</custom-template>
<endpoint>
<if-id>3</if-id>
<custom-template>============================================
==> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR SINGLE ENDPOINT
<name>CT-NETCONF-banner-iteration</name>
<iteration>
<number>1</number>
<variable>
<name>BANNER_NAME</name>
<value>login</value>
</variable>
<variable>
<value>Welcome to Netconf P-0</value>
</variable>
</iteration>
<iteration>
<number>2</number>
<variable>
<name>BANNER_NAME</name>
<value>prompt-timeout</value>
</variable>
<variable>
<value>TimedOut</value>
</variable>
</iteration>
</custom-template>
<vrf>
<address-family>
<vpn-target>

</vpn-target>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
<ce-pe-prot>
<e-bgp>
</e-bgp>
</ce-pe-prot>
<sr-te>
<color>
<id>3000</id>
<ipv4>
</ipv4>
</color>
<color>
<id>3001</id>
<ipv4>
</ipv4>
</color>
</sr-te>
</endpoint>
...
</flat-L3vpn>
</config>

15.2 XML Output – get-modifications Action

This topic contains the XML output for the get-modifications action. For the
corresponding CLI outputs, see chapter Working with Action Commands in
this documentation.
15.2.1 SR-ODN
ODN action get-modifications outformat xml
message <devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>P-0</name>
<config>
<sr xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-segment-
routing-ms-cfg">
<traffic-engineering xmlns="http://cisco.com/ns/yang/Cisco-
IOS-XR-infra-xtc-agent-cfg">
<on-demand-colors>
<on-demand-color>
<color>300</color>
<on-demand-color-dyn-mpls>
<on-demand-color-dyn-mpls-metric>
<enable/>
</on-demand-color-dyn-mpls-metric>
<on-demand-color-dyn-mpls-pce>
<enable/>
</on-demand-color-dyn-mpls-pce>
<disjoint-path>
<disjointness-type>node</disjointness-type>
<sub-id>5</sub-id>
</disjoint-path>
<on-demand-color-dyn-mpls-flex-algorithm>200</on-
demand-color-dyn-mpls-flex-algorithm>
<enable/>
<affinity-rules>
<affinity-rule>
<rule>affinity-exclude-any</rule>
<affinity-name>
<affinity-name>BLUE</affinity-name>
</affinity-name>
</affinity-rule>
</affinity-rules>
</on-demand-color-dyn-mpls>
<enable/>
</on-demand-color>
</on-demand-colors>
</traffic-engineering>
</sr>
</config>
</device>
</devices>


ODN action get-modifications device P-0 outformat xml

<device>
<name>P-0</name>
<config>
<sr xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-segment-
routing-ms-cfg">
<traffic-engineering xmlns="http://cisco.com/ns/yang/Cisco-
IOS-XR-infra-xtc-agent-cfg">
<on-demand-colors>
<on-demand-color>
<color>300</color>
<on-demand-color-dyn-mpls>
<on-demand-color-dyn-mpls-metric>
<enable/>
</on-demand-color-dyn-mpls-metric>
<on-demand-color-dyn-mpls-pce>
<enable/>
</on-demand-color-dyn-mpls-pce>
<disjoint-path>
<disjointness-type>node</disjointness-type>
<sub-id>5</sub-id>
</disjoint-path>
<on-demand-color-dyn-mpls-flex-algorithm>200</on-
demand-color-dyn-mpls-flex-algorithm>
<enable/>
<affinity-rules>
<affinity-rule>
<rule>affinity-exclude-any</rule>
<affinity-name>
<affinity-name>BLUE</affinity-name>
</affinity-name>
</affinity-rule>
</affinity-rules>
</on-demand-color-dyn-mpls>
<enable/>
</on-demand-color>
</on-demand-colors>
</traffic-engineering>
</sr>
</config>
</device>
</devices>

15.2.2 SR-Policy
get-modifications action for service
SR-CLI-DYNAMIC action get-modifications outformat xml
<device>
<config>
<segment-routing xmlns="http://tail-f.com/ned/cisco-ios-xr">
<traffic-eng>
<segment-list>
<name>mysidlist</name>
<index>
<id>1</id>
<mpls>
<label>17001</label>
</mpls>
</index>
<index>
<id>2</id>
<mpls>
<label>18001</label>
</mpls>
</index>
</segment-list>
<policy>
<color>
<end-point>
<ipv4>1.1.1.1</ipv4>
</end-point>
</color>
<candidate-paths>
<preference>
<id>200</id>
<explicit>
<segment-list>
<name>mysidlist</name>
<weight>10</weight>
</segment-list>
</explicit>
</preference>
</candidate-paths>
</policy>
</traffic-eng>
</segment-routing>
</config>
</device>
</devices>

15.2.3 SR-Settings
outformat xml
<device>
<config>
<traffic-eng>
<interface>
<name>GigabitEthernet5</name>
<affinity>
<color>
<name>GREEN</name>
</color>
</affinity>
<metric>2</metric>
</interface>
<affinity-map>
<color>
<name>BLUE</name>
<prefix>name</prefix>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map>
<pcc>
<source-address>
<ipv4>192.168.2.1</ipv4>
</source-address>
<pce>
<address>
<ipv4>
</ipv4>
<ipv4>
</ipv4>
</address>
</pce>

</pcc>
</traffic-eng>
</segment-routing>
</config>
</device>
</devices>
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<config>
<traffic-eng>
<interface>
<affinity>
<color>
<name>BLUE</name>
</color>
</affinity>
<metric>2</metric>
</interface>
<affinity-map>
<color>
<name>BLUE</name>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map>
</traffic-eng>
</segment-routing>
</config>
</device>
</devices>

device PIOSXR-0 outformat xml
<device>
<config>
<traffic-eng>

<interface>
<affinity>
<color>
<name>GREEN</name>
</color>
</affinity>
<metric>2</metric>
</interface>
<affinity-map>
<color>
<name>BLUE</name>
</color>
<color>
<name>GREEN</name>
</color>
<color>
<name>RED</name>
</color>
</affinity-map>
<pcc>
<source-address>
<ipv4>192.168.2.1</ipv4>
</source-address>
<pce>
<address>
<ipv4>
</ipv4>
<ipv4>
</ipv4>
</address>
</pce>
</pcc>
</traffic-eng>
</segment-routing>
</config>
</device>
</devices>

15.2.4 SR-PCE
admin@ncs% request sr-pce PCE-0 action get-modifications outformat xml
<device>
<config>
<pce xmlns="http://tail-f.com/ned/cisco-ios-xr">
<address>
<ipv4>100.1.1.1</ipv4>
</address>
<disjoint-path>
<group-id>
<id>60000</id>
<type>srlg</type>
<sub-id>1</sub-id>
<strict/>
<lsp>
<id>1</id>
<pcc>
<ipv4>2.2.2.2</ipv4>
</pcc>
<shortest-path/>
</lsp>
</group-id>
</disjoint-path>
<timers>
</timers>
<state-sync>
<ipv4>
</ipv4>
</state-sync>
<password>
<type>clear</type>
</password>
<backoff>
<ratio>11</ratio>
</backoff>
<segment-routing>
<strict-sid-only/>
<te-latency/>
</segment-routing>
</pce>
</config>
</device>
</devices>

get-modifications action for a device

admin@ncs% request sr-pce PCE-0 action get-modifications device
PIOSXR-0 outformat xml
<device>
<config>
<pce xmlns="http://tail-f.com/ned/cisco-ios-xr">
<address>
<ipv4>100.1.1.1</ipv4>
</address>
<disjoint-path>
<group-id>
<id>60000</id>
<type>srlg</type>
<sub-id>1</sub-id>
<strict/>
<lsp>
<id>1</id>
<pcc>
<ipv4>2.2.2.2</ipv4>
</pcc>
<shortest-path/>
</lsp>
</group-id>
</disjoint-path>
<timers>
</timers>
<state-sync>
<ipv4>
</ipv4>
</state-sync>
<password>
<type>clear</type>
</password>
<backoff>
<ratio>11</ratio>
</backoff>
<segment-routing>
<strict-sid-only/>
<te-latency/>
</segment-routing>
</pce>
</config>
</device>
</devices>


outformat xml
<device>
<config>
<interface xmlns="http://tail-f.com/ned/cisco-ios-xr">
<HundredGigE>
<id>0/0/0/8</id>
<description>T-SDN Interface</description>
</HundredGigE>
<HundredGigE-subinterface>
<HundredGigE>
<id>0/0/0/8.100</id>
<mode>l2transport</mode>
<encapsulation>
<dot1q>
</dot1q>
</encapsulation>
<rewrite>
<ingress>
<tag>
<dot1q>123</dot1q>
</tag>
</ingress>
</rewrite>
</HundredGigE>
</HundredGigE-subinterface>
</interface>
<l2vpn xmlns="http://tail-f.com/ned/cisco-ios-xr">
<pw-class>
<encapsulation>
<mpls/>
</encapsulation>
</pw-class>
<xconnect>
<group>
<p2p>
<interface>
<name>HundredGigE0/0/0/8.100</name>
</interface>
<neighbor>
<pw-id>100</pw-id>

<ip-version>ipv4</ip-version>
<mpls>
<static>
<label>
<local>101</local>
<remote>202</remote>
</label>
</static>
</mpls>
</neighbor>
</p2p>
</group>
</xconnect>
</l2vpn>
</config>
</device>
</devices>
<device>
<config>
<HundredGigE>
<id>0/0/0/8</id>
</HundredGigE>
<HundredGigE-subinterface>
<HundredGigE>
<id>0/0/0/8.100</id>
<encapsulation>
<dot1q>
</dot1q>
</encapsulation>
<rewrite>
<ingress>
<tag>
<dot1q>123</dot1q>
</tag>
</ingress>
</rewrite>
</HundredGigE>
</HundredGigE-subinterface>
</interface>
<pw-class>
<encapsulation>
<mpls/>
</encapsulation>
</pw-class>

<xconnect>
<group>
<p2p>
<interface>
<name>HundredGigE0/0/0/8.100</name>
</interface>
<neighbor>
<pw-id>100</pw-id>
<mpls>
<static>
<label>
<local>202</local>
</label>
</static>
</mpls>
</neighbor>
</p2p>
</group>
</xconnect>
</l2vpn>
</config>
</device>
</devices>
get-modifications action for a remote-site
admin@ncs% request flat-L2vpn L2vpn01 action get-modifications site-

type remote outformat xml
<device>
<config>
<TenGigE>
<id>0/0/0/7</id>
</TenGigE>
<TenGigE-subinterface>
<TenGigE>
<id>0/0/0/7.200</id>
<description>l2vpn-static-01</description>
<encapsulation>
<dot1q>
</dot1q>
</encapsulation>
</TenGigE>
</TenGigE-subinterface>

</interface>
<pw-class>
<name>mpls-nso</name>
<encapsulation>
<mpls/>
</encapsulation>
</pw-class>
<xconnect>
<group>
<name>p2p-nso</name>
<p2p>
<name>STATIC-PIOSXR-1</name>
<interface>
<name>TenGigE0/0/0/7.200</name>
</interface>
<neighbor>
<pw-id>100</pw-id>
<mpls>
<static>
<label>
<local>202</local>
</label>
</static>
</mpls>
<pw-class>mpls-nso</pw-class>
</neighbor>
</p2p>
</group>
</xconnect>
</l2vpn>
</config>
</device>
</devices>


admin@ncs% request flat-L3vpn L3 action get-modifications outformat
xml
<device>
<name>P-0</name>
<config>
<interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-
IOS-XR-ifmgr-cfg">
<interface-configuration>
<active>act</active>
<interface-name>Loopback3</interface-name>
<interface-virtual/>
<vrf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-
cfg">L3VPN</vrf>
<ipv4-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-
ipv4-io-cfg">
<addresses>
<primary>
<netmask>255.255.255.255</netmask>
</primary>
</addresses>
</ipv4-network>
</interface-configuration>
</interface-configurations>
<vrfs xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-
cfg">
<vrf>
<vrf-name>L3VPN</vrf-name>
<create/>
<afs>
<af>
<af-name>ipv4</af-name>
<saf-name>unicast</saf-name>
<topology-name>default</topology-name>
<create/>
<bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-
bgp-cfg">
<import-route-targets>
<route-targets>
<route-target>
<type>as</type>
<as-or-four-byte-as>
<as-xx>0</as-xx>
<as>100</as>
<as-index>102</as-index>
<stitching-rt>0</stitching-rt>
</as-or-four-byte-as>
<as-xx>0</as-xx>
<as>200</as>

</route-target>
</route-targets>
</import-route-targets>
<export-route-targets>
<route-targets>
<route-target>
<type>as</type>
<as-xx>0</as-xx>
<as>100</as>
<as-xx>0</as-xx>
<as>200</as>
</route-target>
</route-targets>
</export-route-targets>
</bgp>
</af>
</afs>
</vrf>
</vrfs>
<bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg">
<instance>
<instance-name>default</instance-name>
<instance-as>
<as>0</as>
<four-byte-as>
<as>65001</as>
<vrfs>
<vrf>
<vrf-global>
<route-distinguisher>
<type>as</type>
<as-xx>0</as-xx>
<as>1</as>
</route-distinguisher>
<vrf-global-afs>
<vrf-global-af>
<af-name>ipv4-unicast</af-name>
<enable/>
</vrf-global-af>
</vrf-global-afs>
<exists/>
</vrf-global>
<vrf-neighbors>

<vrf-neighbor>
<neighbor-address>169.1.1.2</neighbor-address>
<vrf-neighbor-afs>
<vrf-neighbor-af>
<activate/>
<route-policy-in>PASS_ALL</route-policy-in>
<route-policy-out>PASS_ALL</route-policy-
out>
</vrf-neighbor-af>
</vrf-neighbor-afs>
<remote-as>
<as-xx>0</as-xx>
<as-yy>65002</as-yy>
</remote-as>
</vrf-neighbor>
</vrf-neighbors>
</vrf>
</vrfs>
<bgp-running/>
</four-byte-as>
</instance-as>
</instance>
</bgp>
<routing-policy xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-
policy-repository-cfg">
<route-policies>
<route-policy>
<route-policy-name>PASS_ALL</route-policy-name>
<rpl-route-policy>route-policy PASS_ALL
pass
end-policy
</rpl-route-policy>
</route-policy>
</route-policies>
</routing-policy>
</config>
</device>
</devices>
<device>
<name>P-1</name>
<config>
IOS-XR-ifmgr-cfg">
cfg">L3VPN</vrf>
ipv4-io-cfg">
<addresses>
<primary>

</primary>
</addresses>
</ipv4-network>
cfg">
<vrf>
<create/>
<afs>
<af>
<create/>
bgp-cfg">
<route-targets>
<route-target>
<type>as</type>
<as-xx>0</as-xx>
<as>100</as>
<as-xx>0</as-xx>
<as>200</as>
</route-target>
</route-targets>
<route-targets>
<route-target>
<type>as</type>
<as-xx>0</as-xx>
<as>100</as>
<as-xx>0</as-xx>
<as>200</as>
</route-target>
</route-targets>

</bgp>
</af>
</afs>
</vrf>
</vrfs>
<instance>
<instance-as>
<as>0</as>
<four-byte-as>
<as>65001</as>
<vrfs>
<vrf>
<vrf-global>
<type>as</type>
<as-xx>0</as-xx>
<as>1</as>
<vrf-global-afs>
<vrf-global-af>
<enable/>
</vrf-global-af>
</vrf-global-afs>
<exists/>
</vrf-global>
<vrf-neighbors>
<vrf-neighbor>
<vrf-neighbor-afs>
<vrf-neighbor-af>
<activate/>
out>
</vrf-neighbor-af>
</vrf-neighbor-afs>
<remote-as>
<as-xx>0</as-xx>
</remote-as>
</vrf-neighbor>
</vrf-neighbors>
</vrf>
</vrfs>
<bgp-running/>
</four-byte-as>
</instance-as>
</instance>
</bgp>

<route-policies>
<route-policy>
pass
end-policy
</rpl-route-policy>
</route-policy>
</route-policies>
</routing-policy>
</config>
</device>
</devices>
get-modifications action for an endpoint

0 outformat xml
<device>
<name>P-0</name>
<config>
IOS-XR-ifmgr-cfg">
cfg">L3VPN</vrf>
ipv4-io-cfg">
<addresses>
<primary>
</primary>
</addresses>
</ipv4-network>
cfg">
<vrf>
<create/>
<afs>
<af>
<create/>

bgp-cfg">
<route-targets>
<route-target>
<type>as</type>
<as-xx>0</as-xx>
<as>100</as>
<as-xx>0</as-xx>
<as>200</as>
</route-target>
</route-targets>
<route-targets>
<route-target>
<type>as</type>
<as-xx>0</as-xx>
<as>100</as>
<as-xx>0</as-xx>
<as>200</as>
</route-target>
</route-targets>
</bgp>
</af>
</afs>
</vrf>
</vrfs>
<instance>
<instance-as>
<as>0</as>
<four-byte-as>
<as>65001</as>
<vrfs>
<vrf>
<vrf-global>

<type>as</type>
<as-xx>0</as-xx>
<as>1</as>
<vrf-global-afs>
<vrf-global-af>
<enable/>
</vrf-global-af>
</vrf-global-afs>
<exists/>
</vrf-global>
<vrf-neighbors>
<vrf-neighbor>
<vrf-neighbor-afs>
<vrf-neighbor-af>
<activate/>
out>
</vrf-neighbor-af>
</vrf-neighbor-afs>
<remote-as>
<as-xx>0</as-xx>
</remote-as>
</vrf-neighbor>
</vrf-neighbors>
</vrf>
</vrfs>
<bgp-running/>
</four-byte-as>
</instance-as>
</instance>
</bgp>
<route-policies>
<route-policy>
pass
end-policy
</rpl-route-policy>
</route-policy>
</route-policies>
</routing-policy>
</config>
</device>
</devices>

Appendix D: Use Cases Page 147
16 Appendix D: Use Cases

The use cases in this section provide an insight to the T-SDN FPs workflow.
These use cases provide complete functional solution and thus help to
understand and implement the various service models in the CFP.
To explain these use cases, the network orchestration and virtualization
platform Virtual Internet Routing Lab (VIRL) is used to design the network
topology, configure the virtual machines, and instantiate the network.
The following criteria was considered to design the topology and configure
the virtual machines.
1. Install T-SDN FPs with the required NED packages. For more information on
the installation, see the Cisco NSO Transport SDN Function Pack Bundle
Installation Guide.
2. Use image versions 6.5.3 or 6.6.3 in the topology.
3. Copy the IOSXRv9000 image version 6.5.3.
4. Create flavor before starting the simulation on VIRL (Flavor - 16384 MB, 4
CPUs, and 80 GB Disk)
5. Start the VIRL simulation with the topology configuration. The topology
configuration is available at TSDN-0_0_11.virl.
6. Configure the network topology with Intermediate System to Intermediate
System (isis), BGP protocol, and Segment Routing infrastructure setup.
The reference topology appears as follows:
7. Ensure NSO VM is reachable to IOSXRV9000 spun in VIRL setup.

Verify the configuration of the devices in the topology. Make sure the
segment routing label table on isis is listing the devices connected in the
topology.

Device Verification
RP/0/RP0/CPU0:Core-R1#show isis segment-routing label

table
Tue May 5 19:47:57.076 UTC
IS-IS 1 IS Label Table
IOSXRv9000-1 Label Prefix/Interface
---------- ----------------
(Core-R1) 17001 Loopback0
18001 100.100.100.2/32
19001 100.100.100.3/32
20001 100.100.100.4/32
21001 100.100.100.5/32
22001 100.100.100.6/32

table
Tue May 5 19:48:17.641 UTC
---------- ----------------
(Core-R2) 17001 100.100.100.1/32
18001 Loopback0
19001 100.100.100.3/32
20001 100.100.100.4/32
21001 100.100.100.5/32
22001 100.100.100.6/32

table
Tue May 5 19:48:27.695 UTC
---------- ----------------
(Core-R3) 17001 100.100.100.1/32
18001 100.100.100.2/32
19001 Loopback0
20001 100.100.100.4/32
21001 100.100.100.5/32
22001 100.100.100.6/32

table
Tue May 5 19:48:46.989 UTC
---------- ----------------
(Core-R4) 17001 100.100.100.1/32
18001 100.100.100.2/32
19001 100.100.100.3/32
20001 Loopback0
21001 100.100.100.5/32
22001 100.100.100.6/32
RP/0/RP0/CPU0:PE-R5#show isis segment-routing label table

IOSXRv9000-5 Tue May 5 19:50:06.116 UTC
(PE-R5) IS-IS 1 IS Label Table
Label Prefix/Interface
---------- ----------------

17001 100.100.100.1/32
18001 100.100.100.2/32
19001 100.100.100.3/32
20001 100.100.100.4/32
21001 Loopback0
22001 100.100.100.6/32
RP/0/RP0/CPU0:PE-R6#show isis segment-routing label table

Tue May 5 19:50:09.317 UTC
Label Prefix/Interface
IOSXRv9000-6 ---------- ----------------
(PE-R6) 17001 100.100.100.1/32
18001 100.100.100.2/32
19001 100.100.100.3/32
20001 100.100.100.4/32
21001 100.100.100.5/32
22001 Loopback0
8. Add the devices configured in the VIRL topology (TSDN-0_0_11.virl) to the

NSO device tree. The IOSXR9000v devices are added as CLI type devices.
configure
set devices authgroups group iosxr_authgroup default-map remote-name
admin remote-password cisco
set devices device Core-R1 authgroup iosxr_authgroup address

172.16.1.31 port 22 state admin-state unlocked
set devices device Core-R1 device-type cli ned-id cisco-iosxr-cli-7.24
set devices device Core-R1 trace raw



set devices device PIOSXR-0 authgroup iosxr_authgroup address

set devices device PIOSXR-0 device-type cli ned-id cisco-iosxr-cli-
7.24
set devices device PIOSXR-0 trace raw
set devices device PIOSXR-1 authgroup iosxr_authgroup address

set devices device PIOSXR-1 device-type cli ned-id cisco-iosxr-cli-
7.24
set devices device PIOSXR-1 trace raw
commit

Run the following commands:
request devices fetch-ssh-host-keys

request devices connect
request devices sync-from
16.1 Use Cases

This section covers use cases for the various models and their
implementations in T-SDN FPs.
16.1.1 Use Case 1: Instantiating Example L3VPN over SR-TE for Color 30
L3VPN allows you to associate a SR-TE policy to instantiate the service. Define
and set the path for the color in the policy. For more information about
creating Flat L3VPN service and creating SR-Policies, see chapter
Configuration in this documentation.
This use case shows the end-to-end workflow to instantiate a
Flat-L3VPN service over SR-TE for color 30. The following diagram shows the
required tasks for this use case.
The detailed workflow includes:

1. Create and verify SR-Policy with Metric-TE for color 30.
2. Create and verify L3VPN-Route-policy for color 30.
3. Create and verify Flat-L3VPN service.
4. Associate Route Policy to L3VPN service and verify the same.
The following procedure shows how to instantiate L3VPN over SR-TE for color
30.

To instantiate example L3VPN over SR-TE for color 30:

1. Create a SR-policy with metric TE for color 30.
<policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-
sr-policies">
<policy>
<name>sr-flex</name>
<head-end>
<name>PE-R5</name>
</head-end>
<color>30</color>
<binding-sid>169001</binding-sid>
<path>
<dynamic>
<metric-type>te</metric-type>
</dynamic>
</path>
</policy>
</policies>
</sr-te>
</config>
2. Display the plan and verify the policy is in the ready-reached state.
3. Get modifications for the policy to view if the configuration is pushed to the
device. For more information on the get-modifications action, see chapter
Working with Action Commands in this documentation.
admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies policy sr-
flex action get-modifications outformat cli
message devices {
device PE-R5 {
config {
traffic-eng {
+ policy srte_c_30_ep_100.100.100.6 {
+ binding-sid {
+ mpls 169001;
+ }
+ color {
+ value 30;
+ end-point {
+ ipv4 100.100.100.6;
+ }
+ }

+ candidate-paths {
+ preference 1 {
+ dynamic {
+ metric {
+ type te;
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
4. Create L3VPN route policy for color 30.

<l3vpn-route-policy
<name>L3-color-30</name>
<color>
<id>30</id>
<ipv4>
<prefix>122.122.122.1/32</prefix> *** Loopback interface on
PE-R5, created as part of L3VPN ***
</ipv4>
</color>
5. Create the flat-L3VPN service.

flat-L3vpn">
<name>L3vpn-flex</name>
<endpoint>
<endpoint-name>PE-R5</endpoint-name>
<access-pe>PE-R5</access-pe>
<if-id>4</if-id>
<as-no>1</as-no>
<ce-pe-prot>
<e-bgp>
</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN-flex</vrf-definition>
<address-family>
<vpn-target>

</vpn-target>
<vpn-target>
</vpn-target>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
</endpoint>
</flat-L3vpn>
6. Associate the route policy to the L3VPN service. This configuration data is
deployed on the device when the flat-L3VPN service is applied with this route
policy.
flat-L3vpn">
<name>L3vpn-flex</name>
<endpoint>
<sr-te>
<route-policy>L3-color-30</route-policy>
</sr-te>
</endpoint>
</flat-L3vpn>
7. Display the plan status for the L3VPN service and verify the service is
successfully deployed.
8. Get modifications for the L3VPN service and verify the route policy is applied
to the device PE-R5.
admin@ncs# flat-L3vpn L3vpn-flex action get-modifications outformat
cli
message devices {
device PE-R5 {
config {
cisco-ios-xr:vrf {
+ vrf-list L3VPN-flex {
+ address-family {

+ ipv4 {
+ unicast {
+ import {
+ route-target {
+ address-list 200:200;
+ }
+ }
+ export {
+ route-policy SET_COLORv4_L3-
color-30;
+ route-target {
+ }
+ }
+ }
+ }
+ }
+ }
}
+ Loopback 4 {
+ vrf L3VPN-flex;
+ ipv4 {
+ address {
+ ip 122.122.122.1;
+ mask 255.255.255.255;
+ }
+ }
+ }
}
cisco-ios-xr:extcommunity-set {
+ opaque COLOR_30 {
+ set 30;
+ }
}
cisco-ios-xr:route-policy PASS_ALL {
- value " pass\r\n";
+ value pass;
}
+ cisco-ios-xr:route-policy SET_COLORv4_L3-color-30 {
+ value " if destination in (122.122.122.1/32)
then\r\n set extcommunity color COLOR_30\r\n endif\r\n";
+ }
cisco-ios-xr:router {
bgp {
bgp-no-instance 1 {
+ vrf L3VPN-flex {
+ rd 11:11;
+ address-family {
+ ipv4 {
+ unicast {
+ }
+ }

+ }
+ neighbor 123.123.123.2 {
+ remote-as 65009;
+ address-family {
+ ipv4 {
+ unicast {
+ route-policy in {
+ name PASS_ALL;
+ }
+ route-policy out {
+ name PASS_ALL;
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}
}
9. Verify the status of Segment Routing Traffic Engineering-Policy Admin and

Operational are up. This indicates the successful instantiation of example
L3VPN service over SR-TE for color 30.
admin@ncs# devices device PE-R5 live-status exec show segment-routing
traffic-eng policy
result
Tue May 5 23:23:07.909 UTC
SR-TE policy database

---------------------
Color: 30, End-point: 100.100.100.6
Name: srte_c_30_ep_100.100.100.6
Status:
Admin: up Operational: up for 02:45:29 (since May 5
20:37:38.468)
Candidate-paths:
Preference: 1 (configuration) (active)
Name: srte_c_30_ep_100.100.100.6
Requested BSID: 169001
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 30
24005 [Adjacency-SID, 20.20.10.5 - 20.20.10.6]
24003 [Adjacency-SID, 20.20.10.17 - 20.20.10.18]
24005 [Adjacency-SID, 20.20.10.30 - 20.20.10.29]
Attributes:
Binding SID: 169001
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
RP/0/RP0/CPU0:PE-R5#

16.1.2 Use Case 2: Flat- L3VPN Route Policy for Color 20 by Using SR ODN with
Flex Algo
This use case discusses how to create and instantiate L3VPN service between
two devices for color 20. It discusses how to use the SR-ODN template for the
color for which an on-demand policy instantiation is desired.
The following diagram helps to understand the use case. The two devices -
device 5 and device 6 use two loopback interfaces for each device with IP
addresses 122.122.122.1 and 123.123.123.1 respectively on the same VIRL
L3VPN-T-SDN. Configure an ODN template for the color 20 for which to
instantiate the on-demand policy. Flex algo slices the network to define the
paths for the source and the destination traffic. For the color 20, flex algo
assigns the path 128 from device 5 and path 129 from device 6.
For more information about creating L3VPN service and SR-ODN service, see
chapter Configuration in this documentation. The following diagram shows
the required tasks for this use case.


1. Create and verify SR-Settings service to set up Flex Algo on the core and PE
devices.
2. Create and verify SR-ODN service.
3. Create L3VPN route policy.
4. Create Flat-L3VPN service.
6. Perform a self-test on L3VPN service.
To create a flat L3VPN route policy for color 20 by using SR-ODN with Flex
Algo:
1. Create SR-Settings service to setup Flex Algo on core and PE devices.
sr-te-settings">
<name>SR-SET-Flex-ALGO-ALL</name>
<node>
<name>Core-R1</name>
<isis>
<instance-name>1</instance-name>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>128</name>
<advertise-definition/>
</flex-algo>
</isis>
</node>
<node>
<isis>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>128</name>

</flex-algo>
</isis>
</node>
<node>
<isis>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>129</name>
</flex-algo>
</isis>
</node>
<node>
<isis>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>129</name>
</flex-algo>
</isis>
</node>
<node>
<name>PE-R5</name>
<isis>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>128</name>
</flex-algo>
<flex-algo>
<name>129</name>

</flex-algo>
</isis>
</node>
<node>
<name>PE-R6</name>
<isis>
<loopback>
<id>0</id>
<prefix-sid>
</prefix-sid>
</loopback>
<flex-algo>
<name>128</name>
</flex-algo>
<flex-algo>
<name>129</name>
</flex-algo>
</isis>
</node>
</sr-setting>
</config>
2. Display the plan for the SR-Settings service and verify the service is deployed.
3. Get modifications for the SR-Settings service and verify the configuration is
pushed to the core and PE devices.
admin@ncs# sr-setting SR-SET-Flex-ALGO-ALL action get-modifications

outformat cli

message devices {
device Core-R1 {
config {
isis {
tag 1 {
+ flex-algo 128 {
+ advertise-definition;
+ }
interface Loopback0 {
address-family {
ipv4 {
unicast {
prefix-sid {
+ absolute 16001;
- index 1001;
}
}
}
}
}
}
}
}
}
}
}
devices {
device Core-R2 {
config {
isis {
tag 1 {
+ flex-algo 128 {
+ }
address-family {
ipv4 {
unicast {
prefix-sid {
+ absolute 16002;
- index 2001;
}
}
}
}
}
}
}
}
}
}
}
devices {
device Core-R3 {
config {
isis {
tag 1 {
+ flex-algo 129 {
+ }
address-family {

ipv4 {
unicast {
prefix-sid {
+ absolute 16003;
- index 3001;
}
}
}
}
}
}
}
}
}
}
}
devices {
device Core-R4 {
config {
isis {
tag 1 {
+ flex-algo 129 {
+ }
address-family {
ipv4 {
unicast {
prefix-sid {
+ absolute 16004;
- index 4001;
}
}
}
}
}
}
}
}
}
}
}
devices {
device PE-R5 {
config {
isis {
tag 1 {
+ flex-algo 128 {
+ }
+ flex-algo 129 {
+ }
address-family {
ipv4 {
unicast {
prefix-sid {
+ absolute 16005;
- index 5001;
}
}
}
}
}

}
}
}
}
}
}
devices {
device PE-R6 {
config {
isis {
tag 1 {
+ flex-algo 128 {
+ }
+ flex-algo 129 {
+ }
address-family {
ipv4 {
unicast {
prefix-sid {
+ absolute 16006;
- index 6001;
}
}
}
}
}
}
}
}
}
}
}
4. Create and apply the SR-ODN template to assign color 20 the path 128
on PE-R5 and the path 129 on PE-R6.
<odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-
sr-odn">
<odn-template>
<name>SR-Flex-Algo-PE-R5</name>
<head-end>
<name>PE-R5</name>
</head-end>
<color>20</color>
<dynamic>
</dynamic>
</odn-template>
<odn-template>
<name>SR-Flex-Algo-PE-R6</name>
<head-end>
<name>PE-R6</name>
</head-end>
<color>20</color>
<dynamic>

</dynamic>
</odn-template>
</odn>
</sr-te>
</config>
5. Display the SR ODN template plan to verify if the configuration is applied to

the devices PE-R5 and PE-R6.
6. Get modifications for the SR ODN template and verify if the configuration is
pushed to devices PE-R5 and PE-R6.
admin@ncs# sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-Flex-
Algo-PE-R5 action get-modifications
message devices {
device PE-R5 {
config {
traffic-eng {
on-demand {
+ color 20 {
+ dynamic {
+ metric {
+ type igp;
+ }
+ sid-algorithm 128;
+ }
+ }
}
}
}
}
}
}
admin@ncs# sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-Flex-

Algo-PE-R6 action get-modifications
message devices {
device PE-R6 {
config {
traffic-eng {
on-demand {
+ color 20 {

+ dynamic {
+ metric {
+ type igp;
+ }
+ sid-algorithm 129;
+ }
+ }
}
}
}
}
}
7. Create the L3VPN route policy for color 20 on devices PE-R5 and PE-R6. This
configuration data is deployed on the device when flat L3VPN service is
applied with this route policy.
<l3vpn-route-policy
<name>L3-color-20-PE-R5</name>
<color>
<id>20</id>
<ipv4>
<prefix>122.122.122.1/32</prefix>
</ipv4>
</color>
<l3vpn-route-policy
<name>L3-color-20-PE-R6</name>
<color>
<id>20</id>
<ipv4>
<prefix>123.123.123.1/32</prefix>
</ipv4>
</color>
</config>
8. Create L3VPN service on devices PE-R5 and PE-R6.

flat-L3vpn">
<name>L3VPN-TSDN</name>
<endpoint>
<if-id>4</if-id>
<as-no>1</as-no>
<ce-pe-prot>
<e-bgp>
<update-source>
<if-id>4</if-id>
</update-source>

</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN-T-SDN</vrf-definition>
<address-family>
<redistribute-connected/>
<metric>2</metric>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
<sr-te>
<route-policy>L3-color-20-PE-R5</route-policy>
</sr-te>
</endpoint>
<endpoint>
<if-id>4</if-id>
<as-no>1</as-no>
<ce-pe-prot>
<e-bgp>
<update-source>
<if-id>4</if-id>
</update-source>
</e-bgp>
</ce-pe-prot>
<vrf>
<vrf-definition>L3VPN-T-SDN</vrf-definition>
<address-family>
<redistribute-connected/>
<metric>2</metric>
<vpn-target>
</vpn-target>
</address-family>
</vrf>
<sr-te>
</sr-te>
</endpoint>
</flat-L3vpn>
</config>
9. Associate the route policy to the L3VPN service on the devices PE-R5 and
PE-R6.

tsdn-flat-L3vpn">
<name>L3VPN-TSDN</name>
<endpoint>
<sr-te>
</sr-te>
</endpoint>
<endpoint>
<sr-te>
</sr-te>
</endpoint>
</flat-L3vpn>
</config>
10. Verify the plan for L3VPN service. Make sure the services are ready reached
and type-self state-ready is in reached status.
11. Get modifications on the L3VPN service to verify the configuration is applied
on devices PE-R5 and PE-R6.
admin@ncs# flat-L3vpn L3VPN-TSDN action get-modifications outformat

cli
message devices {
device PE-R5 {
config {
cisco-ios-xr:vrf {
+ vrf-list L3VPN-T-SDN {
+ address-family {
+ ipv4 {
+ unicast {
+ import {
+ route-target {
+ }
+ }
+ export {
color-20-PE-R5;
+ route-target {
+ }
+ }
+ }
+ }
+ }
+ }

}
+ Loopback 4 {
+ vrf L3VPN-T-SDN;
+ ipv4 {
+ address {
+ ip 122.122.122.1;
+ mask 255.255.255.0;
+ }
+ }
+ }
}
+ opaque COLOR_20 {
+ set 20;
+ }
}
+ cisco-ios-xr:route-policy PASS_ALL {
+ value pass;
+ }
+ cisco-ios-xr:route-policy SET_COLORv4_L3-color-20-PE-R5 {
+ }
bgp {
bgp-no-instance 1 {
+ vrf L3VPN-T-SDN {
+ rd 10:10;
+ address-family {
+ ipv4 {
+ unicast {
+ redistribute {
+ connected {
+ metric 2;
+ }
+ }
+ }
+ }
+ }
+ neighbor 122.122.122.2 {
+ remote-as 65002;
+ update-source {
+ Loopback 4;
+ }
+ address-family {
+ ipv4 {
+ unicast {
+ route-policy in {
+ name PASS_ALL;
+ }
+ name PASS_ALL;
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
}

devices {
device PE-R6 {
config {
cisco-ios-xr:vrf {
+ vrf-list L3VPN-T-SDN {
+ address-family {
+ ipv4 {
+ unicast {
+ import {
+ route-target {
+ }
+ }
+ export {
color-20-PE-R6;
+ route-target {
+ }
+ }
+ }
+ }
+ }
+ }
}
+ Loopback 4 {
+ vrf L3VPN-T-SDN;
+ ipv4 {
+ address {
+ ip 123.123.123.1;
+ mask 255.255.255.0;
+ }
+ }
+ }
}
+ opaque COLOR_20 {
+ set 20;
+ }
}
+ cisco-ios-xr:route-policy PASS_ALL {
+ value pass;
+ }
+ cisco-ios-xr:route-policy SET_COLORv4_L3-color-20-PE-R6 {
+ }
bgp {
bgp-no-instance 1 {
+ vrf L3VPN-T-SDN {
+ rd 10:10;
+ address-family {
+ ipv4 {
+ unicast {
+ redistribute {
+ connected {
+ metric 2;
+ }
+ }
+ }
+ }
+ }
+ neighbor 123.123.123.2 {

+ remote-as 65003;
+ update-source {
+ Loopback 4;
+ }
+ address-family {
+ ipv4 {
+ unicast {
+ route-policy in {
+ name PASS_ALL;
+ }
+ name PASS_ALL;
+ }
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
}
12. Perform self-test on L3VPN service to ensure the service is set up and both
the PE devices are able to ping on the loopback interfaces (Loopback-4)
created in L3VPN service.
admin@ncs# flat-L3vpn L3VPN-TSDN action self-test
status success
message [('PE-R6', 'PE-R5', 'success', 'Success rate is 100 percent
(5/5)'), ('PE-R5', 'PE-R6', 'success', 'Success rate is 100 percent
(5/5)')]
admin@ncs#
16.1.3 Use Case 3: Instantiating L2VPN over SR-TE for Color 40

L2VPN allows dissimilar systems to be connected in a way that it appears as if
they are connected to a common LAN segment. For more information about
how to create L2VPN service, see chapter Configuration in this
documentation.
This use case discusses how to instantiate L2VPN over SR-TE for color 40. The
following diagram shows the required tasks for this use case.


1. Create and verify SR-Policy.
2. Create L2VPN route policy.
3. Create Flat-L2VPN service.
5. Perform a self-test on the L2VPN service.
To instantiate L2VPN over SR-TE for color 40:
1. Create SR-policy with metric-latency for color 40 on devices PE-R5 and PE-R6.
sr-policies">
<policy>
<name>sr-policy-color-40-PE-R5</name>
<head-end>
<name>PE-R5</name>
</head-end>
<color>40</color>
<path>
<dynamic>
<metric-type>latency</metric-type>
</dynamic>
</path>
</policy>
<policy>
<name>sr-policy-color-40-PE-R6</name>
<head-end>
<name>PE-R6</name>
</head-end>
<color>40</color>
<path>
<dynamic>
<metric-type>latency</metric-type>
</dynamic>
</path>
</policy>
</policies>
</sr-te>
</config>

2. Display the plan for the policy and verify the policy status is reached.
3. Get modifications for the SR-TE policy and verify the configuration is pushed
to the devices.
admin@ncs#admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies
policy sr-policy-color-40-PE-R5 action get-modifications outformat
cli
message devices {
device PE-R5 {
config {
traffic-eng {
+ policy srte_c_40_ep_100.100.100.6 {
+ binding-sid {
+ mpls 40;
+ }
+ color {
+ value 40;
+ end-point {
+ ipv4 100.100.100.6;
+ }
+ }
+ candidate-paths {
+ preference 2 {
+ dynamic {
+ metric {
+ type latency;
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies policy sr-

policy-color-40-PE-R6 action get-modifications outformat cli
message devices {
device PE-R6 {
config {

traffic-eng {
+ policy srte_c_40_ep_100.100.100.5 {
+ binding-sid {
+ mpls 40;
+ }
+ color {
+ value 40;
+ end-point {
+ ipv4 100.100.100.5;
+ }
+ }
+ candidate-paths {
+ preference 2 {
+ dynamic {
+ metric {
+ type latency;
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
4. Create L2VPN route policy for color 40.

<l2vpn-route-policy
<name>Local_RP-Color-40</name>
<color>
<id>40</id>
<ipv4>
<rd>100.100.100.5:3</rd> *** Loopback0 ip on PE-R5 ***
<rd>100.100.100.6:3</rd> *** Loopback0 ip on PE-R6 ***
</ipv4>
</color>
<l2vpn-route-policy
<name>Remote_RP-Color-40</name>
<color>
<id>40</id>
<ipv4>
<rd>100.100.100.5:3</rd>
<rd>100.100.100.6:3</rd>
</ipv4>
</color>
</config>
5. Create flat L2VPN service.

tsdn-flat-L2vpn">

<name>L2VPN-Service</name>
<service-type>p2p</service-type>
<flat-L2vpn-p2p>
<pw-id>100</pw-id>
<local-site>
<pe>PE-R5</pe>
<if-id>0/0/0/2</if-id>
<if-description>L2vpn-p2p-flat-remote</if-description>
<xconnect-group-name>TSDN-L2vpn</xconnect-group-name>
<xconnect-encapsulation>mpls</xconnect-encapsulation>
<p2p-name>p2p-flat</p2p-name>
<control-word>no</control-word>
<pw-class>TSDN-L2vpn-p2p</pw-class>
<xconnect-local-ip>100.100.100.5</xconnect-local-ip>
<xconnect-remote-ip>100.100.100.6</xconnect-remote-ip>
<mpls-local-label>101</mpls-local-label>
<mpls-remote-label>202</mpls-remote-label>
</local-site>
<remote-site>
<pe>PE-R6</pe>
<if-id>0/0/0/1</if-id>
<if-description>L2vpn-p2p-flat-remote</if-description>
<xconnect-group-name>TSDN-L2vpn</xconnect-group-name>
<p2p-name>p2p-flat</p2p-name>
<pw-class>TSDN-L2vpn-p2p</pw-class>
</remote-site>
</flat-L2vpn-p2p>
</flat-L2vpn>
</config>
6. Associate the route policy to L2VPN service.

flat-L2vpn">
<name>L2VPN-Service</name>
<flat-L2vpn-p2p>
<local-site>
<sr-te>
<preferred-path>
<policy>Local_RP-Color-40</policy>
</preferred-path>
</sr-te>
</local-site>
<remote-site>
<sr-te>
<preferred-path>
<policy>Remote_RP-Color-40</policy>
</preferred-path>
</sr-te>
</remote-site>
</flat-L2vpn-p2p>
</flat-L2vpn>

7. Verify the plan status for L2VPN service and verify the service is successfully
deployed.
8. Get modifications for the L2VPN service verify the route policy is applied to
the devices.
admin@ncs# flat-L2vpn L2VPN-Service action get-modifications
message devices {
device PE-R5 {
config {
GigabitEthernet-subinterface {
+ GigabitEthernet 0/0/0/2.100 {
+ mode l2transport;
+ description L2vpn-p2p-flat-remote;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ }
}
}
cisco-ios-xr:l2vpn {
+ pw-class TSDN-L2vpn-p2p {
+ encapsulation {
+ mpls {
+ preferred-path {
+ sr-te {
+ policy Local_RP-Color-40;
+ }
+ }
+ }
+ }
+ }
xconnect {
+ group TSDN-L2vpn {
+ p2p p2p-flat {
+ interface
GigabitEthernet0/0/0/2.100;
+ neighbor 100.100.100.6 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 101;
+ remote 202;
+ }

+ }
+ }
+ pw-class TSDN-L2vpn-p2p;
+ }
+ }
+ }
}
}
}
}
}
devices {
device PE-R6 {
config {
GigabitEthernet-subinterface {
+ GigabitEthernet 0/0/0/1.100 {
+ mode l2transport;
+ description L2vpn-p2p-flat-remote;
+ encapsulation {
+ dot1q {
+ vlan-id 100;
+ }
+ }
+ }
}
}
+ pw-class TSDN-L2vpn-p2p {
+ encapsulation {
+ mpls {
+ preferred-path {
+ sr-te {
+ policy Remote_RP-Color-40;
+ }
+ }
+ }
+ }
+ }
+ xconnect {
+ group TSDN-L2vpn {
+ p2p p2p-flat {
+ interface
GigabitEthernet0/0/0/1.100;
+ neighbor 100.100.100.5 100 {
+ ip-version ipv4;
+ mpls {
+ static {
+ label {
+ local 202;
+ remote 101;
+ }
+ }
+ }
+ pw-class TSDN-L2vpn-p2p;
+ }
+ }
+ }
+ }
+ }
}
}
}

9. Perform self-test on L2VPN service to ensure the service is set up on both the
PE devices.
admin@ncs# flat-L3vpn flat-L2vpn L2VPN-Service action self-test
status success
message local-site: success. remote-site: success
10. Verify the status of Segment Routing Traffic Engineering-Policy Admin and
Operational are up on both the devices. This indicates the successful
instantiation of L2VPN service over SR-TE for color 40.
On PE-R5
traffic-eng policy
result
Thu May 7 22:51:16.950 UTC

---------------------
Color: 40, End-point: 100.100.100.6

Name: srte_c_40_ep_100.100.100.6
Status:
22:04:20.933)
Candidate-paths:
Name: srte_c_40_ep_100.100.100.6
Requested BSID: 40
Dynamic (valid)
Metric Type: LATENCY, Path Accumulated Metric: 30
16006 [Prefix-SID, 100.100.100.6]
Attributes:
Binding SID: 40
Forward Class: 0
On PE-R6
traffic-eng policy
Thu May 7 22:52:22.823 UTC

---------------------
Color: 40, End-point: 100.100.100.5

Name: srte_c_40_ep_100.100.100.5
Status:
22:04:34.231)
Candidate-paths:


Name: srte_c_40_ep_100.100.100.5
Requested BSID: 40
Dynamic (valid)
Metric Type: LATENCY, Path Accumulated Metric: 30
16005 [Prefix-SID, 100.100.100.5]
Attributes:
Binding SID: 40
Forward Class: 0
16.1.4 Instantiating SR-Policy with SR-PCE for Color 50

SR-PCE service helps set up path computation element related configuration
information on devices. SR-PCE describes a set of procedures by which a Path
Computation Client (PCC) can report and delegate control of a policy head-
end. This use case discusses how to instantiate SR-PCE for color 50 on PE-R5
device. For more information on SR-PCE service, see chapter Configuration in
this documentation.
SR-PCE is set up on the Core R2 device. Configure SR-Settings to enable PCC
on all the devices in the network. The policy uses the metric IGP to instantiate
the service. The head-end for the policy is device PE-R5 and the tail-end is PE-
R6.

The following graphic shows the required tasks you must perform for this use
case.

1. Create and verify SR-PCE service on the device.
2. Create and verify SR-Settings to enable PCC settings on all the devices.
3. Create and verify SR-policy with metric IGP for color 50.
4. Verify the policy operations and the path computed by PCE for color 50.
To instantiate SR-policy with SR-PCE for color 50:

1. Create SR-PCE service on core-R2 device.
<sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-
te-pce">
<name>PCE-Core-R2</name>
<node>
<pce>
<disjoint-path/>
<timers>
</timers>
<state-sync>
<ipv4>
</ipv4>
</state-sync>
<backoff>
<ratio>11</ratio>

</backoff>
<segment-routing>
<strict-sid-only/>
<te-latency/>
</segment-routing>
</pce>
</node>
</sr-pce>
</config>
2. Display the plan for the SR-PCE service and verify the service is in the reached
status.
3. Get modifications for the SR-PCE service and verify the configuration is
pushed to the core-R2 device.
sr-pce PCE-Core-R2 action get-modifications outformat cli
message devices {
device Core-R2 {
config {
+ address {
+ ipv4 100.100.100.2;
+ }
+ disjoint-path {
+ }
+ timers {
+ keepalive 20;
+ }
+ state-sync {
+ ipv4 100.100.100.2;
+ }
+ backoff {
+ ratio 11;
+ difference 10;
+ threshold 12;
+ }
+ segment-routing {
+ strict-sid-only;
+ te-latency;
+ }
+ }
}
}
}

4. Create SR-Settings to enable PCC settings on all the devices.

<sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-
tsdn-sr-te-settings">
<name>PCC_SETTINGS</name>
<pcc>
<pce>
<address>
<ipv4>
</ipv4>
</address>
</pce>
<report-all/>
</pcc>
<node>
</node>
<node>
</node>
<node>
</node>
<node>
</node>
<node>
<name>PE-R5</name>
</node>
<node>
<name>PE-R6</name>
</node>
</sr-setting>
</config>
5. Display the plan for SR-Settings and verify the status is reached for all the
devices.
6. Get modifications for SR-Settings to verify the PCC settings is pushed to the
devices.

sr-setting PCC_SETTINGS action get-modifications

message devices {
device Core-R1 {
config {
traffic-eng {
+ pcc {
+ pce {
+ address {
+ ipv4 100.100.100.2 {
+ precedence 1;
+ }
+ }
+ }
+ report-all;
+ }
}
}
}
}
}
devices {
device Core-R2 {
config {
traffic-eng {
+ pcc {
+ pce {
+ address {
+ ipv4 100.100.100.2 {
+ precedence 1;
+ }
+ }
+ }
+ report-all;
+ }
}
}
}
}
}
devices {
device Core-R3 {
config {
traffic-eng {
+ pcc {
+ pce {
+ address {
+ ipv4 100.100.100.2 {
+ precedence 1;
+ }
+ }
+ }
+ report-all;
+ }
}
}
}
}

}
devices {
device Core-R4 {
config {
traffic-eng {
pcc {
pce {
address {
ipv4 100.100.100.2 {
+ precedence 1;
}
}
}
}
}
}
}
}
}
devices {
device PE-R5 {
config {
traffic-eng {
+ pcc {
+ pce {
+ address {
+ ipv4 100.100.100.2 {
+ precedence 1;
+ }
+ }
+ }
+ report-all;
+ }
}
}
}
}
}
devices {
device PE-R6 {
config {
traffic-eng {
+ pcc {
+ pce {
+ address {
+ ipv4 100.100.100.2 {
+ precedence 1;
+ }
+ }
+ }
+ report-all;
+ }
}
}
}
}
}

7. Verify the PCE peer database to ensure PCC is enabled on all the devices in
the network.
admin@ncs# devices device Core-R2 live-status exec show pce ipv4
peer
result
Fri May 8 00:08:52.700 UTC
PCE's peer database:

--------------------
Peer address: 100.100.100.1
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation

State: Up
Capabilities: Stateful, Segment-Routing

State: Up

State: Up

State: Up

State: Up
RP/0/RP0/CPU0:Core-R2#
admin@ncs#
8. Create the SR-policy with metric IGP for color 50 on the PE-R5 device.
sr-policies">
<policy>
<name>SR-Policy-PCE</name>
<head-end>
<name>PE-R5</name>
</head-end>
<color>50</color>
<path>
<dynamic>
<pce/>
</dynamic>
</path>
</policy>
</policies>
</sr-te>
</config>

9. Display the plan status for the SR-TE policy and verify the policy is deployed.
successfully.
10. Get modifications for the SR-policy with PCE for color 50 to verify the policy is
enforced on the device PE-R5.
sr-te cisco-sr-te-cfp-sr-policies:policies policy SR-Policy-PCE action
get-modifications
message devices {
device PE-R5 {
config {
traffic-eng {
+ policy srte_c_50_ep_100.100.100.6 {
+ binding-sid {
+ mpls 25601;
+ }
+ color {
+ value 50;
+ end-point {
+ ipv4 100.100.100.6;
+ }
+ }
+ candidate-paths {
+ preference 100 {
+ dynamic {
+ pcep {
+ }
+ metric {
+ type igp;
+ }
+ }
+ }
+ }
+ }
}
}
}
}
}
11. Verify the SR-TE policy operations. The status of Segment Routing Traffic
Engineering-Policy Admin and Operational must be up. This indicates the
successful instantiation of SR-PCE for color 50.
admin@ncs# devices device Core-R2 live-status exec show pce lsp detail
result
Fri May 8 00:11:26.400 UTC
PCE's tunnel database:

----------------------
PCC 100.100.100.5:
Tunnel Name: cfg_srte_c_50_ep_100.100.100.6_discr_100

LSPs:
LSP[0]:
source 100.100.100.5, destination 100.100.100.6, tunnel ID 3, LSP
ID 1
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 25601
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x3, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Single LSP
State-sync PCE: None
PCC: 100.100.100.5
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 30
SID[0]: Adj, Label 24003, Address: local 20.20.10.1 remote
20.20.10.2
20.20.10.14
20.20.10.26
Computed path: (Local PCE) ------
---------> Sent to PE-R5.
Computed Time: Fri May 08 00:08:22 UTC 2020 (00:03:04 ago)
Metric type: IGP, Accumulated Metric 30
20.20.10.2
20.20.10.14
20.20.10.26
Recorded path:
None
Disjoint Group Information:
None
RP/0/RP0/CPU0:Core-R2#
12. Verify the path computed by PCE for color 50 on the device PE-R5.
admin@ncs# devices device PE-R5 live-status exec show segment-

routing traffic-eng policy color 50
result
Fri May 8 00:13:26.922 UTC

---------------------
Color: 50, End-point: 100.100.100.6
Name: srte_c_50_ep_100.100.100.6
Status:
23:55:36.110)

Candidate-paths:
Name: srte_c_50_ep_100.100.100.6
Requested BSID: 25601
PCC info:
Symbolic name: cfg_srte_c_50_ep_100.100.100.6_discr_100
PLSP-ID: 3
Dynamic (pce 100.100.100.2) (valid) ---------------> Learnt
by PCE
Metric Type: IGP, Path Accumulated Metric: 30
24003 [Adjacency-SID, 20.20.10.1 - 20.20.10.2]
24003 [Adjacency-SID, 20.20.10.13 - 20.20.10.14]
24005 [Adjacency-SID, 20.20.10.25 - 20.20.10.26]
Attributes:
Binding SID: 25601
Forward Class: 0
admin@ncs#

Cisco NSO Transport SDN Function Pack Bundle User Guide Version 1 0 0 PDF

Uploaded by

Copyright:

Available Formats

Cisco NSO Transport SDN Function Pack Bundle User Guide Version 1 0 0 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco NSO Transport SDN Function Pack Bundle User Guide Version 1 0 0 PDF

Uploaded by

Copyright:

Available Formats

Cisco NSO Transport SDN Function Pack

7.3.4 SR-PCE ................................................................................. 58

15.1.5 L2VPN Example Services ................................................... 124

Sl. No. Documentation

Cisco Transport SDN Function Pack Bundle User Guide

3.1 Cisco Network Services Orchestrator - Overview

From a Linux console, invoke the Network Configuration Protocol NETCONF

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

3.2 Cisco NSO Transport SDN Function Pack Bundle - Overview

Cisco Transport SDN Function Pack Bundle User Guide

3.3 T-SDN Function Packs Bundle Architecture

NSO provides Service Provisioning functionality of T-SDN FPs by:

Cisco Transport SDN Function Pack Bundle User Guide

L3VPN allows you to configure:

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

4 SR-TE Core Function Pack

4.1 SR-TE ODN

Cisco Transport SDN Function Pack Bundle User Guide

There are two types of SR-TE policies:

Cisco Transport SDN Function Pack Bundle User Guide

5 Example Function Packs

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

6.1 Creating SR-TE Services

6.1.1 Creating SR-ODN

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

6.1.2 Creating SR-Policies

Cisco Transport SDN Function Pack Bundle User Guide

admin@ncs% run show sr-te cisco-sr-te-cfp-sr-policies:policies policy-

6.2 Creating SR-Settings Services

To create SR-Settings service:

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

admin@ncs% run show sr-setting-plan

6.2.1 Allocating Resources by Using Resource Pools

Cisco Transport SDN Function Pack Bundle User Guide

Sample Payloads – Resource Pools

Service deployment payload

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

The following payload shows an update to the service deployment payload

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

Cisco Transport SDN Function Pack Bundle User Guide

6.2.1.1 Verifying Allocation

The following plan displays a successful allocation.

6.2.1.2 Adding Resources to the Pool

admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback

admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback

Cisco Transport SDN Function Pack Bundle User Guide

admin@ncs% run show sr-setting-plan

6.3 Creating SR-PCE Services

Cisco Transport SDN Function Pack Bundle User Guide

admin@ncs% run show sr-pce-plan

Cisco Transport SDN Function Pack Bundle User Guide