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

From: "Gray, Eric" <[email-masked]>
Date: Tue, 5 Nov 2002 18:37:20 -0500

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

---

From: Der-Hwa Gan <[email-masked]>
Date: Tue, 05 Nov 2002 16:03:45 -0800

> 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

---

From: George Swallow <[email-masked]>
Date: Wed, 06 Nov 2002 08:29:13 -0500

There were actually two reasons for the design choice of changing the
LSP-ID.

The first was already described by Eric -

> TE-LSP bandwidth) 

The other has to do with optimizing bandwidth across multiple parallel
links.  If the ERO is node specific but not link specific, then the
choice of which link to place a tunnel on is a local decision.  One
option for doing this is to pack tunnels on links where they fit so as
to leave as large a free block of bandwidth as possible in
anticipation of being able to handle a large request.

When you decrease bandwidth, it the tunnel will now fit on one of the
other links, allowing a large free pool, thenyou may want to move it.
Changing the LSP-ID allows this in the same way as nay
make-before-break.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Nov 2002 14:53:16 -0500

> Do you see a easy choice?

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.