The MPLS WG Archive

[Der-Hwa Gan <dhg@juniper.net>]

> 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

> 
> 	Note that - if we were using the FF reservation style
> and trying to increase the bandwidth - the problem would be
> worse because it would be both more likely to cause trouble
> and less likely to be remediable.
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> egray@celoxnetworks.com
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Der-Hwa Gan [mailto:dhg@juniper.net]
> > Sent: Tuesday, November 05, 2002 3:45 PM
> > To: curtis@fictitious.org
> > Cc: Kireeti Kompella; mpls@UU.NET
> > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)
> > 
> > 
> > >
> > > In message <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti
> > Kompell
> > a
> > > writes:
> > > > Hi All,
> > > >
> > > > I'd like to re-iterate Der-Hwa's question:
> > > >
> > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote:
> > > >
> > > > > It is perhaps more appropriate to ask what is the technical reason
> > that a
> > > > > new ID is required to get bandwidth decrease?
> > > >
> > > > Is there a technical reason that someone can articulate?  Along the
> > > > same lines, is make-before-break needed on bandwidth *decrease*?
> > > >
> > > > Thanks,
> > > > Kireeti.
> > >
> > >
> > > Does interoperating with a major router vendor (which is neither
> > > Juniper or Avici) qualify as technical?  After all, this is the IETF
> > > so improving interoperability must count for something.  Right?  If
> > > not, then I can't think of any reason to increment the LSP-ID and if
> > > you don't change the LSP-ID, then you don't need to do
> > > make-before-break.
> > >
> > > OTOH - Do you see any reason to NOT increment the ID and do
> > > make-before-break.  If you do so you interoperate with the major
> > > router vendors (Juniper, Avici, others which do either one right, plus
> > > one which seems to be in denial about their router not handling
> > > bandwidth decrease reliably).
> > 
> > Suppose the reservation style is FF, then incrementing the ID might
> > cause b/w decrease action to fail, since make-before-break may run
> > out of b/w at certain bottle-neck.
> > 
> > We can argue that FF style isn't in wide spread use, but it isn't
> > precluded from RSVP-TE framework so far.
> > 
> > Thanks,
> > Der-hwa
> > 
> > >
> > > We do the latter (change the LSP-ID and do make-before-break) and I
> > > think it is a better strategy because no major router can't handle
> > > that case.
> > >
> > > The only thing besides improved interoperability that borders on a
> > > technical reason is that the same mechanism is then used for both
> > > bandwidth increase and decrease.
> > >
> > > Curtis
> > >