Subject: Two Drafts for Resilience of Control Plane

From: "Kim Young Hwa" <[email-masked]>
Date: Fri, 28 Oct 2005 19:04:20 +0900

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]
====================================

---

From: <[email-masked]>
Date: Fri, 28 Oct 2005 16:58:26 +0100

To add.....

There are some fairly significant differences between cl-ps mode, co-ps
mode and co-cs mode networks.  Indeed, in the co-cs mode an OOB
control/management *network* is a forced solution.  And note there are
(at least) 2 different networks in the same networking system....and how
one addresses resilience for these 2 networks is quite different.  In
fact because the control/management plane network is so important it
should only ever take its design cues from the duct topology.  And there
are other ways to deal with resilience other than 'an IGP' here, cf the
link-set in C7 (which btw is a cl-ps OOB network) as used in the
PSTN..........don't knock it, its a very simple and excellent
idea....maybe a researcher should look at it for some inspiration ;-)

regards, Neil

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: 28 October 2005 16:50
> To: Zafar Ali (zali); Kim Young Hwa; [email-masked]
> Subject: RE: Two Drafts for Resilience of Control Plane
> 
> 
> 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,
> > 	 
> > 	One is for requirements of the resilience of
> > control plane, the
> > other is for a protocol specification as a solution
> > of that .
<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: "Zafar Ali \(zali\)" <[email-masked]>
Date: Fri, 28 Oct 2005 14:22:28 -0400

> From: Igor Bryskin [mailto:[email-masked]] 
> Sent: Friday, October 28, 2005 11:50 AM
> The problem arises when the control plane is decoupled from 
> the data plane. 

But control network is still (and needs to be) an IP network. 

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

If this "single control channel" is "IP routing" the control packets, as
long as there is resilience in the control network (i.e., alternate IP
routes), we should be see "single control channel" as a deficiency. It's
as best of resiliency that it gets. 

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

We have (RSVP/ LMP) GR procedures for recovery of control network
failures. 

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

All these things are already addressed, please also see Dimitri's email
on this. 

> I think control plane resilience is 
> important for all layers. 

What is your definition of layers here? What I am saying is that having
control network resilience build outside IP layer is "bad complexity". 

> 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
> 
> > 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
> > 
> > 
> > [mailto:[email-masked]]
> > On Behalf Of Kim Young Hwa
> > 	One is for requirements of the resilience of control 
> plane, the other 
> > is for a protocol specification as a solution of that .
> Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 28 Oct 2005 16:28:20 -0400

Hi Igor,

Are you referring to controlling the LSP while one of the controllers is
still down?  That would mean that no restart has yet taken place.

The draft seems to be focused on providing standby control channels,
what
you're suggesting sounds more like a standby signaling controller.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, October 28, 2005 1:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; John E;
[email-masked]; Igor Bryskin; Zafar Ali; Kim Young
Hwa; [email-masked]
Subject: Re: Two Drafts for Resilience of Control Plane

Dimitri,
See in-line.
> igor -
>
> you are already going beyond the specific discussion context
>
> 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
>
> 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.

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

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

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

>
> thanks,
> - dimitri.
>
> [email-masked] wrote:
>
>> 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
>>
>>
>>>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.
>>>
>>>
>>>>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
>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>>	One is for requirements of the resilience of control plane, the 
>>>>>>other is for a protocol specification as a solution of that .
>>>>>>	===================================> >>	Young-Hwa Kim
>>>>>>	Principal Member / Ph.D
>>>>>>	===================================> >>
>>>>>>
>>>>>
>>>>>.
>> .

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Fri, 28 Oct 2005 20:07:55 -0400

> From: Drake, John E [mailto:[email-masked]] 
> Sent: Friday, October 28, 2005 4:52 PM
> To: Ong, Lyndon; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; Igor 
> Bryskin; Zafar Ali (zali); Kim Young Hwa; [email-masked]
> > From: Ong, Lyndon [mailto:[email-masked]]
> > Sent: Friday, October 28, 2005 1:28 PM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]
> > Cc: [email-masked]; Drake, John E; 
> [email-masked];
> Igor
> > Bryskin; Zafar Ali; Kim Young Hwa; [email-masked]
> > Are you referring to controlling the LSP while one of the 
> controllers
> is
> [JD] 
> What is the utility of having standby control channels, as 
> opposed to just having multiple *active* control channels?
> 

