Automatic LDP rLFA

The manual LDP rLFA configuration method requires the user to specify beforehand, on each node, the list of peers with which a targeted session is established. See LDP Remote LFA for information about the rLFA LDP tunneling technology, and how to configure LDP to establish targeted sessions.

This section describes the automatic LDP rLFA mechanisms used to automatically establish targeted LDP sessions without the need to specify, on each node, the list of peers with which the targeted sessions must be established. The automatic LDP rLFA method considerably minimizes overall configuration, and increases dynamic flexibility.

The basic principles of operation for the automatic LDP rLFA capability are described in LDP Remote LFA. In the example shown in Figure: General principles of LDP rLFA operation, considering a failure on the shortest path between S and D nodes, S needs a targeted LDP session toward the PQ node to learn the label-binding information configured on PQ node for FEC D. As a prerequisite, the LFA algorithm has run successfully and the PQ node information is attached to the route entries used by LDP.

Enable remote LFA computation using the following command:

config>router>isis>loopfree-alternates>remote-lfa

Enable attaching rLFA information to RTM entries using the following command:

config>router>isis>loopfree-alternates>augment-route-table

In the Figure: General principles of LDP rLFA operation scenarios, because the S node requires the T-LDP session, it should initiate the T-LDP session request. The PQ node receives the request for this session. Therefore, S node configuration is as follows:

configure router ldp targeted-session auto-tx ipv4
{
      tunneling false
      admin-state enable
}

And PQ node configuration is as follows:

configure router ldp targeted-session auto-rx ipv4
{
      tunneling true
      admin-state enable
}

Based on the preceding configurations, the S node, using the PQ node information attached to the route entries, automatically starts sending LDP targeted Hello messages to the PQ node. The PQ node accepts them and the T-LDP session is established. For the same reason, as in case of manual LDP rLFA, enabling tunneling at the PQ node is required to enable PQ to send to S the label that it is bound to FEC D. In such a simple configuration, if there is a change in both the network topology and the PQ node of S for FEC D, S automatically kills the session to the previous PQ node and establish a new one (toward the new PQ node).

In typical network deployments, each node is potentially the source node as well as the PQ node of a source node for a specific destination FEC. Therefore, all nodes may have both auto-tx and auto-rx configured and enabled. Nodes may also have other configurations defined (for example, peer, peer-template, and so on).

There are several implications (explicit or implicit) of having multiple configurations on a peer (either explicit or implicit).

One implication is that LDP operates using precedence levels. When a targeted session is established with a peer, LDP uses the session parameters with the highest precedence. The order of precedence is as follows (highest to lowest):

• peer

• template

• auto-tx

• auto-rx

• sdp

Allow us to consider the case where a T-LDP session is needed between nodes A (source) and B (PQ node). If A has auto-tx enabled and a per-peer configuration for B also exists, A establishes the session using the parameters defined in the per-peer configuration for B, instead of using those defined under auto-tx. The same applies on B. However, if B uses per-peer configuration for A and the chosen configuration does not enable tunneling, LDP rLFA does not work because the PQ node does not tunnel the FEC/label bindings. This mechanism also applies to auto-tx and auto-rx.

In a typical scenario in which the auto-tx and auto-rx modes are both enabled on a node that acts as the PQ node, and the node chooses the auto-tx configuration for the T-LDP session (because it has the higher precedence than auto-rx), LDP rLFA only works if tunneling is enabled under auto-tx. The configuration from which the session parameters are taken is indicated in the show>router>ldp>targ-peer detail command (‟creator” label).

Another implication is that redundant T-LDP sessions may remain up after a topology change when they are no longer required. The following clear command enables the operator to delete these redundant T-LDP sessions.

clear>router>ldp>targeted-auto-rx>hold-time seconds

The operator must run the command during a specific time window on all nodes on which auto-rx is configured. The hold-time value should be greater than the hello-timer value plus the time required to run the clear command on all applicable nodes. A system check verifies that a non-zero value is configured; no other checks are enforced. It is the responsibility of the operator to ensure that the configured non-zero value is long enough to meet the preceding criterion.

While the hold timer for the clear command is in progress, the remaining timeout value can be displayed using the tools>dump>router>ldp>timers command.

The clear command is not synchronized to the standby CPM. If an operator does a clear with a large hold-time value and the CPM does a switchover during this time, the operator needs to restart the clear on the newly active CPM.