SR Circuit Style Manager (CSM)

Circuit Style SR-TE Important Notes

This topic outlines the scope of Crosswork's support for Circuit Style SR-TE policies, including requirements and constraints on the policy attribute values set in each Circuit Style SR-TE policy and the processing logic followed during path reversions.


Note

Role-based Access Control (RBAC) and task permissions have been introduced in this release. To provision a Circuit Style SR-TE policy, you must have write-access to the head-end device based on Device Access Groups and assigned roles. Only Circuit Style SR-TE admin users can modify Circuit Style SR-TE configuration settings. For more information on RBAC and user roles, see the "Cisco Crosswork Network Controller Administration Guide".

Policy Attribute Constraints

You set policy attribute values when you create a Circuit Style SR-TE policy using either the device's command line interface or Cisco Crosswork Network Controller. You can also change them later.

The table below describes the requirements for each attribute and how changes affect them. It is important to understand that all the attributes described in the table below act as constraints. Each corresponds to elements of the configuration that Cisco Crosswork uses to govern how Circuit-Style path hops are computed. Each value is effectively a path computation or optimization constraint since it either specifies a required property of a path or excludes possible choices for that path.

Table 1. Circuit Style SR-TE Policy Attribute Values and Constraints

Attribute

Description

Policy Path Protection

The path protection constraint is required for both sides of a Circuit Style SR-TE policy.

Bandwidth Constraint

The bandwidth constraint is required and must be the same on both sides of a Circuit Style SR-TE policy. Bandwidth changes can be made to existing policies with these effects:

  • Once you configure the new bandwidth on both sides, Crosswork will evaluate the path. This will not result in a recomputed path.

  • If the new bandwidth is higher, Crosswork checks the existing path to ensure sufficient resources. If all currently delegated paths can accommodate the new bandwidth, Crosswork returns the same path with the new bandwidth value, indicating to the path computation client (PCC) that it was successful. If any current paths cannot accommodate the new bandwidth, it returns the old bandwidth value, indicating that it was unsuccessful. This evaluation will only be retried if the bandwidth is changed again.

  • If the bandwidth is lower, Crosswork returns the same path with the new bandwidth value to indicate to the PCC that it was successful.

When you view the policy details, the user interface shows both the requested and reserved bandwidth under each candidate path. These values can differ if the requested bandwidth is increased but there is insufficient available CS pool bandwidth along one or more paths.

Candidate Paths and Roles

The Working path is defined as the highest preference Candidate Path (CP).

The Protect path is defined as the CP of the second highest preference.

The Restore path is defined as the lowest preference CP. The headend must have backup-ineligible configured.

CPs of the same role in each direction must have the same CP preference.

Bi-Directional

All paths must be configured as co-routed.

Paths of the same role on both sides must have the same globally unique bi-directional association ID.

Disjointness

Working and Protect paths on the same PCC must be configured with a disjointness constraint using the same disjoint association ID and disjointness type.

The disjointness association ID for a Working and Protect path pair in one direction must be unique when compared with the corresponding pair in the opposite direction.

Only the Node and Link disjoint types are supported. The disjoint type used must be the same in both directions of the same policy.

The Restore path must not have a disjointness constraint set.

Crosswork follows strict fallback behavior for all Working and Protect path disjointness computations. This means that if node type disjointness is configured but no path is available, Crosswork makes no automatic attempt to compute a less restrictive link type disjoint path.

Metric Type

Only the TE, IGP, Hop count, and Latency metric types are supported. The metric type must match Working, Protect and Restore paths in both directions.

Segment Constraints

All Working, Protect, and Restore paths must have the following segment constraints:

  • protection unprotected-only

  • adjacency-sid-only

To ensure persistency through link failures, configure static adjacency SIDs on all interfaces that might be used by Circuit Style policies.

Unsupported Configurations

The following configurations are not supported:

  • Metric-bounds

  • SID-Algo constraints

  • Partial recovery is not supported 7.8.x.

  • State-sync configuration between PCEs of a high-availability pair. These are not required with Circuit Style SR-TE policies. Use of this feature may result in degraded performance.

  • Multiple Circuit Style SR-TE policies between the same nodes with the same color but different endpoint IPs.

Supported Policy Changes

The following constraints may be modified for an operationally "up" Circuit Style SR-TE policy that has been previously delegated:

  • Metric type

  • Disjoint type

  • MSD

  • Affinities

Once configuration changes are consistent across all CPs and both PCCs (for example: the new metric type is the same for all CPs and both sides), Crosswork will initiate a recompute, which can result in new Working, Protect, and Restore paths.

