The MPLS WG Archive

[Jim Boyle <jboyle@pdnets.com>]

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)