The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

Raymond,

> bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> the delay to do so) involved in this solution worth what it provides
> (better LSP utilization)?

The order is not exactly as you wrote. The old LSP is not being
destroyed first, but rather a new LSP is being attempted to be created
using shared explicit rsvp reservation style. If the new reservation
fails the old tunnel continue to be active if it succeed we build a new
tunnel (no double bandwith reservation) we switch traffic to a new
tunnel. After this old is no longer refreshed. 

It is automatic with ability to adjust the interface stats collection
timers as well as the resize interval. 

R.

> Raymond Law wrote:
> 
> I agree the problem that I posed may not be MPLS specific; it applies to
> ATM circuits as well.  I think this may be more of a TE problem than a MPLS
> problem.
> 
> Basically I heard two solutions from the list.  The first solution is to
> assign a new LSP with the adjusted (measured from the first initial LSP)
> bandwidth.  Is the overhead (destroy the old LSP and set up a new LSP and
> the delay to do so) involved in this solution worth what it provides
> (better LSP utilization)?
> 
> The second solution is to do load balancing when setting up LSPs.  I agree
> that load balancing can definitely lead to better utilization of the
> LSPs.  However, I am more interested in the situation where, after load
> balancing and setting up LSPs for the FECs, the amount of traffic sent
> through the LSPs change, resulting in over- and under-utilization of some LSPs.
> 
> Ray,