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

From: Francois Lemarchand <[email-masked]>
Date: Mon, 4 Nov 2002 16:27:05 -0800

Hello !

For re-optimisation I guess. If there is a need to change
the path when bandwidth increase then it's probably usefull
to return to the old path when bandwidth decrease (probably
more optimal).

So changing path probably justify make-before-break and
LSP-ID change.

Did I miss somthing ?

Francois

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: lundi 4 novembre 2002 20:27
To: [email-masked]
Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

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: Jim Boyle <[email-masked]>
Date: Tue, 5 Nov 2002 08:33:18 -0500 (EST)

Yes, we all agree that as the spec states, when the path changes the LSP
ID should be changed.

The issue is that one implementation has issues if the LSP ID of
a transit LSP does not change when the bandwidth decreases.  Alternatively
you could state that the issue is that one (or two) implementations are
unique in that they don't change the LSP ID when they decrease the
bandwidth.

So the options at this point are:

o) address the implementation with transit issue when bandwidth decreases
and LSP ID is not changed.

o) require LSP ID change during BW decrease in the spec and address the
implementation(s) which currently don't do this.

We've had a few people weigh in on both sides of this, so I'm not sure
if there is any resolution.

Jim

---

From: Blaine Christian <[email-masked]>
Date: Tue, 05 Nov 2002 09:50:45 -0500

Quite simply...  If there is no agreement amongst what are considered
the primary MPLS vendors then you HAVE to specify it in within the
draft.  So, all vendors should consent to allow for significant
permutations or define in the RFC.  The whole point of the IETF is to
help prevent or resolve issues such as this.    At this point the
change in the RFC seems to be straightforward and vendor agreement to
support the permutations does not appear to exist (yet).  

Jim, I think you could also argue that a third option exists.

o) Require in the RFC that an LSP ID NOT change during BW decrease.

Not that I like the third option but we should be fair in presenting
it.