The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Jim,

At 14:46 19/02/2003 -0500, Jim Boyle wrote:

>First, great draft - I like this concept.
>
>While a flag might be just the right thing for this particular
>application, I wonder if it might be good to try to broaden
>soft preemption technique to include other polite preemptions.
>
>These might include the following indicators
>
>o) your LSP is being prempted on the indicated link (draft covers)
>o) your LSP should be rerouted, this node is shutting down
>o) your LSP should be rerouted, this link is being taken out of
>    service
>o) your LSP should be rerouted away from this node (administrative/CLI)
>o) your LSP should be rerouted away from this link (administrative/CLI)

Well one can generate exactly the same sequence of event, setting up the 
RRO Preemption pending flag (of course, that does not provide the 
preemption root cause to the HE).

By the way, there are a bunch of existing alternatives to handle those 
scenarios:

(1) Just flood an IGP LSA/LSP update:
         - with the link down for link maintenance,
         - with MAXAGE LSA (OSPF) or OL bit set (ISIS) for node maintenance

(2) increase the TE metric to MAX

(3) use affinities

and make sure the HE LSR treat those events in a non disruptive fashion 
with a make before break.

>You can somewhat do some of these by changing metrics and waiting, but
>just was wondering if something more general might be useful.
>
>Also, with Diffserv TE, not sure that one can assume that a preemption
>necessarily "implies exhausted bandwidth at the affected priority
>level *and greater*" (section 5), but local implementations can do
>as they please I suppose.

Right.

JP.

>regards,
>
>Jim