The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Oct> msg00165



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Decreasing TE-LSP bandwidth, "interoperability issue"

  • From: Rahul Aggarwal <rahul@redback.com>
  • Date: Thu, 31 Oct 2002 11:50:34 -0800
  • Cc: Markus Jork <mjork@avici.com>, Jean Philippe Vasseur <jvasseur@cisco.com>, Amir Birjandi <amir.birjandi@wcom.com>, mpls@UU.NET, najam.ahmad@wcom.com, juzer.kopti@wcom.com, plahiri@UU.NET, blaine.christian@wcom.com
  • User-Agent: Mutt/1.4i

Hi Jim,

A comment inline :


On Thu, Oct 31, 2002 at 02:01:47PM -0500, Jim Boyle wrote:
> 
> 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?

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

> 
> regards,
> 
> Jim Boyle
> 
> (disclaimer: day job = juniper)
> 
> 
>