RE: Two Drafts for Resilience of Control Plane

["Drake, John E" <John.E.Drake2@boeing.com>]

.
> 
> 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