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 8:11 PM
> To: Zafar Ali (zali); Ong, Lyndon; ibryskin@movaz.com; 
> dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be
> Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor 
> Bryskin; Kim Young Hwa; ccamp@ops.ietf.org
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> 
> 
> > -----Original Message-----
> > From: Zafar Ali (zali) [mailto:zali@cisco.com]
> > Sent: Friday, October 28, 2005 5:08 PM
> > To: Drake, John E; Ong, Lyndon; ibryskin@movaz.com; 
> > dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be
> > Cc: Drake@movaz.com; dimitri.papadimitriou@alcatel.be; Igor Bryskin;
> Kim
> > Young Hwa; ccamp@ops.ietf.org
> > Subject: RE: Two Drafts for Resilience of Control Plane
> > 
> > > -----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.
> [JD] 
> 
> Years ago, when we first started on LMP, we had the notion of 
> active and standby control channels and it was George Swallow 
> that pointed out that this was a really *BadIdea*tm.
> 

Good news is that "we" are consistent :-) The bad news is that LMP newly
born RFC still have this notion [no one listened to George :-( ]. Here
are some reasons why "we" think this way: 

- Redundancy/ HA via IP Layer. 
- Taken a CC OOS is simple as putting an IF to the control network OOS,
and other operational simplicities. 
- OOS IF can be repair without impacting other links or LMP CC FSM. 
- One LMP CC FSM per "N" Egress links to control network. 
- LMP CC FSM is up as long as we have connectivity to the neighbor. 
- No need to make special arrangements to make signaling and control
channel consistent. I.e., both LMP and RSVP Hellos fail only when there
is no IP connectivity to the neighbor. 
- Etc. 

Thanks

Regards... Zafar 

> Thanks,
> 
> John
> > 
> > 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
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>.
> > > > >>>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> .
> > > > >>
> > > > >
> > > >
> > >
>