The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Feb> msg00061



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

draft-meyer-mpls-soft-preemption-00.txt

  • From: "Nguyen, An" <nguyena@ncs.gov>
  • Date: Wed, 19 Feb 2003 20:00:10 -0500
  • Cc: "'Matthew Meyer '" <mrm@gblx.net>, "'mpls@UU.NET '" <mpls@UU.NET>

Hi all,

The draft is interesting. I wonder if this concept can be implemented to
transport critial traffic for customers in the MPLS network.

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