The MPLS WG Archive

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

In message <037c01c3b939$929f1740$a9b39ed9@Puppy>, "Adrian Farrel" writes:
> All,
> 
> I have published a draft to start the ball rolling in the great hard/soft pre
> -emption
> debate.
> There is no doubt that the draft is rambling and wrong.
> 
> Please enter into a detailed and heated debate.

Since Kireeti declined, I'll fulfill your request.

> In summary...
> 
> The points of contention are:
> - Should pre-emption cause the associated LSP to be torn down
>   - at the point of pre-emption
>   - at all other LSRs along the LSP?
> - If it is torn down, is it torn using PathErr and ResvErr?
> - What is the correct processing of a PathErr after an LSP has
>    been successfully established.
> - Is it possible for hard and soft pre-emption to co-exist in a
>    network if they both use the same signalling technique?
> 
> A lot of the answers seem to hang on how admission control is performed. Is i
> t per LSP or
> is it statistical?
> 
> It does not appear to be very fruitful to investigate
> - the 'correct' interpretation of RFC3209
> - the motivation for the Path_State_Removed flag in RFC3473
> (You are, however, perfectly free to investigate whatever you like!)
> 
> Cheers,
> Adrian

Overall its a good description of the problem.

Section 4 is close but not quite right.  But the whole section is
irrelevant.  Soft preemption only makes sense if hard reservations are
not made up to the point where resources are exhausted.  What you
describe as pure statistical admission control is on one end of the
spectrum but there is middle ground between hard reservations and none
at all.

In section 5 - the preempted LSP need not use best effort.  If there
are multiple services using at higher priority (lower numeric holding
priority) may still fit or the preempted service may need be
downgraded, but not to best effort.

For example, consider a network where priority 3 is very low delay EF
and allowed to reserve 5% of bandwidth and 4 is low delay EF and sum
of priority 3 and 4 EF is allowed to reserve 10% of link bandwidth,
priority 5 is an AF service and the sum of the EF and AF is allowed to
reserve 30% of link bandwidth, and prior 7 is best effort but to keep
congestion loss low, the best effort too is limited (though perhaps
allowed to exceed 100% of link bandwidth).  If an additional priority
3 arrives, taking the absolute shortest path available, then a
priority 4 LSP may be displaced.  Since the limit of 10% is only an
administrative goal, the priority 4 LSP can be soft preempted and
continue to consume EF resources.  It need not be downgraded to AF and
lose the delay characteristics.  If a priority 3 or 4 LSP is added a
priority 5 LSP may be preempted.  If may continue to use AF service
since doing so will only put a further squeeze on best effort.  In
either case, if the soft preempt does not result in a reroute by the
ingress then a hard preempt should occur.

If no resources are reserved, then the above does not apply.  However
the case where no resources are reserved is not the only case where
soft preemption makes sense, contrary to what you've written.

The whole point of doing soft preemption is to give the ingress the
option to do a prompt make-before-break reroute.  You could probably
replace all of section 4 and 5 with that statement and this draft
would be no worse for it (and probably better).  Otherwise you have
lots of fixing up to do because you have painted the world black and
white.

The whole problem that resulted in the current implementations use of
hard preemption and the need for an explicit soft-preemption mechanism
is summarized in section 5.5:

   There is no way to distinguish from the received message
   whether the pre-emption point performed soft or hard pre-emption.

Even with soft preemption the midpoint LSR need a way to tell the
ingress that the soft preeemption grace period has expired.
Definition of the path err with state removal and notify occurred
*after* many implementation were written and some deployed.  The
result has been that path err is still assumed to be hard preemption
by many implementations.

The set of solutions for soft preemption is in section 7.  Maybe you
should just skip sections 4 and 5 which are not entirely correct
anyway and catalog the solution space.

The soft preempt draft provides an interoperable solution given that
some routers in the field will tear down on path err.

The problem with just sending patherr is that the ingress needs to
know which LSR are genuinely out of resources and which ones are still
holding resources.  It is silly to propose a solution that works for
the simple case where one new LSP is added but is unsatisfactory for
the common case where a link failure occurs and many preemptions occur
simulataneously.  So it makes sense to look at that case.  If the
minimum number of LSPs are to be displaced then each LSR both forward
and back in the path should know when another LSR has done a
preemption on a LSP so that LSR can select the same one.  Therefore a
single LSP will have lost resources (from an administrative standpoint
only) at multiple midpoint LSR.  If a make-before-break is to be done
by the ingress, the ingress must know which links no longer have
resources and which do.  The information in the RRO summarizes this
for a given LSP.  Noting that zero bandwidth is available on a
specific link for a given holding priority does not provide adequate
information because it must be known whether that full link includes
the bandwidth of the LSP being replaced or if that link is among those
for which bandwidth is no longer being reserved for that LSP.

It is also worth noting that there is no significant network
disruption after a fault if FRR is in use and very little if standby
LSP (fully disjoint backup LSP signaled from the ingress) or disjoint
multipath (fully disjoint LSP signaled from the ingress with load
spliting that temporarily falls back to using one less path after a
fault).  With soft preemption the reallocation of resources can be
orderly and involve no further disruption, except for any brief delay
discontinuity resulting from make-before-break reroutes.  After a
fault, LSP can be rerouted in a way that tends toward close to optimal
use of resources without significant disruption during this
reoptimization.  With any of the backup traffic methods mentioned
above, the reoptimization need not be rushed (ie: it need not occur
faster than feedback on change in network usage can be provided by
reflooding if no loss is occurring except limited congestion for best
effort traffic).

Curtis