During any transitory period in which configurations are not in sync between paths on the same PCC or between PCCs, no path updates are sent to the PCCs.

Unsupported Policy Changes

The following configuration changes to a previously delegated and operationally "up" Circuit Style SR-TE policy are not supported:

  • CP preference

  • Disjoint Association ID

  • Bi-directional Association ID

To change these configurations for an existing policy, you must first shut down the policy on both sides, make the change (complying with restrictions as detailed above in terms of consistency), and then "no shut" the policy.

Path Computation

Crosswork computes paths for circuit style policies only after a complete bi-directional, path-protected set of candidate paths has been delegated, including Working and Protect paths on both sides. In cases where there is insufficient bandwidth, and a path cannot be found, SR Circuit Style Manager will continue to retry after 30 minutes until a solution is found or if Circuit Style SR-TE is disabled.

Crosswork computes the Restore path only after the Working and Protect paths are down. The SR Circuit Style Managerfeature pack configuration interface provides a configurable delay timer to control how long to wait after Restore paths are delegated from both sides before computing the path. This delay allows topology and SR policy state changes to fully propagate to Crosswork in cases where these changes triggered the Restore path delegation.

Automatic re-optimization is not supported for any paths based on changes in topology, LSP state, or any periodic event. Path computation is supported for Intra/Inter-area/Level and Intra/Inter IGP Domain (same AS). Path computation Inter-AS is not supported.

Reversion Behavior

Reversion behavior is controlled by the configuration of the WTR lock timer option under the Protect and Revert paths (it is not relevant for the Working path):

  • No lock configuration: Revert after a default 5-minute lock

  • Lock with no duration specified: No reversion

  • Lock duration <value>: Revert after the specified number of seconds

Reversion Logic

Path reversion depends on the initial state of the Working, Protect, and Restore paths and the events affecting each path. The scenarios in the following table provide examples of typical reversion behavior.

Table 2. Path Reversion Scenarios

Initial State

Events

Behavior

Working path is down, Protect path is up/active

Working path comes back up

  1. Working path recovers to up/standby state.

  2. Each PCC moves the Working path to active after the WTR timer expires.

  3. Protect path moves to up/standby.

Working path is down, Protect path is down, Restore path is up/active

Working path comes back up, then Protect path comes back up

  1. Working path recovers and goes to up/active state

  2. Restore path is removed

  3. Protect path recovers and goes to up/standby

Working path is down, Protect path is down, Restore path is up/active

Protect path comes back up, then Working path comes back up

On side A: The Working path failure is local (the first Adj SID in the SegList is invalid):

  1. Protect path recovers and goes to up/active.

  2. Restore path is removed.

  3. Working path recovers and goes to up/standby.

  4. Each PCC moves the Working path to active after the WTR timer expires, Protect path goes to up/standby.

On side Z: Working path failure is remote (first Adj SID in SegList is valid):

  1. Protect path recovers but is not brought up, Restore path remains up/active.

  2. Working path recovers and goes up/active.

  3. Restore path is removed.

  4. Protect path goes to up/standby.

Workflow for Setting Up CS SR-TE Policy Visualization

The following tasks are necessary to start visualizing Circuit Style SR-TE policies in the topology map:

Table 3. Tasks to Complete to Start Visualizing Circuit Style SR-TE Policies
Step Action

1. Enable the SR Circuit Style Manager (CSM) feature pack.

From the main menu, choose Services & Traffic Engineering > Traffic Engineering > Circuit Style SR-TE > Configuration.

Follow the steps in Enable SR Circuit Style Manager.

2. Configure CS SR policies on the devices.

Note

 

If you do this step before enabling the Circuit Style SR-TE feature pack, then the CS SR policies will appear operationally down.

You can configure CS SR policies using one of the following methods:

3. Verify that the CS SR policies appear in the SR Policy table.
From the main menu, select Traffic Engineering > Traffic Engineering > SR-MPLS > Circuit style.
Select Circuit Style Tab

The SR Policy table now shows a filtered list containing only CS SR policies.

4. Verify that the reserved bandwidth pool settings you defined in Step 1 are configured properly.

Click on a CS SR node or policy and navigate to the Link Details > Traffic engineering page (see Review Circuit Style SR-TE Policy Bandwidth Utilization). From the Circuit style section, view the reserved bandwidth pool size. You can also view current Circuit Style SR-TE bandwidth utilization and how much is still available for use.

Enable SR Circuit Style Manager

To manage and visualize Circuit Style SR-TE policies on the topology map, you must first enable SR Circuit Style Manager (CSM) and set bandwidth reservation settings.

