Subject: Decreasing TE-LSP bandwidth, "interoperability issue"

From: Amir Birjandi <[email-masked]>
Date: Wed, 30 Oct 2002 14:25:50 -0500

Hi,

There are straight guide lines for increasing TE-LSP bandwidth in rfc-3209,
however there are ambiguities in rfc3209 and rfc2205 for decreasing the
TE-LSP bandwidth.  

It seems vendors can follow the spc if they change the LSP-ID or not change
the LSP-ID, after the LSP bandwidth has been decreased. 

This ambiguity may causes some intereoperabilty issues. 

Perhaps verdors or authors "3209 or 2205 "should address this issue so
every one comply to the same standard.

Thanks

A.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 30 Oct 2002 21:06:34 -0400

Hi Amir,

You're correct, there is an ambiguity in the RFCs that we need to address. 
This can clearly cause some interoperability issues. The simplest and more 
logical approach here is to proceed the same way whether the bandwidth is 
being increased or decreased, just increment the LSP-ID.

Any other vendor opinion ?

Thanks.

JP.

---

From: Markus Jork <[email-masked]>
Date: Thu, 31 Oct 2002 09:39:37 -0500

Well, in theory this shouldn't cause any interop problems because
no matter what approach it has chosen itself, an implementation has to
be prepared to deal with a bandwidth decrease via a simple change in
the tspec or via a reroute (new LSP-ID). In practice, it apparently
has caused interop problems...

I'm only familiar with three implementations, two of them use the
reroute method and one just changes the tspec. Because reroute
is the safer method that is guaranteed to work, I'm with JP here
and would suggest that the LSP-ID should always be incremented
for any bandwidth change (whether increase or decrease).

Markus

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 31 Oct 2002 11:52:06 -0500

In message <[email-masked]>, Amir Birjandi writ
> every one comply to the same standard.

Amir,

As Markus pointed out, this is yet another case where it is wise for
the implementor to "be conservative in what you send and liberal in
what you accept".  This has always been good advice to an implementor.

As an ingress anytime anything changes, priority, bandwidth, color
restrictions (if signaled), request for FRR, do a make-before-break
reroute.  Don't try to send a modified PATH message.  It is important
that an implementation not just change the LSP-id but also keep the
SESSION object unchanged so that make-before-break reservation sharing
works (as specified in rfc3209, section 2.5).

As a midpoint be prepared for anything to change in the PATH message.
Be prepared for priority to change or bandwidth to change.  Be
prepared for color restrictions to change.  Be prepared for FRR to be
added, dropped, or modified.  Also be prepared to "share" bandwidth
among more than two LSPs and for the possibility for those LSPs to
have different priorities (otherwise how do you make-before-break
reroute on a change in priority).  Be sure to "get it right" when
making a change or combining shared bandwidths on the CAC decision and
in the bandwidth accounting (the remaining reservable bandwidth
amounts that get reflooded).

There is existance proof that this can be accomplished, yielding
interoperabilty with two major MPLS implementation that do this
differently.

Of course, you are not an implementor and find yourself with one
router that has not been sufficiently conservation in what it sends
and another which has not been sufficiently liberal in what it
accepts.

The remaining question is if a spec is changed should changing the
tspec bandwidth in PATH messages for MPLS/TE be explicitly allowed or
explicitly disallowed.  Or both, require that it not be sent by the
ingress and require that it be accepted by the midpoint so in the
future we still cover older or slightly buggy implementations.

I prefer make-before-break reroute and therefore favor explicitly
disallowing the tspec change (but our implementation is OK either way).
I think the change should go in a future iteration of rfc3209.

Curtis

---

From: Jim Boyle <[email-masked]>
Date: Thu, 31 Oct 2002 14:01:47 -0500 (EST)

This issue was also discussed back in May

See: "RSVP-TE : bandwidth decrease"

there I think David Pointed out that there are obviously good reasons to
change the LSP ID for bandwidth increases and route changes for
make-before-break (you might lose your reservation).

When you decrease the bandwidth, I don't see how you are in danger of
losing your reservation, perhaps that's why the RFC3209 has a section
titled:

"4.6.4. Reroute and Bandwidth Increase Procedure"

but says nothing on bandwidth decrease procedure.

I guess I would agree somewhat with what's already been said.

You should be conservative in what you send (e.g. the spec doesn't say to
change the LSP ID for decreases, some versions of conservative might
differ) and liberal in what you process (e.g., don't expect LSP ID changes
to trigger you to see if bandwidth might have changed, and for increases
and changes in ERO don't expect the LSP ID to increment by one (though
that's common, it's only specified that a new LSP ID is assigned)).  If an
implementations failed to update the tspec propogated when the tspec is
decreased and the LSP ID is not changed, there are obvious situations
where this could cause a problem.

Curtis implied in his last paragraph that you needed to change LSP ID in
order to have  make-before-break on bandwidth decreases.  However, if one
only decreased the bandwidth, there is no worry about losing one's
reservation so there is no time the LSP would be "broke" (e.g. packets
continue to flow the whole time). The only thing adding a new path with a
different LSP ID would do is add more path state for a period of time, and
likely change the label associated with the session.

So what's the consensus here?

Be ready for BW decreases with and without LSP ID to changes?

regards,

Jim Boyle

(disclaimer: day job = juniper)

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 31 Oct 2002 11:50:34 -0800

Hi Jim,

A comment inline :

> Be ready for BW decreases with and without LSP ID to changes?

IMHO that sounds like the best approach. In our implementation this is 
exactly how its handled. A tspec change is propagated when the tpsec is
decreased irrespective of a change in the LSP ID. As you pointed out
for a bandwidth decrease this has advantages as there no additional path
state introduced.

rahul