RE: Two Drafts for Resilience of Control Plane

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.

NH=> Exactly so. THE major thing you have to be sure of before you can even start to consider this is the duct graph. If you cannot get physical disjointedness here then you can't even progress. The link-connections of the control/management plane network will, like any other data-plane network, be carried on trails in a lower layer network. You can use an IGP above this to attempt to provide some form of resiliency or you could do what they did in C7 (which is also a pkt-based network BTW) and have a simple load sharing algorithm across a multiple parallel link-set....so if 1 link fails the rest just carry on. Fast, simple, elegant and focussed at the right/relevant problem. So why not use this approach....as noted you have to start with having to ensure the equivalent of disjoint link-set anyway, so use it directly. Note also that 'adding' stuff generally reduces reliability....keep things simple.

regards, Neil

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.