Supported Features

The following are the supported functionalities:

• SRv6 policies with SRv6 uSID segments

• SRv6 policies with PCE-delegated dynamic paths

• SRv6 policies with explicit paths

• SRv6 policies with single or multiple candidate paths (CP)

• SRv6 policies with a single SID list per CP

• SRv6 policies with multiple (weighted ECMP) SID lists per CP

• Path delegation and reporting with PCEPv4

• Path delegation and reporting with PCEPv6

• PCEPv4 and PCEPv6 sessions with different PCEs

• PCEs with PCEP state-sync sessions must be either PCEPv4 or PCEPv6.

• PCEP path delegation with the following optimization objective (metric) types:

  • IGP metric

  • TE metric

  • Delay (latency)

  • Hop-count

• PCEP path delegation with the following constraint types:

  • Affinity (include-any, include-all, exclude-any)

  • Path disjointness (link, node, SRLG, SRLG+node)

    • For path-computation on PCE, configuring both affinity and disjoint-path is not supported.

  • Segment protection-type:

    • Protected-only

    • Protected-preferred

    • Unprotected-only

    • Unprotected-preferred

• SRv6 policy with TI-LFA (protection of the first segment in the segment list at the head-end)

• Steering over SRv6 policies with Automated Steering for the following services:

  • L3 BGP-based services (IPv4 L3VPN, IPv6 L3VPN, IPv4 BGP global, IPv6 BGP global)

Unsupported Features

The following functionalities are not supported:

• SRv6 policy counters

• PCE-initiated SRv6 policies via PCEP

• SRv6 policies with head-end computed dynamic paths

• PCE path delegation with segment-type Flex Algo constraint

• PCEPv4 and PCEPv6 sessions with same PCE

• Steering over SRv6 policies based on incoming BSID (remote automated steering)

• PCC with user-configured PCE groups

• SR-PM delay-measurement over SRv6 policies

• SR-PM liveness detection over SRv6 policies

• L3 services with BGP PIC over SRv6 policies

• SRv6 policy ping

• L2 BGP-based service (EVPN VPWS)

By default, 1K polices are supported. If MPLS tunnels are not configured on the router, use the following commands to get higher SRv6-TE scale:

• If the support for LDPoTE or SRoSR-TE MPLS features are not required, use the following command to configure higher RSVP-TE/SR-TE scale.

  hw-module profile cef te-tunnel highscale-no-ldp-over-te

• If the support for LDPoTE is required but not SRoSR-TE MPLS features, use the following command to configure higher tunnel scale.

  hw-module profile cef te-tunnel highscale-ldp-over-te-no-sr-over-srte

SRv6-TE uses a “policy” to steer traffic through the network. An SRv6-TE policy path is expressed as a list of micro-segments that specifies the path, called a micro-segment ID (uSID) list. Each segment list 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 following the shortest path calculated by the IGP. If a packet is steered into an SRv6-TE policy, the uSID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the uSID list.

An SRv6-TE policy is identified as an ordered list (head-end, color, end-point):

• Head-end – Where the SRv6-TE policy is instantiated

• Color – A numerical value that distinguishes between two or more policies to the same node pairs (Head-end – End point)

• End-point – The destination of the SRv6-TE policy

Every SRv6-TE policy has a color value. Every policy between the same node pairs requires a unique color value.

An SRv6-TE policy uses one or more candidate paths. A candidate path can be made up of a single SID-list or a set of weighted SID-lists (for weighted equal cost multi-path [WECMP]).

A SID list can be either the result of a dynamic path computation by a PCE or a user-configured explicit path. See SRv6-TE Policy Path Types for more information.

SRv6-TE Policy Path Types

The following SRv6-TE policy path types are supported:

SRv6 Flexible Algorithm allows operators to customize IGP shortest path computation according to their own needs. An operator can assign custom SRv6 locators to realize forwarding beyond link-cost-based shortest path. As a result, Flexible Algorithm provides a traffic-engineered path automatically computed by the IGP to any destination reachable by the IGP.

With SRv6 Flexible Algorithm, a PE can advertise BGP service routes (global, VPN) that include the SRv6 locator (Algo 0 or Flex Algo) of the intended transport SLA.

For information about configuring Flexible Algorithm, see Configuring SRv6 IS-IS Flexible Algorithm.

