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

From: Kireeti Kompella <[email-masked]>
Date: Mon, 4 Nov 2002 11:27:10 -0800 (PST)

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 05 Nov 2002 01:11:41 -0500

In message <[email-masked]>, Kireeti Kompella 
> same lines, is make-before-break needed on bandwidth *decrease*?

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

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 12:45:07 -0800

> 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