Subject: RE: Two Drafts for Resilience of Control Plane

From: "Drake, John E" <[email-masked]>
Date: Fri, 28 Oct 2005 10:56:22 -0700

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 14:41:29 -0400 (EDT)

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

>> >>	===================================> >>	Young-Hwa Kim
>> >>	Principal Member / Ph.D
>> >>	===================================> >>
>> >>
>> >
>> >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 28 Oct 2005 14:52:47 -0400

Just like with 'classic' MPLS, with GMPLS
I think you have a situation where the
data and control planes could be out of
sync., or at least out of contact with each other for
a period of time. This is certainly not a fabricated
problem, but a matter of 'how often' and 'how bad' when
it happens (i.e.: is the IP control plane sufficiently
resilient) As Zafar said earlier, there are already some
mechanisms in place to handle this. Some folks (vendors
only) have said they are sufficient. To me, this should
be a question that operator types should be answering.

     --Tom

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 28 Oct 2005 21:02:59 +0200

igor -

you are already going beyond the specific discussion context

1. what is a control plane partitioned LSP ?

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.

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

thanks,
- dimitri.

---

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

Dimitri,
See in-line.
> 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
>     RSVP GR ? why are you not able to recover the states ? etc.

See my response to John. There are no restarts in my example

> 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

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 29 Oct 2005 01:26:08 +0200

igor - see in-line

> See my response to John. There are no restarts in my example

you stated

"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) :=)"

but this is exactly issue i am pointing here below - if a controller is 
really DEAD (and i included here any redundant controller pair) - beside 
*replacing* the damaged controller and restart i don't know which kind 
of additional extension you are asking for in the present context ... 
and this is logical we are discussing control plane availability/MTBF 
issues rather than resiliency issues

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 28 Oct 2005 19:51:40 -0400

--Tom