RE: Two Drafts for Resilience of Control Plane

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

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

> 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-reqts-01.tx
> >>>>>t
> >>>>>
> >>>>>
> >>>>>>
> >>>>>
>
>>>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=%3C
> >>>863
> >>>
> >>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>__________________________________
> >>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005
> >>>>>http://mail.yahoo.com
> >>>>>
> >>>>>
> >>>>>.
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> .
> >>
> >
>