In the example below, the SR domain has 2 network slices. Each slice is assigned a /32 uSID Locator Block.

A slice can be realized with a user-defined Flex-Algo instances (for example, Flex Algo 128 = min-delay)

• Min-Cost Slice — FCBB:BB00/32

• Min-Delay Slice — FCBB:BB01/32

SR node2 gets a Shortest-Path Endpoint uSID (uN) from each slice:

• uN min-cost of Node2 — FCBB:BB00:0002/48

• uN min-delay of Node2 — FCBB:BB01:0002/48

Node2 announces locators via IS-IS:

• FCBB:BB00:0002/48 Algo 0 (min-cost)

• FCBB:BB01:0002/48 Algo 128 (min-delay)

IS-IS in Node1 computes shortest paths for each locator and programs them in the FIB:

Node1 and Node2 are PEs of a common VPN. PEs advertise VPN routes via BGP with different transport SLAs. For example, traffic to a set of prefixes is to be delivered over the min-cost slice, while for another set of prefixes is to be delivered over the min-delay slice. To achieve this, the egress PE’s service route advertisement includes the locator of the intended transport SLA type.

Use-case: VPN over Min-Cost Slice (Control Plane Behavior)

• Intuitive uSID program for routes advertised by Node2:

  • Within the Min-Cost Slice (FCBB:BB00)

  • Follow the shortest-path to Node2 (0002)

  • Execute VPN9 decapsulation function at Node2 (F009)

• Hardware Efficiency

  • Egress PE Node2 processes multiple uSIDs with a single /64 lookup

  • FCBB:BB00:0002:F009/64

Use-case: VPN over Min-Delay Slice (Control Plane Behavior)

• Intuitive uSID program for routes advertised by Node2:

  • Within the Min-Delay Slice (FCBB:BB01)

  • Follow the shortest-path to Node2 (0002)

  • Execute VPN9 decapsulation at Node2 (F009)

• Hardware Efficiency

  • Egress PE 2 processes multiple uSIDs with a single /64 lookup

  • FCBB:BB01:0002:F009/64

Use-case: VPN over Min-Cost Slice (Data Plane Behavior)

1. Ingress PE (Node 1) learns via BGP that prefix 10.2.0.0/24 in VPN9 is reachable via SID FCBB:BB00:0002:F009

2. Node 1 programs the prefix with “VPN Encaps” behavior

3. When receiving traffic with DA IP matching the prefix 10.2.0.0/24 FIB entry, Node 1 encapsulates the incoming packet into IPv6 with DA of FCBB:BB00:0002:F009

   

4. SRv6 allows for seamless deployment where any transit node (SRv6-capable or not) simply routes based on a /48 longest prefix match lookup.

   For example, transit node (Node 3) forwards traffic along the Algo 0 (min-cost) shortest path for the remote prefix FCBB:BB00:0002::/48.

   

5. Egress PE (Node 2) matches local SID FCBB:BB00:0002:F009/64. Node 2 applies “VPN Decaps” behavior into VRF9 by removing the IPv6 encapsulation and looking up the payload’s DA on the corresponding VPN table.

   

Use-case: VPN over Min-Delay Slice (Data Plane Behavior)

1. Ingress PE (Node 1) learns via BGP that prefix 20.2.0.0/24 in VPN9 is reachable via SID FCBB:BB01:0002:F009

2. Node 1 programs the prefix with “VPN Encaps” behavior

3. When receiving traffic with DA IP matching the prefix 20.2.0.0/24 FIB entry, Node 1 encapsulates the incoming packet into IPv6 with DA of FCBB:BB01:0002:F009

4. Transit node (Node 3) forwards traffic along the Algo 128 (min-delay) shortest path for the remote prefix FCBB:BB01:0002::/48.

5. Egress PE (Node 2) matches local SID FCBB:BB01:0002:F009/64. Node 2 applies “VPN Decaps” behavior into VRF9 by removing the IPv6 encapsulation and looking up the payload’s DA on the corresponding VPN table.

Usage Guidelines and Limitations

• The API is supported for SRv6-TE policies.

• The API is not supported on the SR PCE.

SR-TE gRPC API

The SR-TE gRPC API uses the protocol buffers definition interface language (IDL) to manage the lifecycle (creation, modification, deletion) of SR-TE policies signaled by a controller/PCE and programmed at a headend.