When enabled, CSM computes the best failover bidirectional paths with the requested bandwidth and other constraints defined in the Circuit Style SR policy configuration between two nodes.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Circuit Style SR-TE > Configuration.

Step 2

Toggle the Enable switch to True.

Step 3

Enter the required bandwidth pool size and threshold information. The following list describes additional field information. See also What Happens When Bandwidth Reservation Settings are Exceeded?.

Field Description

Basic

Link CS BW Pool Size

The percentage of each link's bandwidth reservable for Circuit Style SR-TE policies.

Link CS BW Min Threshold

The Link CS BW Pool utilization percentage beyond which a threshold crossing event notification will be generated.

Advanced

Validation Interval

This is the interval that CSM policy will wait before the bandwidth that is reserved for an undelegated policy is returned to the Circuit Style SR-TE policy bandwidth Pool.

Timeout

The duration until which CSM will wait for the delegation request, to generate a notification.

Restore Delegation Delay

The duration until which CSM will pause before processing a restore path delegation.

Step 4

Click Commit Changes to save the configuration. After enabling CSM, you must create Circuit Style SR policy configurations either manually on the device (see Configure Circuit Style SR Policies) or through Cisco Crosswork Network Controller .

Configure Circuit Style SR Policies

A Circuit Style SR policy configuration must include the destination endpoint, the amount of requested bandwidth, and the bidirectional attribute (see Circuit Style SR-TE Important Notes for additional requirements or notable constraints). The configuration should also include a Performance Measurement Liveness (PM) profile. A PM profile enables proper detection of candidate path liveness and effective path protection. PCCs do not validate past the first SID, so without PM, the path protection will not occur if the failure in the Circuit Style SR policy candidate path is not the first hop in the segment list. For more information, see Configuring SR Policy Liveness Monitoring.

This section provides guidance on how to manually configure a Circuit Style SR policy and a Performance Measurement Liveness (PM) profile on a device.

Procedure

Step 1

If applicable, enable the hardware module on the device for PM configuration.

Example:

hw-module profile offload 4

reload location all

Step 2

Configure the PM profile.

Example:

performance-measurement
 liveness-profile sr-policy name CS-active-path
  probe
   tx-interval 3300
  !
npu-offload enable   !! Required for hardware Offload only
  !
 !
 liveness-profile sr-policy name CS-protect-path
  probe
   tx-interval 3300
  !

npu-offload enable   !! Required for hardware Offload only
  !
 !
!

Step 3

Configure the Circuit Style SR policy with the PM profile. All configurations shown in the example are required in order for CSM to manage the Circuit Style SR-TE policy. Entries that are defined by the user are italicized. See Circuit Style SR-TE Important Notes for additional requirements or notable constraints.

Example:

segment-routing
 traffic-eng
  policy cs1-cs4

   performance-measurement
    liveness-detection
     liveness-profile backup name CS-protect      !! Name must match liveness profile defined for Protect path
     liveness-profile name CS-active               !! Name must match liveness profile defined for Active path
    !
   !
   bandwidth 10000
   color 1000 end-point ipv4 192.168.20.4
   path-protection
   !
   candidate-paths
    preference 10
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     backup-ineligible
     !

     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
     !
     bidirectional
      co-routed
      association-id 1010
     !
    !
    preference 50
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 1050
     !
    !
    preference 100
     dynamic
      pcep
      !
      metric
       type igp
      !
     !
     constraints
      segments
       protection unprotected-only
       adjacency-sid-only
      !
      disjoint-path group-id 3 type node
     !
     bidirectional
      co-routed
      association-id 1100
     !
    !

   !
  !

 !
!

Review Circuit Style SR-TE Policy Bandwidth Utilization

You can verify that the reserved bandwidth pool settings (defined when enabling CSM, see Enable SR Circuit Style Manager) are correctly configured. You can also view current Circuit Style SR-TE bandwidth utilization and how much is still available for use.


Note

There are different ways to navigate to the Link Details > Traffic Engineering page from a participating Circuit Style SR-TE node or link. The following procedure assumes you have a Circuit Style SR-TE policy checked in the SR Policy table.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit style. The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

Check the check box next to the Circuit Style SR-TE policy you are interested in.

Step 3

From the topology map, click on a participating Circuit Style SR-TE policy node.

Step 4

From the Device details page, click Links tab > Link_Type _entry > Traffic engineering tab > General.

Under Circuit Style bandwidth pool, you can see the reserved bandwidth pool size, the amount of bandwidth currently being used, and what bandwidth (allocated to Circuit Style SR-TE policies) is still available.

