The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

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

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:dhg@juniper.net]
> Sent: Tuesday, November 05, 2002 7:04 PM
> To: Gray, Eric
> Cc: mpls@UU.NET
> 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.
> > 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
> > > >
>
>