• Supported Platforms
• M Series
• T Series

Optimizing Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time, make the path suboptimal. A new path might have become available that is less congested, has a lower metric, and traverses fewer hops. You can configure the router to recompute paths periodically to determine whether a more optimal path has become available.

If reoptimization is enabled, an LSP can be rerouted through different paths by constrained-path recomputations. However, if reoptimization is disabled, the LSP has a fixed path and cannot take advantage of newly available network resources. The LSP is fixed until the next topology change breaks the LSP and forces a recomputation.

Reoptimization is not related to failover. A new path is always computed when topology failures occur that disrupt an established path.

Because of the potential system overhead involved, you need to control carefully the frequency of reoptimization. Network stability might suffer when reoptimization is enabled. By default, the optimize-timer statement is set to 0 (that is, it is disabled).

Configuring LSP optimization is meaningful only when constrained-path LSP computation is enabled, which is the default behavior. For more information about constrained-path LSP computation, see Disabling Constrained-Path LSP Computation.

To enable path reoptimization, include the optimize-timer statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Once you have configured the optimize-timer statement, the reoptimization timer continues its countdown to the configured value even if you delete the optimize-timer statement from the configuration. The next optimization uses the new value. You can force the Junos OS to use a new value immediately by deleting the old value, committing the configuration, configuring the new value for the optimize-timer statement, and then committing the configuration again.

After reoptimization is run, the result is accepted only if it meets the following criteria:

1. The new path is not higher in IGP metric. (The metric for the old path is updated during computation, so if a recent link metric changed somewhere along the old path, it is accounted for.)
2. If the new path has the same IGP metric, it is not more hops away.
3. The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
4. The new path does not worsen congestion overall.

   The relative congestion of the new path is determined as follows:

   1. The percentage of available bandwidth on each link traversed by the new path is compared to that for the old path, starting from the most congested links.
   2. For each current (old) path, the software stores the four smallest values for bandwidth availability for the links traversed in ascending order.
   3. The software also stores the four smallest bandwidth availability values for the new path, corresponding to the links traversed in ascending order.
   4. If any of the four new available bandwidth values are smaller than any of the corresponding old bandwidth availability values, the new path has at least one link that is more congested than the link used by the old path. Because using the link would cause more congestion, traffic is not switched to this new path.
   5. If none of the four new available bandwidth values is smaller than the corresponding old bandwidth availability values, the new path is less congested than the old path.

When all the above conditions are met, then:

5. If the new path has a lower IGP metric, it is accepted.
6. If the new path has an equal IGP metric and lower hop count, it is accepted.
7. If you choose least-fill as a load-balancing algorithm and if the new path reduces congestion by at least 10 percent aggregated over all links it traversed, it is accepted. For random or most-fill algorithms, this rule does not apply.
8. Otherwise, the new path is rejected.

You can disable the following reoptimization criteria (a subset of the criteria listed previously):

• If the new path has the same IGP metric, it is not more hops away.
• The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
• The new path does not worsen congestion overall.
• If the new path has an equal IGP metric and lower hop count, it is accepted.

To disable them, either issue the clear mpls optimize-aggressive command or include the optimize-aggressive statement:

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]
• [edit logical-systems logical-system-name protocols mpls]

Including the optimize-aggressive statement in the configuration causes the reoptimization procedure to be triggered more often. Paths are rerouted more frequently. It also limits the reoptimization algorithm to the IGP metric only.