The gRPC requests are encoded and sent to the SR-TE headend router (gRPC server) using JSON. The router can invoke the RPC calls defined in the IDL to program the SR-TE policies.

The gRPC service specifications for SR-TE, including the definitions of messages and the data model, are housed in a proto file. This SR-TE gRPC API proto file and a sample client are available in the following Github repository: https://github.com/ios-xr/SR-TE

SR-TE gRPC API proto file provides the following RPCs:

Enabling the SR-TE gRPC API on the Headend Router

Use the following commands to enable the SR-TE gRPC API:

RP/0/RP0/CPU0:ios(config)# grpc
RP/0/RP0/CPU0:ios(config-grpc)# segment-routing 
RP/0/RP0/CPU0:ios(config-grpc-sr)# traffic-eng 
RP/0/RP0/CPU0:ios(config-grpc-sr-te)# policy-service
RP/0/RP0/CPU0:ios(config-grpc-sr-te)# commit

Note	Refer to Use gRPC Protocol to Define Network Operations with Data Models in the Programmability Configuration Guide for Cisco 8000 Series Routers for other gRPC parameters.

Verify

Use the show segment-routing traffic-eng service-api clients command to display the SR-TE gRPC API client and its status:

RP/0/RSP0/CPU0:ios# show segment-routing traffic-eng service-api clients
. . .

Client name: emsd (Protocol type: gRPC)
  Role: Active
  ID: 960268627
  State: Up
  Throttled: No
  Statistics:
    Client ever connected: Yes
    Connected: 00:00:12 (since Wed Nov 15 15:02:14 PST 2023)
    Number of add requests: 0
    Number of delete requests: 0
. . .

Examples

In the following examples, R1 is the SR-TE headend and the gRPC server. The headend router implements the server-side of the gRPC communication, handling requests from gRPC clients.

In these examples, an SR-TE gRPC client written in Python is used to emulate the controller node. These clients send commands to create, modify, or delete SRTE policies, and the headend router executes these commands and returns the responses.

Example 1: Programming an SRv6-TE Policy with Explicit Path via gRPC API

1. Configure the SRv6-TE policy.

   In this example, the SRv6-TE policy uses explicit paths with a segment list. The following JSON file is passed as an input to the SR-TE gRPC client to program an SRv6-TE policy with an explicit path at the head-end router.

   controller:grpc$ more sample_srv6_explicit_path_req.json
   {
    "policies": [
     {
      "key": {
       "color": 6,
       "endpoint": "2001:0:108::1",
       "headend": "2001:0:101::1"
      },
      "CPs": [
       {
        "explicit": [
         {
          "segmentList": {
           "name": "test-srv6",
           "segments": {
            "typeB": [
             "fcbb:bb00:104::",
             "fcbb:bb00:108::"
            ]
           }
          }
         }
        ],
        "preference": 10,
        "dataplane": 1,
        "key": {
         "originatorID": {
          "ASN": 64000,
          "nodeID": "1.1.1.101"
         },
         "discriminator": 100,
         "originatorProtocol": 40
        }
       }
      ],
      "bindingSIDAllocation": 1,
      "srv6BindingSID": {
       "locatorName": "LOC_BEST_EFFORT",
       "behavior": 71
      }
     }
    ]
   }
   
   

   Execute the command/JSON file on the SR-TE gRPC client:

   controller-grpc$ srte_client -u <user> -p <password> --policy-add 
   -j sample_srv6_explicit_path_req.json -a <sr-te-headend-ip-addr>:57400
   Response: ['{"ReturnCode": 0, "Key": {"Color": 6, "Headend": "2001:0:101::1", 
   "Endpoint": "2001:0:108::1"}}']
   

   Note	Observe the console message indicating the policy state is “UP”: RP/0/RP0/CPU0:Nov 15 15:11:23.784 PST: xtc_agent[1304]: %OS-XTC-5-SR_POLICY_UPDOWN : SR policy 'srte_c_6_ep_2001:0:108::1' (color 6, end-point 2001:0:108::1) state changed to UP

