The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

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.  

	Please tell me again why this is a hard choice?

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