Posted on behalf of Young Hwa Kim

[Ron Bonica <Ronald.P.Bonica@wcom.com>]

Folks,

The following message is posted on behalf of Young Hwa Kim. He attempted to
post this message several days ago, but for some reason, it didn't get
posted to the list.

                                                         Ron



=====================================================

Hi, all.
I'd like to discuss the control plane resilience via the mailing list and in
the next IETF meeting.
In current, we do not have works about the control plane resilience.
The current focus of resilience has been only on transport plane.
The draft-ietf-ccamp-gmpls-recovery-analysis-00.txt also describes as
follows:
"Here, the focus will only be on transport plane survivability and recovery
 issues and not on control plane resilience related aspects."
I do not think it means that control plane does not need to have features of
the control plane resilience.
In order to provide reliable control networks in relevant networks, the
control plane resilience is also important.
I think the first issue to handle the problem domain, called the control
plane resilience is whether the problem domain is related to the CCAMP
charter or not.

We could read the following in the CCAMP charter.
"Abstract link and path properties needed for link and path protection.
Define signaling mechanisms for path protection, diverse routing and fast
path restoration. Ensure that multi-layer path protection and restoration
functions are achievable using the defined signaling and measurement
protocols, either separately or in combination."

In the sentence above, I could not assure whether link and path protection
means only transport plane, or
transport plane and control plane together.
If the sentence means the former, the charter have to be updateted.
But, if the sentence means the latter, the one seems good as such.
I think the latter interpretation is appropriate to us  because the CCAMP
realm handle control plane.
If so, I'm free to get into discussion on the control plane resilience.
But, our current concerns are on transport plane.
Under this status, it may be not possible to discuss a protocol
specification for protecting control channels.
I think the work for a framework or requirements for protecting control
channels may be good as a starting point.
I'm looking forward your opinions.
If you're interested in the control plane resilience, please refer to
draft-kim-ccamp-cc-protection-01.txt.
The document has the abstract section such as the following:
Abstract
   This document proposes a protocol used to protect control channels
   between adjacent nodes in GMPLS. Control channels are used to carry
   several control packets that include signaling related, routing
   related, or link management related information. The protocol may
   be used not in in-fiber(or in-band) network configurations but in
   out-of-fiber(or out-of-band) network configurations.
   Because this proposal is a first document for specifying the protocol
   used to protect control channels, it has no full contents for the
   specification to be proposed. Instead, this document focuses on basic
   concepts, necessity and requirements to be analyzed for protecting
   control channels. If we agree to this proposal including necessity
   and requirements for protecting control channels, we may proceed
   further works for the protection of control channels.
Thank you for reading this email.
******************************************
Young Hwa Kim
Senior Member, Network Technology Lab., ETRI
Office No. : 82-42-860-5819
Fax No. : 82-42-860-6342
Email addr. : yhwkim@etri.re.kr
******************************************