The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Nov> msg00086



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Wed, 13 Nov 2002 14:53:16 -0500
  • cc: "Gray, Eric" <egray@celoxnetworks.com>, mpls@UU.NET


In message <200211060003.gA603jS78616@merlot.juniper.net>, Der-Hwa Gan writes:
> 
> > Der-hwa,
> > 
> > 	Here we have a trade-off between a small potential for
> > simplification represented by using a symmetrical approach
> > (the same approach used for increasing or decreasing the 
> > TE-LSP bandwidth) and the potential risk of not being able
> > to make a new reservation with a lesser bandwidth in the
> > unusual use of FF reservation style.  
> 
> It is not a question of simplication. If FF reservation style is
> excluded from RSVP-TE spec, then we won't discuss it. But if FF remains
> a potential option (perhaps a future application may make use of it?),
> then it is fair to consider it.
> 
> My response was mainly to the point that Curtis raised - could there be
> a reason that changing ID is bad?
> 
> > 
> > 	Please tell me again why this is a hard choice?
> 
> There are other benefits to not changing the ID. It was those considerations
> that drove the original choice - it is more optimal, less
> states, and less overhead to the network.
> 
> Do you see a easy choice?
> Der-Hwa



If we can't agree that one approach is better, then we are stuck with
the current situation.  The ingress can either change the LSP-ID or
not change the LSP-ID and just decrease the bandwidth.

wrt you preferences.  There is no "less states" advantage since you
still have to implement bandwidth increase.  The overhead of an
additional interim LSP is inconsequential.  In either case the
flooding of a new reservable bandwidth amount incurs more overhead
than the RSVP signaling, is identical for either approach, and is not
a big deal either.

If we still have two methods available to the ingress, then we have to
make sure the midpoints can handle both.  If so, then the only thing
that we should add is (currently implied if the ingress can do it)
that the midpoint LSR must be prepared to handle a decrease in
bandwidth on an LSP.

Curtis

btw - maybe we should be getting rid of use of FF and just use SE but
thats a whole new topic.