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
   

Liveness Monitoring

• SR PM Liveness probes are performed over Working and Protect candidate paths.

• TWAMP Light (RFC 5357) is used for performance measurement and liveness monitoring.

• Separate PM liveness monitoring sessions are created for working and protect candidate-paths.

• Independent PM sessions are created at both endpoints of the SR Policy.

• Loopback measurement-mode (timestamps t1/t4) is used for liveness monitoring. Probe packets are not punted on the responder node. Round-trip delay is computed as (t4 – t1).

• From headend router 1, PM probe query packets are sent with forward and reverse (7->3->2->1) direction paths of the SR Policy’s candidate-path in the header of the probe packet. Similarly, PM probe query packets are sent along the Protect path.

• For liveness monitoring:

  • Liveness is declared UP as soon as one probe packet is received back on all segment-lists of the candidate-path.

  • Liveness failure is detected when last N (user-configured value) consecutive probe packets are lost on any segment-list.

  • Fault in the forward and reverse direction of the segment-list (co-routed path) triggers liveness failure notification to SRTE and FIB. FIB triggers protection switchover upon PM notification (running on high priority thread).

Configuration

• In this example, an SR-TE policy foo is created on the headend router and path-protection is enabled for the policy.

RP/0/RSP0/CPU0:ios# configure 
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng policy foo 
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# color 10 end-point ipv4 192.168.0.3 
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# path-protection 
RP/0/RSP0/CPU0:ios(config-sr-te-path-pref-protection)#exit 

• Under candidate-paths, the Protect and Working paths are specified through explicit segment lists.

• The Protect path’s preference is 50, and it is lower than the Working path preference of 100. The forward (1->4->5->6->7) and reverse (7->6->5->4->1) Protect paths, and the forward (1->2->3->7) and reverse (7->3->2->1) Working paths are enabled as explicit segment lists.

• When the Working path is invalid, the Protect path becomes active. After the Working path has recovered, the Protect path remains active until the default lock duration (of 300 seconds) expires. You can configure a different lock duration using the lock duration command.

  The duration range is 0 (disabled) to 3000 seconds. If the lock duration is 0 (disabled), then the Working path becomes active as soon as it recovers. If the duration is not specified, the Protect path remains active.

RP/0/RSP0/CPU0:ios(config-sr-te-policy)# candidate-paths 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-path)#preference 50 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-path-pref)#lock duration 30 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-path-pref)# explicit segment-list sl-protect-fwd 

Type Exit three times to go to the SR-TE policy configuration mode.

RP/0/RSP0/CPU0:ios(config-sr-te-policy)#candidate-paths 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-path)#preference 100 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-path-pref)# explicit segment-list sl-working-fwd 
RP/0/RSP0/CPU0:ios(config-sr-te-pp-info)# commit 

Working and Protect Segment Lists Configuration

Configure explicit segment lists for the candidate paths.

Note

Segment lists must use only unprotected (dynamic or manual) Adjacency SID and BSIDs (as non-first-SID). RP/0/RSP0/CPU0:ios# configure RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng RP/0/RSP0/CPU0:ios(config-sr-te)# segment-list sl-working-fwd RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 1 mpls label 24000 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 2 mpls label 24004 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# exit RP/0/RSP0/CPU0:ios(config-sr-te)# segment-list sl-working-bck RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 1 mpls label 24002 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 2 mpls label 24006 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# exit RP/0/RSP0/CPU0:ios(config-sr-te)# segment-list sl-protect-fwd RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 1 mpls label 24000 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 2 mpls label 30201 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# exit RP/0/RSP0/CPU0:ios(config-sr-te)# segment-list sl-protect-bck RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 1 mpls label 24002 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# index 2 mpls label 30201 RP/0/RSP0/CPU0:ios(config-sr-te-sl)# commit

Performance Measurement Configuration For SR-TE Policy

• Enable SR-TE policy specific performance measurement configurations.

• Create a liveness profile for the Working and Protect paths.

RP/0/RSP0/CPU0:ios# configure 
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng policy foo 
RP/0/RSP0/CPU0:ios(config-sr-te-policy)#performance-measurement 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)#liveness-detection 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile backup name profile-PROTECT 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile name profile-WORKING 

• The default Invalidation action is Down and it triggers path protection switching. The other action is None, which is enabled here.

RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)#invalidation-action none 
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)#commit 

Performance Measurement Global Profile Configuration

• Create a Working candidate path liveness profile.

RP/0/RSP0/CPU0:ios(config)#performance-measurement 
RP/0/RSP0/CPU0:ios(config-perf-meas)#liveness-profile sr-policy name profile-WORKING 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# measurement-mode loopback 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tx-interval 30000 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# commit 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection multiplier 4 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# commit 

Type Exit to access the Performance Measurement config mode.

• Create a Protect candidate path liveness profile.

RP/0/RSP0/CPU0:ios(config-perf-meas)# liveness-profile sr-policy name profile-PROTECT 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# measurement-mode loopback 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tx-interval 100000 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# commit 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection multiplier 3 
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# commit 

Verification

Use the show segment-routing traffic-eng policy candidate-path command to display Working and Protect candidate-path details.

RP/0/RSP0/CPU0:ios# show segment-routing traffic-eng policy candidate-path name foo 
 
SR-TE policy database
---------------------

Color: 10, End-point: 192.168.0.3s
  Name: srte_c_10_ep_192.168.0.3
  Status:
    Admin: up  Operational: Up for 00:11:55 (since Dec 15 07:02:08.709)
  Candidate-paths:
    Preference: 100 (configuration) (active) 
      Name: foo
      Requested BSID: dynamic
        Protection Type: protected-preferred 
        Maximum SID Depth: 10 
      Explicit: segment-list sl-working-fwd (active) 
        Weight: 1, Metric Type: TE
          24000
          24004
      Protection Information:
        Role: WORKING 
        Path Lock: Timed
        Lock Duration: 300(s) 
    Preference: 50 (configuration) (active) 
      Name: foo
      Requested BSID: dynamic
        Protection Type: protected-preferred 
        Maximum SID Depth: 10 
      Explicit: segment-list sl-protect-fwd (active) 
        Weight: 1, Metric Type: TE
          24000
          30201
      Protection Information:
        Role: PROTECT 
        Path Lock: Timed
        Lock Duration: 30(s) 
 ..

Example

The following output shows the BGP-LU routes learned at the head-end (PE1 in the illustration above). Consider the IP prefix 1.1.1.4/32. A BGP-LU local label is assigned from the SRGB with a prefix SID index of 4, resulting in the value 16004. Additionally, the classic BGP-LU upstream neighbor (P2) advertises an outgoing label of 78000 for this IP prefix.

RP/0/RP0/CPU0:R1# show bgp ipv4 unicast labels

BGP router identifier 1.1.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 13
BGP main routing table version 13
BGP NSR Initial initsync version 6 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop        Rcvd Label      Local Label

*> 1.1.1.1/32         0.0.0.0         nolabel         3
*> 1.1.1.2/32         10.1.2.2        3               24007
*> 1.1.1.3/32         10.1.2.2        78005           24002
*> 1.1.1.4/32         10.1.2.2        78000           16004
*> 1.1.1.5/32         10.1.2.2        78002           16005
*> 1.1.1.6/32         10.1.2.2        78001           16006

...

RP/0/RP0/CPU0:R1# show bgp ipv4 labeled-unicast 1.1.1.4/32

BGP routing table entry for 1.1.1.4/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 74          74
    Local Label: 16004
Last Modified: Sep 29 19:52:18.155 for 00:07:22
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.2 
  3
    10.1.2.2 from 10.1.2.2 (1.1.1.2)
      Received Label 78000
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 74
      Origin-AS validity: not-found
      Label Index: 4

The following output shows the corresponding label forwarding entry for BGP prefix SID 16004 with corresponding outgoing label and outgoing interface.

RP/0/RP0/CPU0:R1# show mpls forwarding labels 16002

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
16004  78000       SR Pfx (idx 2)     Te0/0/0/0    10.1.2.2        44

The configuration below depicts an SR policy (color 100 and end-point 1.1.1.6) with an explicit path to PE6 using the BGP prefix SID of transit LSR node 4 (16004) as its first segment followed by the BGP prefix SID of PE6 (16006).

