The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00271



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-meyer-soft-preemption-00.txt

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Mon, 17 Mar 2003 13:01:16 -0500
  • cc: mrn@gblx.net, denver@gblx.net, jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>


In message <000701c2eca2$721aeee0$b5828182@movaz.com>, "Adrian Farrel" writes:
>  
> Hi,
>  
> I support this concept, but I wonder why you do not use PathErr
> instead of Resv .  Why not just define a new Errcode/value for the
> PathErr to indicate preempted but still in place?  Transit nodes
> (including backwards compatibility) will forward the PathErr but not
> act on the LSP The headend can treat the PathErr as you describe by
> performing make-before-break.
>  
> Cheers,
> Adrian


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.

The soft preempt is an advisory from a midpoint to the ingress that
while an LSP is up, its resource reservation cannot be maintained and
it must be voluntarily rerouted or face tear down.  A bit in the
normal resv is a better way to express this than one of the error or
explicit tear down mechanisms.

Also, any midpoint that recieves this and then has to do a preempt can
prefer to soft preempt an already soft preempted LSP over one that has
not yet been preempted.  This would be quite common during the
reaction to a link failure, if the rerouting of preferred LSPs caused
less preferred LSPs to be preempted.

Curtis