Subject: RESEND: Decreasing TE-LSP bandwidth, "interoperability issue" (fw d)

From: "David Allan" <[email-masked]>
Date: Wed, 6 Nov 2002 06:27:24 -0500

Der-Hwa/Eric:
 
 Only scenario that comes to my mind is that some form of data 
 plane probing of the LSP is going on (be it LSP-PING, Y.1711 
 or whatever). Changing the ID means there is a small window 
 in which it may appear as a transient fault to the probing system.
 
 cheers
 Dave
 
> > -----Original Message-----
> > From: Der-Hwa Gan [mailto:[email-masked]]
> > Sent: Tuesday, November 05, 2002 7:04 PM
> > To: Gray, Eric
> > Cc: [email-masked]
> > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability 
> > issue" (fwd)
> > 
> > 
> > 
> > 
> > > 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.
> > > [email-masked]
> > > 508 305 7214
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Der-Hwa Gan [mailto:[email-masked]]
> > > > Sent: Tuesday, November 05, 2002 3:45 PM
> > > > To: [email-masked]
> > > > Cc: Kireeti Kompella; [email-masked]
> > > > Subject: Re: Decreasing TE-LSP bandwidth, 
> > "interoperability issue" (fwd)
> > > > 
> > > > 
> > > > >
> > > > > In message 
> > <[email-masked]>, 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
> > > > >
> > 
> > 
>