Cisco Crosswork Network Controller 7.2.x Network Bandwidth Management

PDF

Cisco Crosswork Network Controller 7.2.x Network Bandwidth Management

Path computation and reversion behaviors

Updated: January 30, 2026

Want to summarize with AI?

Log in

This section describes the path computation behavior and the processing logic used during path reversions.

The successful provisioning and continuity of circuit-style SR-TE policies depend on both the process of path computation and the precise handling of recovery and restoration scenarios. Path computation determines how the system establishes candidate paths that meet bandwidth, protection, and constraint requirements. Path reversion logic governs the transition between working, protect, and restore paths in response to network events and recoveries.

Path computation behavior

The SR Circuit-Style Manager (CSM) 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.

  • Bandwidth availability and path delegation: Path computation relies on bandwidth availability. If insufficient bandwidth prevents path establishment, the SR Circuit-Style Manager will retry every 30 minutes until a solution is found or circuit style SR-TE is disabled.

  • Restore path computation: The Restore path is computed only after the Working and Protect paths go down. Use the configurable delay timer to set the wait period post-delegation, allowing topology and policy state changes to propagate before computation.

  • Path optimization and limitations: Automatic path re-optimization is unavailable for topology or LSP state changes and periodic events. Path configurations must be manually adjusted as needed.

  • Supported path computation scenarios: Path computation supports Intra/Inter-area and Intra/Inter IGP Domain scenarios. Inter-AS path computation is not supported, requiring manual configuration for such cases.

Path reversion

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: 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 1. 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.