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. Changes to bandwidth can be applied to existing policies with the following outcomes:

  • After configuring the new bandwidth on both sides, the system evaluates the path without recomputing it.

  • If the new bandwidth is higher, the system checks the current path for sufficient resources. If all paths can support the new bandwidth, the same path is returned with the updated bandwidth value, indicating to the path computation client (PCC) that it was successful. If any path cannot support the new bandwidth, the old bandwidth value is returned, indicating failure. This evaluation is only retried if the bandwidth changes again.

  • If the bandwidth is lower, the system 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 circuit-style 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 paths

• 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

• The supported disjoint path types are:

  • Link: Links are not shared on the computed paths.

  • Node: Nodes are not shared on the computed paths.

  • SRLG: Links with the same Share Risk Link Group (SRLG) value are not shared on the computed paths. These links rely on a common resource, making them susceptible to the same potential failures. This setting specifies that the Working and Protect paths cannot use links that are part of the same SRLG.

  • SRLG-node: SRLG and nodes are not shared on the computed paths.

• The disjoint type used must be the same in both directions of the same policy.

• 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.

• The Restore path must not have a disjointness constraint set.

• Crosswork Network Controller 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, the system 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 SR-TE policies.