Optimize Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time, make the path suboptimal. A subsequent recomputation might be able to determine a more
optimal path.

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, optimize-timer 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 Disable Constrained Path LSP Computation.

To enable path reoptimization, include the optimize-timer statement at the [edit protocols mpls], [edit protocols mpls label-switched-path lsp-path-name ], or [edit protocols mpls label-switched-path lsp-path-name (primary | secondary)] hierarchy level:

optimize-timer seconds ; 

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. This is done by comparing the percentage of available bandwidth on each link traversed by the new and old paths, starting from the most congested links.

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.

To disable items 2, 3, 4 and 6 above, enter the clear mpls optimize-aggressive command or at the [edit protocols mpls] hierarchy level, include the optimize-aggressive statement:

optimize-aggressive; 

Including the optimize-aggressive statement makes the reoptimization process more aggressive. Not only does it tend to reroute more often, it also limits the reoptimization algorithm to be based on the IGP metric only.