2. Verify the configuration.

   Use the following show commands to verify the configuration.

   RP/0/RP0/CPU0:R1# show segment-routing traffic-eng policy color 6
   
   SR-TE policy database
   ---------------------
   
   Color: 6 End-point: 2001:0:108::1
     Name: srte_c_6_ep_2001:0:108::1
     Status:
       Admin: up  Operational: up for 00:01:00 (since Nov 15 15:11:23.784)
     Candidate-paths:
       Preference: 10 (gRPC) (active)
         Requested BSID: dynamic
         PCC info:
           Symbolic name: gRPC_srte_c_6_ep_2001:0:108::1_c_6_ep_2001:0:108::1_discr_100
           PLSP-ID: 1
         Constraints:
           Protection Type: protected-preferred
           Maximum SID Depth: 7 
         Explicit: segment-list grpc_sl_1 (valid)
           Weight: 1, Metric Type: TE
             SID[0]: fcbb:bb00:104::/48
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
             SID[1]: fcbb:bb00:108::/48
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
         SRv6 Information:
           Locator: LOC_BEST_EFFORT
           Binding SID requested: Dynamic
           Binding SID behavior: uB6 (Insert.Red)
     Attributes:
       Binding SID: fcbb:bb00:101:e005::
       Forward Class: Not Configured
       Steering labeled-services disabled: no
       Steering BGP disabled: no
       IPv6 caps enable: yes
       Invalidation drop enabled: no
       Max Install Standby Candidate Paths: 0
   
   

   RP/0/RP0/CPU0:R1# show cef ipv6 fcbb:bb00:101:e005::/64
   
   fcbb:bb00:101:e005::/64, version 927, SRv6 Endpoint uB6 (Insert.Red), internal 0x1000001 0x200 (ptr 0x8b1495e8) [1], 0x400 (0x8a460958), 0x0 (0xa0e205e8)
    Updated Nov 15 15:11:23.786 
    local adjacency to TenGigE0/0/0/0
   
    Prefix Len 64, traffic index 0, precedence n/a, priority 0
     gateway array (0x8a2f3708) reference count 1, flags 0x400000, source rib (7), 0 backups
                   [2 type 3 flags 0x8401 (0x8a396cf8) ext 0x0 (0x0)]
     LW-LDI[type=3, refc=1, ptr=0x8a460958, sh-ldi=0x8a396cf8]
     gateway array update type-time 1 Nov 15 15:11:23.786
    LDI Update time Nov 15 15:11:23.787
    LW-LDI-TS Nov 15 15:11:23.787
    Accounting: Disabled
      via fe80::28a:96ff:feaa:ac00/128, TenGigE0/0/0/0, 8 dependencies, weight 1, class 0, protected, ECMP-backup (Local-LFA) [flags 0x600]
       path-idx 0 bkup-idx 1 NHID 0x0 [0xa0ffa0a0 0x0]
       next hop fe80::28a:96ff:feaa:ac00/128
       SRv6 H.Insert.Red SID-list {fcbb:bb00:104::}
      via fe80::d66a:35ff:fef3:2000/128, TenGigE0/0/0/1, 8 dependencies, weight 1, class 0, protected, ECMP-backup (Local-LFA) [flags 0x600]
       path-idx 1 bkup-idx 0 NHID 0x0 [0xa0ffa190 0x0]
       next hop fe80::d66a:35ff:fef3:2000/128
       SRv6 H.Insert.Red SID-list {fcbb:bb00:104::}
   
       Weight distribution:
       slot 0, weight 1, normalized_weight 1, class 0
       slot 1, weight 1, normalized_weight 1, class 0
       Load distribution: 0 1 (refcount 2)
   
       Hash  OK  Interface                 Address
       0     Y   TenGigE0/0/0/0            fe80::28a:96ff:feaa:ac00
       1     Y   TenGigE0/0/0/1            fe80::d66a:35ff:fef3:2000
   
   

Example 2: Programming an SRv6-TE Policy with Dynamic Path (Delegated to PCE) via gRPC API

