The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <200303171921.OAA23501@bifocal.cisco.com>, George Swallow writes:
> Curtis -
> 
> > The current semantics of path-err or path-tear is to indicate an error
> > in setup or to tear down.  Any intermediate node that didn' understand
> > this would release resources and cause traffic to black hole, exactly
> > what the soft preempt is trying to avoid.
> 
> If that were true for path-err, why does path-err have an in-place bit
> to express that the reservation is still there?
> 
> ...George


Expect that a certain implementation that we need to take into
consideration tears down if it doesn't understand the error code.

It also gets upset if it doesn't understand bits in the 'RRO IPv4/IPv6
Sub-Object Flags' or 'SESSION-ATTRIBUTES Flag' so that doesn't help
with either RRO flags or path-err.  At least the SESSION-ATTRIBUTES
flag will yield a path-err on the initial setup and the ingress can
fall back to a setup with no soft-preempt requested.

If the ingress doesn't understand soft-preempt, no sense sending it,
since it just delays the inevitable preempt.  If the midpoints will
tear down immediately due to an unknown error code or an unknown RRO
flag bit, its good to know that too.

The preference for the RRO flag is that like the protect-inuse, the
ingress knows which hops it does not have resources on.  Consider the
path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the
hops are near 100% utilized, the ingress knows it can share bandwidth
with its prior LSP on all hops for which the RRO flag bit is not set.
Its harder to do that with a collection of path-err messages.

Also, I haven't mentioned to the list, but if you put the preempted
bit back in the PATH ERO, others downstream of the initial
soft-preempt can soft-preempt the same LSP during the time that it
reroutes.  If we are looking for sub-second convergence plus
soft-preempt, this could be a very valuable feature.  The bit change
in the ERO is purely advisory and requires no change in resource
allocation so it can be propogated very quickly, much more quickly
than CSPF plus path setup.

Another reason to put this in the RRO is if FRR is used, the LSP is
both soft-preempted and protect-inuse must be set.  It is better to
set two bits in the RRO rather than send two separate messages.  If
the backup got preempted, then soft-preempt set and local-protect
available cleared would have a higher sense of urgency than
soft-preempt set and local-protect inuse being set.

I've given a few advantages of putting this in RRO.  What are the
technical advantages of putting this in path-err?

Curtis