Re: Two Drafts for Resilience of Control Plane

["Adrian Farrel" <[e-mail]>]

Hi Young,

Thanks for your thoughtful mail.

In focussing on control channel resilience you must answer why it is you
are not satisfied with the resilience provided by normal IP mechanisms.

For example, in your figure...

>            ~~~~~~~~~~~~~~~~~~~
>            |                 |
>            |  Intra/extra    |
>|-----------|  network for    |
>|           | control plane   |
>|           |                 |
>| 5         ~~~~~~~~~~~~~~~~~~~
>|                   |
>|                   | 6
>|        1          |         4
>A-------------------B------------------C
>|                   |                  |
>|        2          |                  |
>|--------------------                  |
>|                                      |
>|                   3                  |
>|--------------------------------------|

You correctly identify that there are several control plane routes from A
to B

>     Route-1 : 1
>     Route-2 : 2
>     Route-3 : 3-4
>     Route-4 : 5-6

The option that most people currently consider is that they run an IGP in
the control plane. This would mean that a control plane signaling message
from the signaling controller at A to the signaling controller at B would
be placed in an IP datagram addressed to the control plane address of B.
It would be sent along the shortest open path from A to B (route 1). In
the event of a failure of link 1, the IGP would converge and the signaling
messages would be sent along the next shortest path (route 2). And so on.

This mechanism is not sensitive to whether multiple control channels use
the same duct or not since the IGP will converge just as well if multiple
control channels fail at once.

Note that load sharing between control channels is not recommended because
it will result in out of order delivery of control messages. Have a look
at all of the health warnings about the use of ECMP.

So I assume that one of three issues is worrying you.
1. You do not want to implement an IGP in your control plane
2. You do not want to handle IP forwarding in your control plane
3. The speed of convergence of the IGP is not good enough for the
    use you wish to make of your control plane.

Item 1. is an issue of complexity. I can see that it would reduce the
complexity of a network device and the control plane if you do not have an
IGP. But since you must run the IGP to exchange TE information, it is no
additional cost to use it to exchange control plane information. And, to
the contrary, by using the IGP you do not need any other mechanisms for
control plane resiliency.

Item 2. is an implementation issue. The forwarding does not have to be at
line speed. In general, software forwarding of control plane packets might
be considered adequate.

Item 3. would be interesting to hear about. Note that for most cases (such
as the switch from route 1 to route 2 in your example) there is no need to
wait for IGP convergence since it is the sending node (A) that notices the
failed link and can immediately update its routing table. Thus convergence
time is only an issue for less direct routes.

So I'd like to understand a little more what is motivating your work, and
why you think existing techniques are not sufficient.


> 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.

OK. That sounds worth further investigation.

Thanks,
Adrian