Subject: RE: Two Drafts for Resilience of Control Plane

From: "Drake, John E" <[email-masked]>
Date: Fri, 28 Oct 2005 11:48:19 -0700

What part of your problem, as stated below, is not handled by RSVP
graceful restart?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 28, 2005 11:41 AM
> To: Drake, John E
> Cc: [email-masked]; [email-masked]; Igor
> Bryskin; Zafar Ali; Kim Young Hwa; [email-masked]
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> 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:[email-masked]]
> >> Sent: Friday, October 28, 2005 9:56 AM
> >> To: Igor Bryskin
> >> Cc: Zafar Ali (zali); Kim Young Hwa; [email-masked]
> >> 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)" <[email-masked]> 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: [email-masked]
> >> >>[mailto:[email-masked]]
> >> >>On Behalf Of Kim Young Hwa
> >> >>	Sent: Friday, October 28, 2005 6:04 AM
> >> >>	To: [email-masked]
> >> >>	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: [email-masked]
> >> >>	===================================> >>
> >> >>
> >> >
> >> >
> >
<http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]
g&name=ccamp%40ops.ietf.org&fromemail=[email-masked]&messageid=%3C863
> >> >
> >> >>[email-masked]%3E>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > __________________________________
> >> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> >> > http://mail.yahoo.com
> >> >
> >> >
> >> > .
> >> >
> >
> >
> >

---

From: [email-masked]
Date: Fri, 28 Oct 2005 16:00:16 -0400 (EDT)

John,

I think you missed my point here. "Dead" controllers in my example *do
not* come back for a considerable period of time. So there are no restarts
here (graceful or not graceful) :=)

Igor