The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Gopalkrishna Panicker wrote:
> 
> Thanks. That was helpful.
> I was just browsing the RSVP-TE spec. In light of this discussion I
> find it interesting that the spec always refers to
> "bandwidth-increase" instead of say a "bandwidth-modify".
> 
> I am wondering if make-before-break mechanism should be used when
> bandwidth is to be decreased.
> 
> IMO make-before-break was devised to solve the double-counting
> issues which we don't have here.

The purpose of make-before-break is for situations where the LSP is
being rerouted independantly of the routing table - like when the ERO
changes.  An in-line change of the ERO creates transient instability in
the LSP that will result in a temporary loss of connectivity on the data
plane.  In a service provider network, that is completely unacceptible.

I'm not sure what the specific rationale for make-before-break is when
the LSP is not rerouting.  I think it's in order to prevent a loss of
the LSP.

In the case of a bandwidth-increase, if you just change the TSPEC, some
node may be unable to increase the reservation.  The resulting PathErr
may cause the LSP to be torn instead of reverted to the smaller
reservation.  This would be a very bad thing.

So instead, we create a new LSP.  If the new one fails, the old one is
not affected.

When doing a bandiwdth decrease, this shouldn't be a concern.  If a
switch is capable of modifying the bandwidth of an existing LSP in the
first place, I would assume that a bandwidth decrease will always
succeed.

> As mentioned in one of David's earlier emails on the subject, We
> could simply change the Sender Tspec and wait for a new updated
> Flowspec from the egress to take effect.

That would be mu gut feeling, but I wouldn't implement such a feature
without further study.  I don't trust gut feelings when making a
decision that may seriously affect interoperability if I'm wrong.

Personally, since make-before-break is required for rerouting and
bandwidth-increase, I see no strong reason not to use it for all
changes.  Once the mechanism is developed, it's simpler to just use it
everywhere.

-- David