The MPLS WG Archive

[Raymond Law <rlaw@vt.edu>]

Robert:

If I understand correctly, the new LSP is reserved with the same ingress 
and egress LSR but with different amount of reserved resources such that 
both LSPs combine to match the new bw requirement of the traffic flows.

I can see how the above works if the old LSP needs more bw, then it just 
sets up a new LSP with some more bw to accommodate the traffic (no double 
bw).  What if the old LSP is actually allocated more than enough bw and you 
want to take away some bw from it to give it to other LSPs?  How would you 
set up the new LSP with less bw than the old one?

Is the new LSP set up like a regular LSP or is it set up using the existing 
knowledge of the old LSP so as to lower the overhead associated with 
setting up a whole new LSP.

Can you point me to some more info on this please?

Thanks.
Ray,

At 08:26 AM 7/30/01 -0700, you wrote:

>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,