Hi,
First of all, I'd like to appreciate your sending and receiving communication broadly as an initiator of this issue.
As most of people know about control plane,
it consists of control nodes, control entities, and control channels.
Here, the resilience aspect of control nodes could be addressed in the Igor's example
or in the duplication of processor cards within a commercial product.
The resilience aspect of control entities could be addressed in a protocol itself with GR (graceful restart) capability.
And, the resilience aspect of control channels could be identified a link or concatenation of links carrying control packets.
Here, I believe that the resilience of control nodes, called controller resiliency,
belong to implementation issue (or H/W specific issue), not protocol issue.
And, the resilience of control entities belong to protocol issue.
However, the scope of resilience in control entities exists between peer control entities, not between physically adjacent nodes.
Note that the resilience of control entities belong to only the protocol because a control entity means a protocol that runs a specific function.
Some protocols could be run with soft-state nature, others could be run with hard-state nature.
The decision on soft-state and hard-state is different from every protocol to be applied.
Next is the resilience of control channels.
It seems that this could belong to implementation issue as addressed by Adrian.
However, if you see the resilience of control channels as implementation issue,
I think that we don't need to consider more the resilience of control channels in a protocol approach. But,
differently from data plane, control plane has various protocols to keep their control relation.
Control channels addressed here are concerned with physically adjacent nodes via direct and indirect connections.
And, there could be one or more alternative routes to transfer control packets between physically adjacent nodes.
Let's look at an example network.
~~~~~~~~~~~~~~~~~~~
| |
| Intra/extra |
|-----------| network for |
| | control plane |
| | |
| 5 ~~~~~~~~~~~~~~~~~~~
| |
| | 6
| 1 | 4
A-------------------B------------------C
| | |
| 2 | |
|-------------------- |
| |
| 3 |
|--------------------------------------|
Above the example, we assume that 1, 2, 3, and 4 control channels share the fate with data channels, and 5 and 6 control channels are used to transfer only control packets. And, the network for control plane could have different capacity in real implementations.
Here, we can see several alternatives routes in conveying control packets between physically adjacent nodes.
Between A and B nodes have the following routes.
Route-1 : 1
Route-2 : 2
Route-3 : 3-4
Route-4 : 5-6
I think that the resilience aspect of control channel should handle reliable (and fast) transfer of control packets between specific nodes.
In the example between A and B nodes, these nodes should negotiate active and standby control channels, protocols to be carried on a control channel, and etc. In this sense, I believe that the resilience of control channel could belong to protocol issue.
One of two draft that I proposed is a solution for the resilience of control channel, which is based on a concept of the control network, called common channel signaling system used in the traditional PSTN and ISDN.
Of course, there could be other solutions to solve the resilience of control channel.
I don't think that the IP connectivity provides a means to be capable of using these various routes.
For the resilience of control plane, the IP connectivity is a basic, and additional works should be considered.
The other draft that I proposed is a requirement document for the resilience of control plane, not the one of control channels.
In the requirement document, as a initial comment from Dimitri, I think that the draft should cover protocol-neutral approaches, not protocol specific ones. For examples, the various resilience aspects of control nodes, control entities, control channels, and etc should be covered.
However, the current draft does not sufficiently cover the general aspect for the resilience of control plane.
I think that these parts in the requirement document could be handled in further version with help of ccampers who are interested in the resilience of control plane.
Regards
Young.