The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Decreasing TE-LSP bandwidth, "interoperability issue"
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) > > >
|
|