There is no advantage, but there are numerous disadvantages. Having
multiple *active* control channels is what I was referring to as let IP
layer provide the  resilience for Control Plane. In fact there are
disadvantages of having active and standby control channel and some
other entity have to manage them. Now you have to worry about signaling
and control channels to be in-sync, fast switchover, etc. 

My motivation is to keep is simple, but yet superior. 

Thanks

Regards... Zafar 

> [JD] 
> A standby signaling controller is an implementation option 
> that shouldn't affect the existing GMPLS protocols
> 
> > 
> > Cheers,
> > 
> > Lyndon
> > 
> from the 
> plane,
> > the
> >>>>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-r
> eqts-01.tx
> > >>>>>t
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>
> >
> >>>http://www.ietf.org/internet-drafts/draft-kim-ccamp-accp-pr
> otocol-00.
> > >>>txt
> > >>>
> > >>>>>>	I want your comments.
> > >>>>>>
> > >>>>>>	Regards
> > >>>>>>
> > >>>>>>	Young.
> > >>>>>>
> >>><http://umail.etri.re.kr/External_ReadCheck.aspx?email=ccam
> [email-masked]
> > >>>.or
> > >>>
> > >>>>>
> >
> >>>g&name=ccamp%40ops.ietf.org&fromemail=[email-masked]&mes
> sageid=%3C
> > >>>863
> > >>>

---

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

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Friday, October 28, 2005 5:08 PM
> To: Drake, John E; Ong, Lyndon; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Igor Bryskin;
Kim
> Young Hwa; [email-masked]
[JD] 

Years ago, when we first started on LMP, we had the notion of active and
standby control channels and it was George Swallow that pointed out that
this was a really *BadIdea*tm.

Thanks,

John
On
> > > > the resilience mechanisms of the control plane that we have
today
> > have
> > > >>>>problems ? (not related to policy/config. - note: all the
issues
> > you
> > > >>>>>associated data links also fail? Do we need to reroute in
this
> > case

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Sat, 29 Oct 2005 07:47:54 -0400

> Sent: Friday, October 28, 2005 8:11 PM
> To: Zafar Ali (zali); Ong, Lyndon; [email-masked]; 
> Bryskin; Kim Young Hwa; [email-masked]
> > > Zafar Ali (zali); Kim Young Hwa; [email-masked]
> > > What is the utility of having standby control channels, 
> as opposed 
> > > to just having multiple *active* control channels?
> > >
> > 
> Years ago, when we first started on LMP, we had the notion of 
> active and standby control channels and it was George Swallow 
> that pointed out that this was a really *BadIdea*tm.
> 

Good news is that "we" are consistent :-) The bad news is that LMP newly
born RFC still have this notion [no one listened to George :-( ]. Here
are some reasons why "we" think this way: 

- Redundancy/ HA via IP Layer. 
- Taken a CC OOS is simple as putting an IF to the control network OOS,
and other operational simplicities. 
- OOS IF can be repair without impacting other links or LMP CC FSM. 
- One LMP CC FSM per "N" Egress links to control network. 
- LMP CC FSM is up as long as we have connectivity to the neighbor. 
- No need to make special arrangements to make signaling and control
channel consistent. I.e., both LMP and RSVP Hellos fail only when there
is no IP connectivity to the neighbor. 
- Etc. 

Thanks

Regards... Zafar 

> > > A standby signaling controller is an implementation option that 
> > > shouldn't affect the existing GMPLS protocols
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Lyndon
> > > >
> > > > >>>>work are also usable used here OSPF GR, etc. ... on 
> the other
> > > side,
> > > > >>>>than document these tools and provide our 
> experience in using
> > > them;
> > > > >>>>
> > > > >>>>now, before stating there are (potential) 
> problems(s) arising
> -
> > > > >>>>>parallel PSC data links bundled together and 
> controlled by a
> > > single
> > > >
> > > > >>>>>control channel.
> > > > >>>>>>other is for a protocol specification as a 
> solution of that
> .

---

From: <[email-masked]>
Date: Mon, 31 Oct 2005 14:31:42 -0000

Igor....if it's any comfort to you, folks here in BT agree with you.
And I don't care what anyone says about the NMS and the futile attempts
to obsolete it....we will always need this for a whole raft of
functions/reasons....and the closer one gets to the duct the more
important it becomes and the less important a control-plane becomes (at
least dynamic routing aspects).  

regards, Neil 

> Sent: 31 October 2005 14:10
> To: Drake, John E; Zafar Ali (zali); Igor Bryskin
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Kim Young Hwa; [email-masked]
> John,
> > > States are supposed to be destroyed on explicit
> signalling message
> > > (e.g. PathTear or PathErr with the state removal flag), but not
> > > because of the absence of refreshes.
> > >
> [JD]
> 
> Igor,
> 
> Just to be clear, we are talking about RSVP here, and RSVP
> *is* a soft state protocol.  Can you point to any RFC that 
> supports your statements above?
> 
> IB>> Oh, come on, John. You sound like you've been yourself
> in a dormant
> state for a while :=). We've gone a long way since RFC2205.
> In RFC3471, for example, there is a discussion why GMPLS is 
> needed and how is it different from MPLS. One of the 
> differences is the fact that soft state protocols do not work 
> well for non-packet environments. Here is from the RDC3471:
> 
> 
> 
> 9.2. Fault Handling    There are two new faults that must be 
> handled when
> the control   channel is independent of the data channel.  In 
> the first,
> there is a   link or other type of failure that limits the ability of
> neighboring   nodes to pass control messages.  In this situation,
> neighboring nodes   are unable to exchange control messages 
> for a period of
> time.  Once   communication is restored the underlying 
> signaling protocol
> must   indicate that the nodes have maintained their state through the
> failure..
> 
> What is more important is the reality of life: The customers
> simply say that you cannot destroy a user service (or even 
> force any traffic hits) just because you have a problem in 
> the control plane. If this does not fit your soft-state 
> paradigm, than "harden" your protocols or flash them down the 
> toilet and come with something else if you want our business. 
> After all, if we provision the services via NMS, we do not 
> have to destroy the services if we have problems in the 
> management network. It is that simple.
> 
> 
> 
> Igor
> 
> 
> 
> 
> 
> 
>

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 31 Oct 2005 12:41:37 -0800

