Subject: RE: Two Drafts for Resilience of Control Plane

From: "Drake, John E" <[email-masked]>
Date: Mon, 31 Oct 2005 08:43:19 -0800

.
> 
> No John,
> 
> This is not true, I gave you a very specific problem - provide
mechanisms
> to
> manage LSPs with impaired control plane (when one or more controllers
are
> out of service).
> You said that this is not a problem, because RSVP is a soft state
protocol
> and once there are no refreshes the control data plane states must be
> destroyed and hence there is nothing to manage.
> And I tried very hard to explain you why this is not acceptable and
hence
> must be addressed.

[JD] 

Actually, I didn't say that.  What I said was that in your example,
PathTear and PathError with state removed should work just fine.

Due to 'CP degraded' notification, nodes C and D will know that B
failed.

In option a), local policy, configured via the NMS, at D will tell it
whether to send a PathErr with state removed and if so, how long to
wait.  As stated in another e-mail, multiple CP failures are handled by
configuration, via the NMS, at intermediate nodes that tell them under
what circumstances and after what duration to send PathTear and /or
PathErr with state removed, or whether simply to wait until the
resources time-out and how long to wait before timing them out.

In option b) A creates an MBB LSP on the path A, E, F, H, K, D.
Subsequently, A sends a PathTear to B, and D sends a PathErr with state
removed to C.  The MBB LSP was created under policy control, via the
NMS, at the ingress node, A.

Here's your initial example:

A----B------C-----D
|                 |
E-----F-----H-----K

> I have a solution and am planning to write a draft. I'd like this work
to
> live in CCAMP.
[JD] 

You can't get pre-approval of an I-D.

> Igor

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 31 Oct 2005 14:20:39 -0500

John,
mechanisms
are
protocol
hence

[JD]

IB>> This would require node D, for example, to know exactly what to do with
the service when it gets notified about the CP failure.
Policies do not work here. It's totally upto user to decide what to do with
this service. The only way it can convey this decision is by sending more
requests to the LSP ingress controller. For instance, the user may decide to
keep using the service for a while and then delete or reroute it before the
controller B comes back.
Neither of your options below therefore works. See also my response to
Dimitri.

Igor

A----B------C-----D
|                 |
E-----F-----H-----K

to
[JD]