Gracefully Tearing Down GMPLS LSPs

You can gracefully tear down nonpacket GMPLS LSPs. An LSP that is torn down abruptly, a common process in a packet-switched network, can cause stability problems in nonpacket-switched networks. To maintain the stability of nonpacket-switched networks, it might be necessary to tear down LSPs gracefully.

The following sections describe how to tear down GMPLS LSPs gracefully:

Temporarily Deleting GMPLS LSPs

You can gracefully tear down a GMPLS LSP using the clear rsvp session gracefully command.

This command gracefully tears down an RSVP session for a nonpacket LSP in two passes. In the first pass, the Admin Status object is signaled along the path to the endpoint of the LSP. During the second pass, the LSP is taken down. Using this command, the LSP is taken down temporarily. After the appropriate interval, the GMPLS LSP is resignaled and then reestablished.

The clear rsvp session gracefully command has the following properties:

It only works on the ingress and egress routers of an RSVP session. If used on a transit router, it has the same behavior as the clear rsvp session command.
It only works for nonpacket LSPs. If used with packet LSPs, it has the same behavior as the clear rsvp session command.

For more information, see the Junos Routing Protocols and Policies Command Reference.

Permanently Deleting GMPLS LSPs

When you disable an LSP in the configuration, the LSP is permanently deleted. By configuring the disable statement, you can disable a GMPLS LSP permanently. If the LSP being disabled is a nonpacket LSP, then the graceful LSP tear-down procedures that use the Admin Status object are used. If the LSP being disabled is a packet LSP, then the regular signaling procedures for LSP deletion are used.

To disable a GMPLS LSP, include the disable statement at any of the following hierarchy levels:

[edit protocols mpls label-switched-path lsp-name]—Disable the LSP.
[edit protocols link-management te-link te-link-name]—Disable a traffic engineering link.
[edit protocols link-management te-link te-link-name interface interface-name]—Disable an interface used by a traffic engineering link.

Configuring the Graceful Deletion Timeout Interval

The router that initiates the graceful deletion procedure for an RSVP session waits for the graceful deletion timeout interval to ensure that all routers along the path (especially the ingress and egress routers) have prepared for the LSP to be taken down.

The ingress router initiates the graceful deletion procedure by sending the Admin Status object in the path message with the D bit set. The ingress router expects to receive an Resv message with the D bit set from the egress router. If the ingress router does not receive this message within the time specified by the graceful deletion timeout interval, it initiates a forced tear-down of the LSP by sending a PathTear message.

To configure the graceful deletion timeout interval, include the graceful-deletion-timeout statement at the [edit protocols rsvp] hierarchy level. You can configure a time between 1 through 300 seconds. The default value is 30 seconds.

graceful-deletion-timeout seconds;

You can configure this statement at the following hierarchy levels:

[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]

You can use the show rsvp version command to determine the current value configured for the graceful deletion timeout.