> 
> [JD]
> IB>> This would require node D, for example, to know exactly what to
do
> with
> the service when it gets notified about the CP failure.
> Policies do not work here. It's totally upto user to decide what to do
> with
> this service.
[JD] 

I don't buy that.  That's what Service Level Agreements are for.

> The only way it can convey this decision is by sending more
> requests to the LSP ingress controller. For instance, the user may
decide
> to
> keep using the service for a while and then delete or reroute it
before
> controller B comes back.
[JD] 

Why would the user be involved any decision other than hanging up?  The
user shouldn't be aware that node B failed.  You are asserting a
particular mode of operation for a service provider network which seems
to require that every instance of every service have its own
individualized recovery plan.

> Neither of your options below therefore works. See also my response to
> Dimitri.
> 
> Igor
> 
> 
> Due to 'CP degraded' notification, nodes C and D will know that B
> failed.
> 
> In option a), local policy, configured via the NMS, at D will tell it
> whether to send a PathErr with state removed and if so, how long to
> wait.  As stated in another e-mail, multiple CP failures are handled
by
> configuration, via the NMS, at intermediate nodes that tell them under
> what circumstances and after what duration to send PathTear and /or
> PathErr with state removed, or whether simply to wait until the
> resources time-out and how long to wait before timing them out.
> 
> In option b) A creates an MBB LSP on the path A, E, F, H, K, D.
> Subsequently, A sends a PathTear to B, and D sends a PathErr with
state
> removed to C.  The MBB LSP was created under policy control, via the
> NMS, at the ingress node, A.
> 
> Here's your initial example:
> 
> A----B------C-----D
> |                 |
> E-----F-----H-----K
> 
> > I have a solution and am planning to write a draft. I'd like this
work
> to
> > live in CCAMP.
> [JD]
> 
> You can't get pre-approval of an I-D.
> 
> >
> > Igor

---

From: "Kim Young Hwa" <[email-masked]>
Date: Tue, 1 Nov 2005 13:03:46 +0900

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.