What is a path profile policy?

Path profile policies

A path profile policy is configured to provide a set of rules that determine how LSPs will be routed through the network. These rules ensure that the paths of the LSPs are optimized in order to meet specified criteria. Pairs of LSPs whose paths will have an affect on one another should have the same path profile policy applied to them, and be made part of the same path profile group. These include bi-directional LSPs (which follow the same path in opposing directions) and disjoint LSPs (which follow paths that must be diverse from one another).

Note: LSPs can follow paths that are both bi-directional and disjoint from one another.

For information about creating a path profile policy, see How do I create a path profile policy?.

For information about applying a path profile policy and a path profile group to an LSP, see How do I create PCE-initiated LSPs?.

Note: When an existing path profile policy is modified, the changes are not automatically applied to the LSPs using that policy. In order for the changes to be applied, those LSPs must first be re-signaled. By default, this occurs automatically every 30 minutes, though they can be re-signaled manually at any time.

Note: Some third-party LSPs do not support the direct application of path profile policies. In this case, the user can force the LSP to inherit the set of rules configured in a path profile policy by applying a path profile override. For more information, see How do I apply a path profile override?.

Path profile policy parameters

The following section describes some of the options available when configuring certain path profile policy parameters.

Bi-directional — this parameter specifies whether or not a pair of LSPs must follow the same path (in opposing directions). The options are:

No: LSPs do not have to follow the same path
Symmetric Loose: LSPs should follow the same path, unless impossible
Symmetric Strict: LSPs must follow the same path or else fail

Disjoint — this parameter specifies whether or not a pair of LSPs must follow paths that are diverse from one another. The options are:

No: LSPs do not have to follow paths that are diverse from one another
Node Strict: LSPs must not traverse the same nodes, unless they are source or destination nodes
Link Strict: LSPs must not traverse the same links
SRLG: LSPs must not have overlapping SRLG values. LSPs may run over the same links, provided those links don’t have SRLG values assigned to them.
Node Strict and SRLG: LSPs must not traverse the same nodes, unless they are source or destination nodes, and must not have overlapping SRLG values
Link Strict and SRLG: LSPs must not traverse the same links, and must not have overlapping SRLG values

Optimize On (Objective) — this parameter specifies the primary goal when identifying potential paths for LSPs to follow. The options are:

Hops: LSPs should follow the path that requires traversing the fewest links
Cost: LSPs should follow the path with the lowest sum, as determined by IGP Link metrics
TE Metric: LSPs should follow the path with the lowest sum, as determined by TE metrics
Star Weight: LSPs should follow the path with the least value, as determined by the STAR algorithm
Latency (microseconds): LSPs should follow the path with the lowest latency

Bandwidth Strategy — this parameter specifies the strategy that will be used to determine interface and LSP bandwidth. The options are:

Standard: specifies that the LSP bandwidth used during path calculation for the LSP will be the requested bandwidth value configured for the LSP (LSP reservation bandwidth configuration)
Telemetry: LSP bandwidth statistics are obtained by measuring dynamically. When selected, NSP will attempt to mitigate congestion by rerouting LSPs so as to avoid links that have exceeded their specified utilization threshold. NSP will still attempt to calculate a path that best meets an LSP’s routing objectives while ensuring congested links are avoided.

Explicit Route Strategy — this parameter specifies the strategy to use when calculating the explicit route object (ERO). The options are:

Standard: the ERO will contain end-to-end strict hops for the path
Standard BSID Preferred: the ERO will contain end-to-end strict hops for the path, with binding SIDs preferred along the way to reduce label stack depth. If required, new binding SIDs will be generated and injected into the topology. The generation and compression of binding SIDs only occurs when necessary to avoid exceeding the MSD.
Loose Hop: the ERO will contain the border routers through which traffic will be routed, which are identified as loose hops. As the exact path is generally not known (due to ECMP), NSP will not provide a computed path for loose hop-routed LSPs.
Loose Hop AnyCast Preferred: the ERO will contain the border routers through which traffic will be routed, which are identified as loose hops. Manually-configured node SIDs will be preferred at parallel exit points to add resiliency. As the exact path is generally not known (due to ECMP), NSP will not provide a computed path for loose hop-routed LSPs.
Loose Hop BSID Preferred: the ERO will contain loose hops along the borders of the path, with binding SIDs preferred along the way to reduce label stack depth. When a path crosses multiple ASes or areas, NSP identifies the border router between the two areas as a loose hop and uses a Binding SID to specify the path through the next area.
Compressed: the ERO will contain a combination of adjacency SIDs and node SIDs for the path to reduce label stack depth
ECMP: the ERO will contain a combination of adjacency SIDs and node SIDs along a path comprised of parallel links and nodes. when this strategy is used, telemetry and bandwidth management are not available.

Note: The traffic route between loose hops is not tracked as it is generally not known (due to ECMP) and is therefore not maintained by NSP. As a result, NSP will not use telemetry to keep track of utilization for loose hop-routed LSPs. It does, however, use telemetry to determine the utilization of all other LSPs that have been configured to use telemetry as their bandwidth strategy.

