The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

Raymond,

> both LSPs combine to match the new bw requirement of the traffic flows.

No. The new LSP's BW = (old bw +/- delta bw). (Note delta can be
negative :). So when the new LSP is build we as I already indicated stop
refreshing the old one. 

Also notice that at any time there is no double reservation of resourcse
(shared explicit rsvp reservation style is used).

R.

PS. I will send you offline some vendor specific doc ;).

> Raymond Law wrote:
> 
> 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,