[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two Drafts for Resilience of Control Plane

igor -

you are already going beyond the specific discussion context

1. what is a control plane partitioned LSP ?

2. when you state "Suppose one or more signaling controllers managing
   some LSP went out of service leaving the LSP’s data plane intact."

   what does it mean "one or more controllers" ? what if you support
   RSVP GR ? why are you not able to recover the states ? etc.
hence, i still miss the exact problem wrt to the control plane protocol resilience
but i think there is another issue (which is even more important) - the resilience mechanisms of the control plane that we have today have been provided based on experience from the common use of the control plane and for being resilient wrt common failures - but not for ALL use of the control plane in ANY condition and for ALL possible failures - indeed what you are asking here is like what shall i do when the CP is completely down and the DP still up; it would surprise me that the CP would be of any help in this specific condition 

thanks,
- dimitri.

ibryskin@movaz.com wrote:


Hi,

Here is one of the problems that I’ve been thinking for a while – control
plane partitioned LSPs. Suppose one or more signaling controllers managing
some LSP went out of service leaving the LSP’s data plane intact. As far
as the user is concerned such LSP is perfectly healthy and operational.
Such situation could last for a considerable period of time. Do we need to
manage such LSP via control plane? Sure, we must be capable to tear down
such LSP, perform mb4b rerouting, distribute alarms between operational
controllers, signal data plane faults and perform recovery switchover,
modify LSP status, etc. Can we do this today? No, but with some
(signaling) extensions the problem I believe is solvable. Is this some
artificial, “fabricated” problem? No, I think it is real. Does it fall
under the control plane resilience problem space? I believe it does.

Igor



I agree with Zafar and Dimitri.  If someone wanted to document the GMPLS
control plane resiliency features, as was done for GMPLS addressing,
that might be a useful activity.



-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
Sent: Friday, October 28, 2005 9:56 AM
To: Igor Bryskin
Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org
Subject: Re: Two Drafts for Resilience of Control Plane

igor -

over time CCAMP came with a set of mechanims to improve control plane
resilience (RSVP and LMP GR upon channel/node failure) other WG


protocol


work are also usable used here OSPF GR, etc. ... on the other side,
mechanism such as link bundling have built-in resilience capabilities
and most GMPLS control plane capabilities have been designed such as


to


be independent of the control plane realisation (in-band, out-of-band,
etc.)

so indeed i share the concern of Zafar what could we do more here than
document these tools and provide our experience in using them;

now, before stating there are (potential) problems(s) arising - would
you please be more specific on what are these potential issue(s)


and/or


problems ? (not related to policy/config. - note: all the issues you
have pointed here below are simply policy/config specific but none of
them highlights a missing IP control plane resiliency feature)

thanks,
- dimitri.


Igor Bryskin wrote:



Zafar,

The problem arises when the control plane is decoupled
from the data plane. The question is do we need such
decoupling in IP networks? Consider, for example, the
situation when several parallel PSC data links bundled
together and controlled by a single control channel.
Does it mean in this case that when the control
channel fails all associated data links also fail? Do
we need to reroute in this case LSPs that use the data
links? Can we rely in this case on control plane
indications to decide whether an associated data link
is healthy or not (in other words, can we rely on RSVP
Hellos or should we use, for example, BTD)? Should we
be capable to recover control channels without
disturbing data plane? I think control plane
resilience is important for all layers. You are right,
Internet does work, however, we do need for some
reason TE and (fast) recovery in IP as much as in
other layers,don't we?

Cheers,
Igor

--- "Zafar Ali (zali)" <zali@cisco.com> wrote:




Hi All,

I am unable to understand the problem we are trying
to solve or
fabricate. My control network is IP based and IP has
proven resiliency
(Internet *does* work), why would I like to take
control plan resiliency
problem at a layer *above-IP* and complicate my
life. Did I miss
something?

Thanks

Regards... Zafar


________________________________

	From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Kim Young Hwa
	Sent: Friday, October 28, 2005 6:04 AM
	To: ccamp@ops.ietf.org
	Subject: Two Drafts for Resilience of Control Plane


	Dear all,

	I posted two drafts for the resilience of control
plane.
	One is for requirements of the resilience of
control plane, the
other is for a protocol specification as a solution
of that .
	These are now available at:




http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt







http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-protocol-00.txt


	I want your comments.

	Regards

	Young.

	===================================> >>	Young-Hwa Kim
	Principal Member / Ph.D
	BcN Research Division, ETRI
	Tel:     +82-42-860-5819
	Fax:    +82-42-860-5440
	e-mail: yhwkim@etri.re.kr
	===================================> >>




<http://umail.etri.re.kr/External_ReadCheck.aspx?email=ccamp@ops.ietf.or




g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863


0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E>








__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com


.









.