RE: Two Drafts for Resilience of Control Plane

[ibryskin@movaz.com]

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

I never said that the problem is about new LSPs

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

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.

> 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 was talking about NMS connectivity with  ?live? NEs via management network

>
> I think we are done.
>

I think too.

> Thanks,
>
> John
>
>> -----Original Message-----
>> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]
>> Sent: Saturday, October 29, 2005 7:40 AM
>> To: Drake, John E
>> Cc: ibryskin@movaz.com; Zafar Ali; drake@movaz.com;
>> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; Igor
> Bryskin;
>> Kim Young Hwa; ccamp@ops.ietf.org
>> 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
>
>