This example shows the reserved bandwidth pool size as 800 Mbps for NCS-3 and NCS1. The configured settings were earlier defined as 80% for the bandwidth pool size. Since the interface is 1 Gbps, we can confirm that CSM has correctly allocated 80% of the bandwidth for Circuit Style SR-TE policies for these interfaces.
Figure 1. CS SR Policy Bandwidth Pool

CS SR Policy Bandwidth Pool

View Circuit Style SR-TE Policies

View Circuit Style SR-TE policy details such as the endpoints, bandwidth constraints, IGP metrics, and candidate (Working and Protect) paths.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit style.

Figure 2. Select Circuit Style Tab

Select Circuit Style Tab

The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

From the Actions column, click More icon > View Details for one of the Circuit Style SR-TE policies.

Note

 

You cannot edit or remove Circuit Style SR-TE policy configurations that have been created directly on the device.

Figure 3. View Circuit Style SR-TE Policy Details

View Circuit Style SR-TE Policy Details

The Circuit style policy details window is displayed on the side panel. By default, the candidate path with an "active" state is displayed in the topology map. An active state is designated with a green "A" icon under State, indicating it is currently the operational active path. The map also has the Bi-Dir path checkbox checked by default, showing the bidirectional paths. The Candidate path list displays the candidate path with an active status (path that takes traffic) and other candidate paths.

Figure 4. CS-SR Policy Details Summary

CS-SR Policy Details Summary

Note

 

The Bandwidth Constraint value can differ from the bandwidth you requested if the value is increased and insufficient resources exist to satisfy demand on all Working and Protect candidate paths.

Step 3

View Candidate path configuration details.

  1. The Circuit style policy details window allows you to drill down to view more information about the candidate paths. You can also copy the URL and share this information with others.

    The Working path (highest preference path) with an operational state (Oper state) "Up" will always have an active state indicating that it takes traffic (see How Does CSM Handle Path Failures?). If the Working path goes down, the Protect path is activated. In this example, the Protect path (with preference 50) is active and displayed on the topology map. Click Expand all to view more information about both paths.

    Figure 5. Candidate Path on Topology Map

    Candidate Path on Topology Map

    Note

     

    • First preference paths are shown as purple links.

    • Second preference paths are shown as blue links.

    • Third preference paths are shown as pink links.
    If the Circuit Style SR-TE policy configuration was done through Cisco Crosswork Network Controller, you have the option to view the Circuit Style SR-TE policy configuration. To see the configuration, click the link next to Config ID. For example:
    Figure 6. View Candidate Path Details

    View Candidate Path Details
    Here is a sample of a Circuit Style policy configuration. For more information, see Configure Circuit Style SR Policies.
    Figure 7. Circuit Style Policy Configuration Example

    Circuit Style Policy Configuration Example

Step 4

To view the physical path and metrics between endpoints of the selected Circuit Style SR-TE policies, click Display Preferences icon to turn applicable metrics on and check the IGP path checkbox.

Figure 8. IGP Metrics

IGP Metrics

Trigger CSM to Recalculate a Circuit Style SR-TE Policy

Circuit Style SR-TE policies are static in nature, meaning once the paths are computed, they will not be automatically re-optimized based on topology or operational status changes that may affect their paths. You can manually trigger CSM to recalculate a CS-SR policy after the policy's operational status went from down to up or if bandwidth size and requirement changes have been configured.


Note

You can only reoptimize a Working and Protect path. It will not work for a Restore path.

Procedure

Step 1

From the main menu, choose Traffic Engineering > Traffic Engineering > SR-MPLS and click Circuit style. The SR Policy table lists all Circuit Style SR-TE policies.

Step 2

From the Actions column, click More icon > View Details for the Circuit Style SR-TE policies you want CSM to recalculate a path for again.

Step 3

From the top-right corner, click More icon > Reoptimize.

What Happens When Bandwidth Reservation Settings are Exceeded?

CSM discovers and updates the available and reservable bandwidth in the network. CSM maintains an accounting of all bandwidth reservations provided for CS SR policies to ensure that the total reserved bandwidth on all interfaces remains at or below the network-wide resource pool (bandwidth pool size).

This topic provides examples of how CSM handles policies that exceed the bandwidth pool size or bandwidth alarm threshold set on the CSM Configuration page.

Example: Bandwidth Utilization Surpasses Defined Threshold

  • Link CS Bandwidth Pool Size: 10%

  • Link CS Bandwidth Minimum Threshold: 10%

