Subject: RE: Two Drafts for Resilience of Control Plane

From: "Drake, John E" <[email-masked]>
Date: Sat, 29 Oct 2005 08:35:53 -0700

Igor,

If a node looses control plane connectivity to its adjacent nodes, then
in the interval until that connectivity is restored, the nodes adjacent
to that node will take it and its links out of the TE link state
database so that no new LSPs will be routed through that node.

Existing LSPS can be maintained.  The endpoints of each LSP will be
informed of the control plane failure, so that they can tear the LSP
down if configured to do so, after a configured interval.  If
connectivity to multiple nodes along the path of an LSP are lost, there
may be hung resources.  To reclaim those resources, any node that loses
CP connectivity to an adjacent node can be configured to tear down LSPs
through that node after a configured interval.

I am dubious the NM connectivity would exist if CP connectivity would
exist, so one can't resort to NM to save the day.

I think we are done.

Thanks,

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, October 29, 2005 7:40 AM
> To: Drake, John E
> Cc: [email-masked]; Zafar Ali; [email-masked];
> [email-masked]; [email-masked]; Igor
Bryskin;
> Kim Young Hwa; [email-masked]
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> >
> >> Sticking to the example I described:
> >> a) absence of RSVP refreshes does not affect data plane in any way;
> >> b) use of LMP is not mandatory and, becides, I don't see now it
helps.
> >> True, the TE link could be withdrawn, however, the LSP will still
be
> >> operational
> > [JD]
> >
> > In your example, PathTear downstream and PathErr w/ state removed
> > upstream would work quite nicely.
> 
> True, but it means that operator needs to issue two management
requests
> from two controllers. But this is not how control plane is supposed to
> work, isn't it? - it should be able to manage an LSP from a single
> (usually, ingress)controller. The way you described it the operator
needs
> to figure out where to go and issue these requests. And what if this
LSP
> is not an S-PVC, rather, SVC created via UNI or ENNI request?
> 
>  As a matter of local policy, a node
> > always has the option of tearing down LSPs through adjacent nodes
with
> > which control plane connectivity has been lost, after a configured
> > interval has elapsed.
> 
> Sorry, for envirionments where control and data planes are not
congruent
> what you just said is an explicit NO-OPTION, i.e. must not be done -
you
> cannot destroy data plane just because you lost connectivity in the
> control plane.
> 
> Igor

---

From: [email-masked]
Date: Sat, 29 Oct 2005 13:31:20 -0400 (EDT)

> database so that no new LSPs will be routed through that node.

I never said that the problem is about new LSPs

> informed of the control plane failure, so that they can tear the LSP
down if configured to do so, after a configured interval.

Here is the problem. The CP comes into play when some entity (for example,
TL1 agent) issues a provisioning request on the service ingress to setup
one or more LSPs. All subsequent management is provided via this ingress
node. One cannot pre-configure what to do, say, on LSP egress node because
all actions are service specific real-time decisions based on numerous
policies (time of day, network state, identity of the service user, SLAs
and many other things). In other words all operations should be controlled
via ingress node.

> I am dubious the NM connectivity would exist if CP connectivity would
Ø	exist, so one can't resort to NM to save the day.

I was talking about NMS connectivity with  “live” NEs via management network

> I think we are done.

I think too.