The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

Jim,

	With respect to your comment on make before break
(and not referencing any particular implementation), it
can be the case that packets might be lost in reducing
bandwidth associated with a queue in an implementation -
if a new queue is not temporarily created.  This could
occur, for example, as a result relinquishing buffer
resources previously allocated to a "deeper" queue now
being associated with "shallower" queuing resources.  I
have not seen such an implementation recently, but it
is distinctly possible that some implementations do not 
handle reduction of queuing resources for an existing
queue gracefully.  Such an implementation would not
necessarily be "broken", if it were not designed with
the intention of supporting resource reduction for an
active queue.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@pdnets.com]
> Sent: Thursday, October 31, 2002 2:02 PM
> To: Markus Jork
> Cc: Jean Philippe Vasseur; Amir Birjandi; mpls@UU.NET;
> najam.ahmad@wcom.com; juzer.kopti@wcom.com; plahiri@UU.NET;
> blaine.christian@wcom.com
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue"
> 
> 
> 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)
>