Note: If the Explicit Route Strategy is set to Compressed, the label stack of the computed path will only be compressed if it exceeds the maximum stack depth that has been requested or configured.

BSID generation parameters — these parameters control BSID selection and/or BSID generation rules when computing a path result. The options are:

Generation: Stop on first found: The BSID generation algorithm computes using a sequence of strategies. Specifies whether the calculation will stop after a result is found, or continue attempting additional strategies for a potentially more optimal result.
Generation: Run permutations: A strategy may have various potential permutations in terms of where a BSID can be placed to achieve label stack reduction. For example, in a multi-area topology with an area splitting strategy, the algorithm may have an option to place a BSID in Area 1, or Area 0, or both. When the value of this parameter is set to false, the computation will program a BSID in all feasible areas. When the value is set to true, the computation will attempt different permutations and determine a subset result to achieve label stack reduction. The emplacement preference parameter setting will be used to assign preference for the final result, given multiple equal options.
Generation: Emplacement Preference: This setting is applicable when the Run Permutations parameter is set to true. Given a potential combination of results, this option controls where in the network-relative topology the BSID will be placed. For example, the CORE option will prefer to place BSIDs in the center of the topology (such as Area 0), whereas the EDGE option will prefer to place BSIDs closer to the edge/destination of the path, such as a non-backbone area.

Compressed Fallback parameters — these parameters specify one or more actions that can be taken in order to keep an LSP with the Explicit Route Strategy of Compressed from going down when its label stack cannot be compressed below the configured maximum stack depth. When multiple options are enabled, they will each be attempted in sequence, until a suitable alternate path is found. The options are:

Compression Fallback IGP TE: if maximum stack depth is exceeded, LSPs will instead adhere to IGP shortest path (with traffic engineering) to allow for compression. When enabled, this compression fallback action takes precedence over all others. It is enabled by default, and it is recommended that it remain enabled.
Compression Fallback IGP No TE: if maximum stack depth is exceeded, LSPs will instead adhere to IGP shortest path (without traffic engineering) allow for compression. When enabled, this compression fallback action takes precedence over all others, with the exception of Compression Fallback IGP TE. It is disabled by default, and it is recommended that it only be enabled if it is preferred that a tunnel remain operationally up rather than adhere to all configured traffic engineering requirements.
Compression Fallback Status Quo: if the prior attempts fail to compute a compressed label stack path, the LSP will be permitted to adhere to its current path, if that path is deemed healthy. When enabled, this compression fallback action only takes precedence over Compression Fallback Loose Hop. It is enabled by default, and it is recommended that it remain enabled.
Compression Fallback Loose Hop: if maximum stack depth is exceeded, LSPs will instead only use node SIDs in order to stay operationally up. This parameter is disabled for disjoint LSPs. When enabled, this compression fallback action is the last to be taken. It is disabled by default, and it is strongly recommended that it only be enabled if Compression Fallback Status Quo is also enabled.

Note: If the Compressed Fallback Loose Hop parameter is used to find a path, all path tracking and traffic engineering will be disabled.

Note: The last calculation behavior decision that was made can be viewed under the LSP details.

Explicit Route Strategy ECMP Preference — this parameter specifies the type of SID that will be preferred when calculating the ERO for an LSP that has been configured with the Explicit Route Strategy of ECMP. The options are:

Adjacency SID: adjacency SIDs (including adjacency set SIDs) are preferred
Node SID: node SIDs (including Anycast node SIDs) are preferred

Control Route Strategy — this parameter specifies whether an LSP is able to reroute, or must remain on its current path. The options are:

Standard: LSPs are rerouted based on network changes or manual re-signaling
Loose: LSPs are rerouted based on manual re-signaling only
Strict: LSPs are not rerouted, regardless of network changes or manual re-signaling

SID Protection Strategy — this parameter specifies the extent of SID protection to be used when routing a path. The options are:

Standard: LSPs prefer routes that include links with SID protection
Protected Only: LSPs must take routes comprised exclusively of links with SID protection
Unprotected Only: LSPs must take routes comprised exclusively of links without SID protection
Unprotected Preferred: LSPs prefer routes that include links without SID protectiong

Note: The SID Protection Strategy parameter is applied as a constraint when evaluating adjacency SID eligibility during path calculation. The ‘Backup Flag’ identified in the IGP information is evaluated to determine whether a SID is protected or not.

Latency Threshold — this parameter specifies when to re-signal an LSP that is optimized on latency. If the parameter is set to 0, indicating no change in latency, the LSP is automatically re-signaled when its end-to-end latency (the sum of all link latencies along the path) increases. If the parameter is set to a value less than 0, this automatic re-signal does not occur. If the parameter is set to a value greater than 0, the LSP is re-signaled when its end-to-end latency is greater than the defined threshold. If a path cannot be found that is below the Latency Threshold, the LSP will not be brought down, but an alarm will be raised. The LSP is brought down when no path that satisfies the max latency constraint can be found. The default value is -1.

Use subject to agreed restrictions on disclosure and use.