RP/0/RP0/CPU0:R1# configure
RP/0/RP0/CPU0:R1(config)# segment-routing
RP/0/RP0/CPU0:R1(config-sr)# traffic-eng
RP/0/RP0/CPU0:R1(config-sr-te)# segment-list SL-R4-R6
RP/0/RP0/CPU0:R1(config-sr-te-sl)# index 10 mpls label 16004
RP/0/RP0/CPU0:R1(config-sr-te-sl)# index 20 mpls label 16006
RP/0/RP0/CPU0:R1(config-sr-te-sl)# exit

RP/0/RP0/CPU0:R1(config-sr-te)# policy POL-to-R6
RP/0/RP0/CPU0:R1(config-sr-te-policy)# color 100 end-point ipv4 1.1.1.6
RP/0/RP0/CPU0:R1(config-sr-te-policy)# candidate-paths
RP/0/RP0/CPU0:R1(config-sr-te-policy-path)# preference 100
RP/0/RP0/CPU0:R1(config-sr-te-policy-path-pref)# explicit segment-list SL-R4-R6

RP/0/RP0/CPU0:R1# show running-configuration

segment-routing
 traffic-eng
  segment-list SL-R4-R6
   index 10 mpls label 16004
   index 20 mpls label 16006
  !
  policy POL-to-R6
   color 100 end-point ipv4 1.1.1.6
   candidate-paths
    preference 100
     explicit segment-list SL-R4-R6
     !
    !
   !
  !
 !
!

The following output depicts the forwarding information for the SR policy including the outgoing interface and outgoing label stack.

Observe how the first segment configured (MPLS label 16004) is replaced in the forwarding with the label advertised by the BGP-LU neighbor of the SRTE head-end (MPLS label value 78000).

RP/0/RP0/CPU0:R1# show segment-routing traffic-eng forwarding policy color 100

SR-TE Policy Forwarding database
--------------------------------

Color: 100, End-point: 1.1.1.6
  Name: srte_c_100_ep_1.1.1.6
  Binding SID: 24006
  Active LSP:
    Candidate path:
      Preference: 100 (configuration)
      Name: POL-to-R6
    Local label: 24005
    Segment lists:
      SL[0]:
        Name: SL-R4-R6
        Switched Packets/Bytes: 100/10000
          [MPLS -> MPLS]: 100/10000
        Paths:
          Path[0]:
            Outgoing Label: 78000
            Outgoing Interfaces: TenGigE0/0/0/0
            Next Hop: 10.1.2.2
            Switched Packets/Bytes: 100/10000
              [MPLS -> MPLS]: 100/10000
            FRR Pure Backup: No
            ECMP/LFA Backup: No
            Internal Recursive Label: Unlabelled (recursive)
            Label Stack (Top -> Bottom): { 78000, 16006 }

  Policy Packets/Bytes Switched: 100/9600

With the SR-TE policy installed, the head-end can apply SR-TE automated steering principles when programming BGP service overlay routes.

In the following output, BGP prefix 10.0.0.0/8 with next-hop 1.1.1.6 and color 100 is automatically steered over the SR policy configured above (color 100 and end-point 1.1.1.6).

RP/0/RP0/CPU0:R1# show bgp

BGP router identifier 1.1.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 13
BGP main routing table version 13
BGP NSR Initial initsync version 6 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path

. . .

*> 10.0.0.0/8        1.1.1.6 C:100            0             0 3 i

Configuration Example

/* Enter the SR-TE configuration mode and create the SR policy. This example corresponds to a local SR policy with an explicit path. */
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list sample-sid-list
Router(config-sr-te-sl)# index 10 address ipv4 10.1.1.7
Router(config-sr-te-sl)# index 20 address ipv4 10.1.1.2
Router(config-sr-te-sl)# exit
Router(config-sr-te)# policy sample_policy
Router(config-sr-te-policy)# color 1000 end-point ipv4 10.1.1.2
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list sample-sid-list 
Router(config-sr-te-pp-info)# end

/* Configure LDP over an SR policy */
Router(config)# mpls ldp
Router(config-ldp)# address-family ipv4
Router(config-ldp-af)# neighbor sr-policy srte_c_1000_ep_10.1.1.2 targeted  
Router(config-ldp-af)#

Note	Do one of the following to configure LDP discovery for targeted hellos: Active targeted hellos (SR policy head end): mpls ldp interface GigabitEthernet0/0/0/0 ! ! Passive targeted hellos (SR policy end-point): mpls ldp address-family ipv4 discovery targeted-hello accept ! !

