RE: Two Drafts for Resilience of Control Plane

["Zafar Ali \(zali\)" <zali@cisco.com>]

> -----Original Message-----
> From: Drake, John E [mailto:John.E.Drake2@boeing.com] 
> Sent: Friday, October 28, 2005 4:52 PM
> To: Ong, Lyndon; ibryskin@movaz.com; dpapadimitriou@psg.com; 
> dimitri.papadimitriou@alcatel.be
> Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor 
> Bryskin; Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> 
> 
> > -----Original Message-----
> > From: Ong, Lyndon [mailto:Lyong@Ciena.com]
> > Sent: Friday, October 28, 2005 1:28 PM
> > To: ibryskin@movaz.com; dpapadimitriou@psg.com; 
> > dimitri.papadimitriou@alcatel.be
> > Cc: Drake@movaz.com; Drake, John E; 
> dimitri.papadimitriou@alcatel.be;
> Igor
> > Bryskin; Zafar Ali; Kim Young Hwa; ccamp@ops.ietf.org
> > Subject: RE: Two Drafts for Resilience of Control Plane
> > 
> > Hi Igor,
> > 
> > Are you referring to controlling the LSP while one of the 
> controllers
> is
> > still down?  That would mean that no restart has yet taken place.
> > 
> > The draft seems to be focused on providing standby control channels,
> [JD] 
> 
> What is the utility of having standby control channels, as 
> opposed to just having multiple *active* control channels?
> 

There is no advantage, but there are numerous disadvantages. Having
multiple *active* control channels is what I was referring to as let IP
layer provide the  resilience for Control Plane. In fact there are
disadvantages of having active and standby control channel and some
other entity have to manage them. Now you have to worry about signaling
and control channels to be in-sync, fast switchover, etc. 

My motivation is to keep is simple, but yet superior. 

Thanks

Regards... Zafar 


> > what
> > you're suggesting sounds more like a standby signaling controller.
> [JD] 
> 
> A standby signaling controller is an implementation option 
> that shouldn't affect the existing GMPLS protocols
> 
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On 
> > Behalf Of ibryskin@movaz.com
> > Sent: Friday, October 28, 2005 1:08 PM
> > To: dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be
> > Cc: ibryskin@movaz.com; Drake@movaz.com; John E; 
> > dimitri.papadimitriou@alcatel.be; Igor Bryskin; Zafar Ali; 
> Kim Young 
> > Hwa; ccamp@ops.ietf.org
> > Subject: Re: Two Drafts for Resilience of Control Plane
> > 
> > Dimitri,
> > See in-line.
> > > igor -
> > >
> > > you are already going beyond the specific discussion context
> > >
> > > 1. what is a control plane partitioned LSP ?
> > 
> > LSPs with one or more controllers down, so there is/are 
> partitions in 
> > hop-by-hop signaling
> > >
> > > 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.
> > 
> > See my response to John. There are no restarts in my example
> > 
> > >
> > > 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
> > 
> > Believe me, CP could be still of a great help in such 
> conditions. You 
> > need some signaling extensions - which is why I think CP 
> resilience is 
> > an important topic within CCAMP - and then you can manage LSPs with 
> > control plane gaps at least to the extend I described.
> > 
> > Igor
> > 
> > >
> > > 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-r
> eqts-01.tx
> > >>>>>t
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>
> >
> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr
> otocol-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=ccam
> p@ops.ietf
> > >>>.or
> > >>>
> > >>>>>
> >
> >>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&mes
> sageid=%3C
> > >>>863
> > >>>
> > >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>__________________________________
> > >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005 
> > >>>>>http://mail.yahoo.com
> > >>>>>
> > >>>>>
> > >>>>>.
> > >>>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> .
> > >>
> > >
> > 
>