In this example, the bandwidth pool size for the 10 Gbps ethernet interfaces is 1Gbps and the alarm threshold is set at 100 Mbps (10% of pool size).

  1. A Circuit Style SR-TE policy from node 5501-02 to node 5501-01 (r02 - r01) is created with a bandwidth of 100 Mbps.

    Figure 9. CS-SR Policy 10 Mbps Up

    CS-SR Policy 10 Mbps Up

  2. Later, the requested bandwidth configured for the policy is increased to 500 Mbps. CSM determines the additional bandwidth along the existing path is available and reserves it.

    Figure 10. CS-SR Policy 500 Mbps Up

    CS-SR Policy 500 Mbps Up

  3. Since the bandwidth utilization (500 Mbps) with the updated policy is above the configured pool utilization threshold (100 Mbps), an event is triggered.

    Figure 11. Threshold Alerts

    Threshold Alerts

Example: Bandwidth Pool Size and Utilization Exceeded

  • Link CS Bandwidth Pool Size: 10%

  • Link CS Bandwidth Minimum Threshold: 90%

In this example, the bandwidth pool size for the 10 Gbps ethernet interfaces is 1Gbs and the alarm threshold is set for 900 Mbps.

  1. An existing Circuit Style SR-TE policy from node 5501-02 to node 5501-01 (r02 - r01) uses a bandwidth of 500 Mbps.

  2. Later, a new policy requiring a bandwidth of 750 Mbps with a path from node 5501-02 to node 5501-01 to 5501-2 (r02 - r01- r2) is requested. The only paths available between these two nodes are the paths computed for the first CS policy.

    • CSM cannot compute a path for the new Circuit Style SR-TE policy r02 - r01 - r2 and remains operationally down. CSM will try again every 30 minutes to find a path that meets the bandwidth requirements.

      Figure 12. CS-SR Policy Exceeds Bandwidth Pool Size

      CS-SR Policy Exceeds Bandwidth Pool Size

    • Alerts are triggered.

      Figure 13. Threshold Alerts

      Threshold Alerts

  3. Later, the Circuit Style SR-TE policy r02 - r01- r2 is updated and only requires 10 Mbps. The following behaviors occur:

    • Since the total bandwidth required for the two policies (10 Mbps + 500 Mbps = 510 Mbps) now requires less than the bandwidth pool size (1Gbps), Circuit Style SR-TE policy r02 - r01 - r2 receives a path computed by CSM and becomes operationally up.

      Figure 14. Updated CS-SR Policy Operational

      Updated CS-SR Policy Operational

    • Since the second Circuit Style SR-TE policy with the reduced bandwidth is now provided a path by CSM, alerts are cleared.

      Figure 15. Cleared Alerts

      Cleared Alerts

How Does CSM Handle Path Failures?

Cisco Crosswork computes paths for Circuit Style SR-TE policies only after a complete bidirectional, path-protected set of candidate paths has been delegated. Three types of candidate paths are used during path failures:

  • Working—This candidate path has the highest preference value.

  • Protect—This candidate path has the second-highest preference value. If the Working path goes down, the Protect path (with the lower preference value) is activated. After the Working path recovers, the Protect path remains active until the default lock duration expires.

  • Restore—This candidate path has the lowest preference value. Crosswork computes the Restore path only after the Working and Protect paths are down. You can control how long after Restore paths are delegated from both sides to wait before the path is computed (see Enable SR Circuit Style Manager). This delay allows topology and policy state changes to fully propagate to Crosswork in cases where these changes triggered the Restore path delegation.

You can configure Performance Measurement (PM) to address path failures effectively and switch from the Working path to the Protect path. For more information, see Configure Circuit Style SR Policies.

Examples


Note

Illustrations are for demonstration purposes only and may not always reflect the exact UI or data described in the workflow content. If you are viewing the HTML version of this guide, click the images to view them in full size.

The following image shows that the Working and Protect paths of the Circuit Style SR-TE policy are operational. The active path is indicated by the "A" icon.
Figure 16. Initial Candidate Paths

Initial Candidate Paths
When a Working path having an active status goes down, the Protect path immediately becomes "active." When the Working path recovers, the Protect path moves to up/standby, and the Working path (with preference 100 in the example) becomes active.
Figure 17. Protected Path Becomes Active

Protected Path Becomes Active
When both the Working and Protect paths go down, CSM calculates a Restore path, which becomes active. The Restore path only appears in this specific scenario. Note that the Restore path has the lowest preference value of 10 in the example. If the Working or Protected paths become operational again, the Restore path will no longer be visible on the topology map and will be removed from the Candidate path list.
Figure 18. Restore Path

Restore Path