Understand How Pathfinder Handles LSPs

LSP Control Types

The LSP’s control type determines whether the Path Computation Client (PCC, which is the router) or the PCE maintains the operational and configuration states of the LSP.

The PCE supports the following control types for LSPs:

• PCC-controlled LSPs (also known as device-controlled LSPs)—You can configure such LSPs on the router either from the GUI (by selecting NETCONF as the provisioning method) or from the CLI. The LSPs are managed by the router, which maintains both the operational state and the configuration state of the LSPs. The LSPs are part of the router’s configuration file.

• PCC-delegated LSPs—You cannot configure such LSPs directly from the GUI or from the CLI. You must first configure a PCC-controlled LSP from the GUI or from the CLI, and then delegate it to the PCE for management from the Configure LSP Delegation page (Network > Tunnels > Configure LSP Delegation) on the GUI or from the CLI. The router maintains both the operational state and the configuration state of the LSPs, and the LSPs are part of the router’s configuration file.

  If Pathfinder is down or if the LSP is not working as expected, you can delegate the LSP back to the PCC, in which case, the LSP is reclassified as PCC-controlled.

• PCE-initiated LSPs—You can configure such LSPs either from the GUI (by selecting PCEP as the provisioning method) or from the CLI. The PCE manages the LSPs and only the operational state is maintained in the router. The LSPs are not part of the router’s configuration file.

  Note:

  Although Pathfinder typically creates PCE-initiated LSPs, in the following cases, the PCE discovers such LSPs from the router:

  • When a PCE-initiated LSP is created by an external controller other than Pathfinder, the PCE then discovers the LSP from the router.

  • When you reset the topology in the GUI, the PCE re-learns the LSPs from the router.

LSP Path Types

Pathfinder supports the discovery, control, and creation of primary and protection LSPs. Primary LSPs provide the primary (preferred) route for traffic flows, while protection LSPs provide an alternate route if the primary route fails.

Protection LSPs are of two types: standby LSPs and secondary LSPs. The tunnel ID, source node, destination node, and IP address of a secondary or standby LSP are identical to that of the primary LSP. However, secondary and standby LSPs have the following differences:

• A secondary LSP is not signaled until the primary LSP fails.

• A standby LSP is signaled regardless of the status of the primary LSP.

When you configure a protection LSP from the GUI, you must have a primary LSP of the same control type (PCC-controlled, PCC-delegated, or PCE-initiated) available before you configure a protection LSP.

Protocols to Provision and Manage LSPs

Pathfinder supports two protocols for provisioning and managing LSPs: PCEP and NETCONF. When you provision an LSP by using PCEP, the LSP is added as a PCE-initiated LSP. When you provision an LSP by using NETCONF, the LSP is added as a PCC-controlled LSP.

Table 1 lists the provisioning and managing actions available for each LSP control type.

Irrespective of whether the LSPs are provisioned by using PCEP or NETCONF, Pathfinder can learn about LSPs by using PCEP or by device collection. Both PCEP and device collection discover the same LSP attributes.

For LSPs provisioned by using PCEP, reprovisioning (in case of a provisioning failure), deletion, rerouting, and path optimization for the LSPs are triggered automatically. For LSPs provisioned by using NETCONF (which are PCC-controlled LSPs and PCC-delegated LSPs), you must initiate the following tasks manually:

• If the provisioning of PCC-controlled LSPs fails (for example, when there is a commit failure or if the NETCONF session is down), you must resubmit the provisioning order manually.

• If the deletion of PCC-delegated LSPs or PCC-controlled LSPs fails, you must resubmit the deletion order manually.

• When the PCE receives an LSP down event from the network (for example, when maintenance events are scheduled for the LSP) for PCC-controlled LSPs, the PCE does not automatically recompute and reprovision a new path for the LSPs. You must manually modify the LSP to change the routing path.

• When you run path optimization, the PCE doesn't optimize PCC-controlled LSPs automatically. You must manually modify the LSP to choose an optimal routing path.

LSP Routing Methods

When you create an LSP, you can choose one of the following routing methods to specify whether the PCE should compute and provision the path or not:

• routeByDevice routing method—The LSP is provisioned with no explicit path, so the router computes the path.

• Other routing methods (default, delay, adminWeight, constant, distance, IS-IS, OSPF)—For routing methods other than routeByDevice, the PCE computes and provisions the path.

Routing Path Types

When you add an LSP, you can choose one of the following routing path types to specify how the PCE should compute the path:

• Dynamic—The PCE computes the path without imposing any path restrictions.

• Required—The PCE uses the path that you specified. If the specified path is not viable and available, the LSP status changes to Down and the PCE does not perform the computation to look for an alternate path.

• Preferred—The PCE uses the path that you specified, as long as it is viable and available. If not, the PCE computes an alternate path.

Deletion of LSPs

When an LSP is deleted from the router (and, thereby, from the network), it is automatically deleted from Pathfinder, unless it was previously modified by a user (either from the GUI or by using REST APIs). Any LSP that is modified by a user has a Persist state associated with it. Therefore, LSPs with Persist state must be deleted manually from the GUI or by using REST APIs. See Edit and Delete Tunnels.