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 that are described in the table below act as constraints. Each of them 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 they either specify a required property of a path or exclude possible choices for that path.
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:
The user interface shows both the requested and reserved bandwidth under each candidate path when you view the policy details. These values can differ if the requested bandwidth is increased but there is insufficient available CS pool bandwidth along one or more of the 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 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 used must match across Working, Protect and Restore paths in both directions. |
Segment Constraints |
All Working, Protect and Restore paths must have the following segment constraints:
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:
|
Supported Policy Changes |
The following constraints may be changed for an operationally "up" Circuit Style SR-TE policy that has been previously delegated:
Once configuration changes are made in a consistent manner 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:
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 Manager feature pack configuration interface provides a configurable delay timer to control how long after Restore paths are delegated from both sides to wait before the path is computed. 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) Not supported path computation Inter-AS. |
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):
|
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.
Initial State |
Events |
Behavior |
---|---|---|
Working path is down, Protect path is up/active |
Working path comes back up |
|
Working path is down, Protect path is down, Restore path is up/active |
Working path comes back up, then Protect path comes back up |
|
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):
On side Z: Working path failure is remote (first Adj SID in SegList is valid):
|