[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
>
> ibryskin@movaz.com 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.
>>>
>>>
>>>>-----Original Message-----
>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
>>>>Sent: Friday, October 28, 2005 9:56 AM
>>>>To: Igor Bryskin
>>>>Cc: Zafar Ali (zali); Kim Young Hwa; ccamp@ops.ietf.org
>>>>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
>>>>>
>>>>>--- "Zafar Ali (zali)" <zali@cisco.com> 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: owner-ccamp@ops.ietf.org
>>>>>>[mailto:owner-ccamp@ops.ietf.org]
>>>>>>On Behalf Of Kim Young Hwa
>>>>>> Sent: Friday, October 28, 2005 6:04 AM
>>>>>> To: ccamp@ops.ietf.org
>>>>>> Subject: Two Drafts for Resilience of Control Plane
>>>>>>
>>>>>>
>>>>>> 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: yhwkim@etri.re.kr
>>>>>> ===================================> >>
>>>>>>
>>>>>
>>><http://umail.etri.re.kr/External_ReadCheck.aspx?email=ccamp@ops.ietf.or
>>>
>>>>>
>>>g&name=ccamp%40ops.ietf.org&fromemail=yhwkim@etri.re.kr&messageid=%3C863
>>>
>>>>>>0a6db-0c31-49ab-a798-13b0dda04553@etri.re.kr%3E>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>__________________________________
>>>>>Yahoo! Mail - PC Magazine Editors' Choice 2005
>>>>>http://mail.yahoo.com
>>>>>
>>>>>
>>>>>.
>>>>>
>>>
>>>
>>>
>>
>>
>>
>> .
>>
>