The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3.0.32.20021030142549.027cb8b0@pop.wcomnet.com>, Amir Birjandi writ
es:
> 
> 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.



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