Subject: RE: draft-meyer-mpls-soft-preemption-00.txt

From: "Nguyen, An" <[email-masked]>
Date: Thu, 20 Feb 2003 09:33:49 -0500

Ina,

Sorry I didn't define what "critical" means. What I meant was "authorized
emergency preparedness" traffic for Federal, state, and local. I am
interested in how this critical traffic can be reliably routed in times of
network congestion or crises.

Thanks,

An

-----Original Message-----
From: Ina Minei [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 9:20 PM
To: Nguyen, An
Cc: 'Curtis Villamizar '; 'Jim Boyle '; 'Matthew Meyer '; [email-masked] '
Subject: RE: draft-meyer-mpls-soft-preemption-00.txt

	I am not sure what you mean by critical.
	If "critical" implies zero loss always, then the answer is no.
Please note  that this scheme relies on a timer to do hard preemption
regardless of  whether the head end managed to resignal the LSP or not.It
is true that  this timer can be user configurable, but note that in the
scheme presented  this can be done in a scalable fashion only at node
level and not at LSP level (since the head end does not signal the amount
of time at LSP setup time).

	The proposed scheme will be beneficial, but cannot offer any hard
guarantees.

		Thanks,

			Ina

On Wed, 19 Feb 2003, Nguyen, An wrote:

> 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; [email-masked]
> Sent: 2/19/03 4:39 PM
> Subject: Re: draft-meyer-mpls-soft-preemption-00.txt
>
>
> In message <[email-masked]>, 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
>
>
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 11:13:49 -0500

In message <[email-masked]>, "Ng
> network congestion or crises.

As a practical matter, I don't think there would be other traffic that
would be preempting "authorized emergency preparedness" traffic for
Federal, state, and local.

The soft preemption helps the traffic which is being preempted.

AFAIK "authorized emergency preparedness" traffic is not being
selectively signaled and queued at all in ISP networks.

Curtis

---

From: Ina Minei <[email-masked]>
Date: Thu, 20 Feb 2003 10:13:02 -0800 (PST)

> Federal, state, and local.

	Agreed. However, think of the scenario where you want to move away
traffic from particular links for a maintenance window. In that case, even
this high priority LSP would have to be preempted.

				Ina

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 14:46:31 -0500

> this high priority LSP would have to be preempted.

That's make-before-break rerouting.  If you do it right, increase
metric, reset LSPs if reroute timers are long or set an admin-color
and set exclude-admin-color on the LSPs (just leave them set that
way).  You can name the admin-color "maintenance".  No preemption
occurs.  The LSPs just voluntarily move off the link, then you shut
the idle link down.  Requires that your routers do make-before-break
correctly and that your operational staff is sufficiently clued in.

Curtis

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 24 Feb 2003 12:14:08 -0500

>correctly and that your operational staff is sufficiently clued in.

Agreed.

JP.