1. Configure the SRv6-TE policy.

   In this example, the SRv6-TE policy uses dynamic paths delegated to the PCE.

   The following JSON file is passed as an input to the SR-TE gRPC client to program an SRv6-TE policy with a dynamic path.

   controller:grpc$ more sample_srv6_dynamic_path_req.json
   {
    "policies": [
     {
      "key": {
       "color": 7,
       "endpoint": "2001:0:108::1",
       "headend": "2001:0:101::1"
      },
      "CPs": [
       {
        "dynamic": {
         "delegate": true,
         "ometric": 0
        },
        "preference": 10,
        "dataplane": 1,
        "key": {
         "originatorID": {
          "ASN": 64000,
          "nodeID": "1.1.1.101"
         },
         "discriminator": 100,
         "originatorProtocol": 40
        }
       }
      ],
      "bindingSIDAllocation": 1,
      "srv6BindingSID": {
       "locatorName": "LOC_BEST_EFFORT",
       "behavior": 71
      }
     }
    ]
   }
   

   Execute the command/JSON file on the SR-TE gRPC client:

   controller-grpc$ srte_client -u <user> -p <password> --policy-add 
   -j sample_srv6_dynamic_path_req.json -a <sr-te-headend-ip-addr>:57400 
   Response: ['{"ReturnCode": 0, "Key": {"Color": 7, "Headend": "2001:0:101::1", 
   "Endpoint": "2001:0:108::1"}}']
   

   Note	Observe the console message indicating the policy state is “UP”: RP/0/RP0/CPU0:Nov 15 15:25:23.671 PST: xtc_agent[1304]: %OS-XTC-5-SR_POLICY_UPDOWN : SR policy 'srte_c_7_ep_2001:0:108::1' (color 7, end-point 2001:0:108::1) state changed to UP

2. Verify the configuration.

   Use the following show commands to verify the configuration.

   RP/0/RP0/CPU0:R1# show segment-routing traffic-eng pol color 7
   
   SR-TE policy database
   ---------------------
   
   Color: 7, End-point: 2001:0:108::1
     Name: srte_c_7_ep_2001:0:108::1
     Status:
       Admin: up  Operational: up for 00:01:06 (since Nov 15 15:25:23.671)
     Candidate-paths:
       Preference: 10 (gRPC) (active)
         Requested BSID: dynamic
         PCC info:
           Symbolic name: gRPC_srte_c_7_ep_2001:0:108::1_c_7_ep_2001:0:108::1_discr_100
           PLSP-ID: 3
         Constraints:
           Protection Type: protected-preferred
           Maximum SID Depth: 7 
         Dynamic (pce 2001:0:109::1) (valid)
           Metric Type: TE,   Path Accumulated Metric: 44 
             SID[0]: fcbb:bb00:103::/48 Behavior: uN (PSP/USD) (48)
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
                     Address: 2001:0:103::1
             SID[1]: fcbb:bb00:104::/48 Behavior: uN (PSP/USD) (48)
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
                     Address: 2001:0:104::1
             SID[2]: fcbb:bb00:107::/48 Behavior: uN (PSP/USD) (48)
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
                     Address: 2001:0:107::1
             SID[3]: fcbb:bb00:108::/48 Behavior: uN (PSP/USD) (48)
                     Format: f3216
                     LBL:32 LNL:16 FL:0 AL:80
                     Address: 2001:0:108::1
         SRv6 Information:
           Locator: LOC_BEST_EFFORT
           Binding SID requested: Dynamic
           Binding SID behavior: uB6 (Insert.Red)
     Attributes:
       Binding SID: fcbb:bb00:101:e006::
       Forward Class: Not Configured
       Steering labeled-services disabled: no
       Steering BGP disabled: no
       IPv6 caps enable: yes
       Invalidation drop enabled: no
       Max Install Standby Candidate Paths: 0
   
   

   RP/0/RP0/CPU0:R1# show cef ipv6 fcbb:bb00:101:e006::/64
   
   fcbb:bb00:101:e006::/64, version 936, SRv6 Endpoint uB6 (Insert.Red), internal 0x1000001 0x200 (ptr 0x8b149100) [1], 0x400 (0x8a460918), 0x0 (0xa0e20598)
    Updated Nov 15 15:25:23.672 
    local adjacency to TenGigE0/0/0/1
   
    Prefix Len 64, traffic index 0, precedence n/a, priority 0
     gateway array (0x8a2f3618) reference count 1, flags 0x500000, source rib (7), 0 backups
                   [2 type 3 flags 0x8401 (0x8a396e58) ext 0x0 (0x0)]
     LW-LDI[type=3, refc=1, ptr=0x8a460918, sh-ldi=0x8a396e58]
     gateway array update type-time 1 Nov 15 15:25:23.672
    LDI Update time Nov 15 15:25:23.672
    LW-LDI-TS Nov 15 15:25:23.672
    Accounting: Disabled
      via fe80::28a:96ff:feaa:ac00/128, TenGigE0/0/0/0, 10 dependencies, weight 1, class 0, backup (Local-LFA) [flags 0x300]
       path-idx 0 NHID 0x0 [0x8a0c5a00 0x0]
       next hop fe80::28a:96ff:feaa:ac00/128
       local adjacency
       SRv6 H.Insert.Red SID-list {fcbb:bb00:103:104:107::}
      via fe80::d66a:35ff:fef3:2000/128, TenGigE0/0/0/1, 10 dependencies, weight 1, class 0, protected [flags 0x400]
       path-idx 1 bkup-idx 0 NHID 0x0 [0xa0ffa190 0x0]
       next hop fe80::d66a:35ff:fef3:2000/128
       SRv6 H.Insert.Red SID-list {fcbb:bb00:103:104:107::}
   
       Weight distribution:
       slot 0, weight 1, normalized_weight 1, class 0
       Load distribution: 0 (refcount 2)
   
       Hash  OK  Interface                 Address
       0     Y   TenGigE0/0/0/1            fe80::d66a:35ff:fef3:2000
   
   

   RP/0/RP0/CPU0:R1# show segment-routing traffic-eng forwarding pol color 7
   
   SR-TE Policy Forwarding database
   --------------------------------
   
   Color: 7, End-point: 2001:0:108::1
     Name: srte_c_7_ep_2001:0:108::1
     Binding SID: fcbb:bb00:101:e006::
     Active LSP:
       Candidate path:
         Preference: 10 (gRPC)
       Segment lists:
         SL[0]:
           Name: dynamic
           SL ID: 0xa000002
           Switched Packets/Bytes: ?/?
           Paths:
             Path[0]:
               Outgoing Interfaces: TenGigE0/0/0/0
               Next Hop: fe80::28a:96ff:feaa:ac00
               FRR Pure Backup: Yes
               ECMP/LFA Backup: Yes
               SID stack (Top -> Bottom): {fcbb:bb00:103::/48, fcbb:bb00:104::/48, fcbb:bb00:107::/48}
             Path[1]:
               Outgoing Interfaces: TenGigE0/0/0/1
               Next Hop: fe80::d66a:35ff:fef3:2000
               FRR Pure Backup: No
               ECMP/LFA Backup: No
               SID stack (Top -> Bottom): {fcbb:bb00:103::/48, fcbb:bb00:104::/48, fcbb:bb00:107::/48}
   
     Policy Packets/Bytes Switched: ?/?
   

