The MPLS WG Archive

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

Hi,

At 20:00 19/02/2003 -0500, Nguyen, An wrote:
>Hi all,
>
>The draft is interesting.

Thanks.

>I wonder if this concept can be implemented to
>transport critial traffic for customers in the MPLS network.

Well I'm not sure to exactly see your point here but yes you could see this 
bit as a new TE LSP properties: the fact that the TE LSP could be soft 
preempted as opposed to hard preempted with the current existing scheme.

For instance, a TE LSP carrying critical traffic could have the following 
properties:
         Local protection desired: 0x01
         Bandwidth protection desired: 0x08
         Node protection desired: 0x10
         Soft preempted desired:  0x40

JP.

>Thanks,
>
>An Nguyen
>
>-----Original Message-----
>From: Curtis Villamizar
>To: Jim Boyle
>Cc: Matthew Meyer; mpls@UU.NET
>Sent: 2/19/03 4:39 PM
>Subject: Re: draft-meyer-mpls-soft-preemption-00.txt
>
>
>In message <Pine.LNX.4.44.0302191431560.3611-100000@fido.nc.rr.com>, Jim
>Boyle
>writes:
> >
> > 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)
> >
> > You can somewhat do some of these by changing metrics and waiting, but
> > just was wondering if something more general might be useful.
>
>Why couldn't you just use the same bit and allow soft preemption on
>link shut, reload, CLI adminstrative without encoding the reason?
>Since these are all CLI initiated, it wouldn't hurt to delay.
>Alternately, the soft preempt on anything using a specific resource
>could be done.
>
>Link bundle lost a member might also qualify as a reason for soft
>preemption for implementations of link bundling that can trasnparently
>more flows to other members of the bundle.
>
> > 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.
>
>Agreed.  The "and greater" should be dropped.
>
> > regards,
> >
> > Jim
>
>Thanks,
>
>Curtis