The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

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.

That's perfectly correct and one of the reasons why we ended up with this scheme. Otherwise, the HE would have had to wait for some unknown period of time (to make sure it has received all the PERR from the set of preempting nodes) before triggering a new CSPF on the modified topology

 

OK. But I don't see how using Resv lets you know when all of the premption is complete. Since in your example preemption of D-E is likely to happen first it will trigger a Resv reporting just one hop as preempted. Later there will be another Resv that indicates D-E and G-H as preempted. Sometime later there might be another Resv indicating further preemption down near Z.

The only advantage seems to be that the Resv gives you a list of preemptions that have happened (saving the HE from having to maintain that list itself). It does not remove the "unknown period of time" issue.

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.

 

This is a good reason for a flag in the ERO. It doesn't speak to the use of Resv at all.

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.

Fully agree.

Will add another one: the number of signalling messages when the preempted TE LSP is soft preempted at multiple hops ...

As in the example above, you still get multiple messages (don't you?).

This only drawback with the Resv RRO message would be the existence of mid point LSRs non supporting the soft preemption draft as they might no detect the Resv message change (RRO preemption pending bit set) and as such would not trigger an immediate refresh. This would introduce some delay in the HE notification.

Are you sure there are no implementations out there that will tear down the LSP because of an unrecognized flag in the RRO? :-)

 

Adrian