Example 3: Delete the Policy

1. On the cRPC client, run the following command to delete the policy configuration:

   controller-grpc$ srte_client -u <user> -p <password> --policy-delete 
   -j sample_srv6_explicit_path_req.json -a <sr-te-headend-ip-addr>:57400
   Response: ['{"ReturnCode": 0, "Key": {"Color": 6, "Headend": "2001:0:101::1", 
   "Endpoint": "2001:0:108::1"}}']
   
   controller-grpc$ srte_client -u <user> -p <password> --policy-delete 
   -j sample_srv6_explicit_path_req.json -a <sr-te-headend-ip-addr>:57400
   Response: ['{"ReturnCode": 0, "Key": {"Color": 7, "Headend": "2001:0:101::1", 
   "Endpoint": "2001:0:108::1"}}']
   

   Note

   Observe the console message indicating the policy state is “DOWN”: RP/0/RP0/CPU0:Nov 15 15:30:14.180 PST: xtc_agent[1304]: %OS-XTC-5-SR_POLICY_UPDOWN : SR policy 'srte_c_6_ep_2001:0:108::1' (color 6, end-point 2001:0:108::1) state changed to DOWN (path invalidated) RP/0/RP0/CPU0:Nov 15 15:30:27.181 PST: xtc_agent[1304]: %OS-XTC-5-SR_POLICY_UPDOWN : SR policy 'srte_c_7_ep_2001:0:108::1' (color 7, end-point 2001:0:108::1) state changed to DOWN (path invalidated)

2. Verify the delete operation.

   RP/0/RSP0/CPU0:ios# show segment-routing traffic-eng service-api clients
   
   Client name: emsd (Protocol type: gRPC)
     Role: Active
     ID: 440080357
     State: Up
     Throttled: No
     Statistics:
       Client ever connected: Yes
       Connected: 00:28:00 (since Wed Nov 15 15:02:14 PST 2023)
       Number of add requests: 2
       Number of delete requests: 2