RE: Two Drafts for Resilience of Control Plane

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

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