Running Configuration

segment-routing
 traffic-eng
  segment-list sample-sid-list
   index 10 address ipv4 10.1.1.7
   index 20 address ipv4 10.1.1.2
  !
  policy sample_policy
   color 1000 end-point ipv4 10.1.1.2
   candidate-paths
    preference 100
     explicit segment-list sample-sid-list
     !
    !
   !
  !
 !
!

mpls ldp
 address-family ipv4
  neighbor sr-policy srte_c_1000_ep_10.1.1.2 targeted
  discovery targeted-hello accept
 !
!

Verification

Router# show mpls ldp interface brief
Interface       VRF Name            Config Enabled IGP-Auto-Cfg TE-Mesh-Grp cfg
--------------- ------------------- ------ ------- ------------ ---------------
Te0/3/0/0/3     default             Y      Y       0            N/A
Te0/3/0/0/6     default             Y      Y       0            N/A
Te0/3/0/0/7     default             Y      Y       0            N/A
Te0/3/0/0/8     default             N      N       0            N/A
Te0/3/0/0/9     default             N      N       0            N/A
srte_c_1000_    default             Y      Y       0            N/A


Router# show mpls ldp interface
Interface TenGigE0/3/0/0/3 (0xa000340)
   VRF: 'default' (0x60000000)
   Enabled via config: LDP interface
Interface TenGigE0/3/0/0/6 (0xa000400)
   VRF: 'default' (0x60000000)
   Enabled via config: LDP interface
Interface TenGigE0/3/0/0/7 (0xa000440)
   VRF: 'default' (0x60000000)
   Enabled via config: LDP interface
Interface TenGigE0/3/0/0/8 (0xa000480)
   VRF: 'default' (0x60000000)
   Disabled:
Interface TenGigE0/3/0/0/9 (0xa0004c0)
   VRF: 'default' (0x60000000)
   Disabled:
Interface srte_c_1000_ep_10.1.1.2 (0x520)
   VRF: 'default' (0x60000000)
   Enabled via config: LDP interface


Router# show segment-routing traffic-eng policy color 1000

SR-TE policy database
---------------------

Color: 1000, End-point: 10.1.1.2
  Name: srte_c_1000_ep_10.1.1.2
  Status:
    Admin: up  Operational: up for 00:02:00 (since Jul  2 22:39:06.663)
  Candidate-paths:
    Preference: 100 (configuration) (active)
      Name: sample_policy
      Requested BSID: dynamic
      PCC info:
        Symbolic name: cfg_sample_policy_discr_100
        PLSP-ID: 17
      Explicit: segment-list sample-sid-list (valid)
        Weight: 1, Metric Type: TE
          16007 [Prefix-SID, 10.1.1.7]
          16002 [Prefix-SID, 10.1.1.2]
  Attributes:
    Binding SID: 80011
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: yes


Router# show mpls ldp neighbor 10.1.1.2 detail

Peer LDP Identifier: 10.1.1.2:0
  TCP connection: 10.1.1.2:646 - 10.1.1.6:57473
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 421/423; Downstream-Unsolicited
  Up time: 05:22:02
  LDP Discovery Sources:
    IPv4: (1)
      Targeted Hello (10.1.1.6 -> 10.1.1.2, active/passive)
    IPv6: (0)
  Addresses bound to this peer:
    IPv4: (9)
      10.1.1.2       2.2.2.99       10.1.2.2       10.2.3.2
      10.2.4.2       10.2.22.2      10.2.222.2     10.30.110.132
      11.2.9.2
    IPv6: (0)
  Peer holdtime: 180 sec; KA interval: 60 sec; Peer state: Estab
  NSR: Disabled
  Clients: LDP over SR Policy
  Capabilities:
    Sent:
      0x508  (MP: Point-to-Multipoint (P2MP))
      0x509  (MP: Multipoint-to-Multipoint (MP2MP))
      0x50a  (MP: Make-Before-Break (MBB))
      0x50b  (Typed Wildcard FEC)
    Received:
      0x508  (MP: Point-to-Multipoint (P2MP))
      0x509  (MP: Multipoint-to-Multipoint (MP2MP))
      0x50a  (MP: Make-Before-Break (MBB))
      0x50b  (Typed Wildcard FEC)