Re: Two Drafts for Resilience of Control Plane

["Igor Bryskin" <ibryskin@movaz.com>]

John,



This discussion is about resilience of control plane and whether some
standardized solutions (and hence additional work in CCAMP) is needed. So I
disagree with you when you say that the discussion has nothing to do with
NMS, because one can evaluate the resilience only compared with one of some
alternative way of service provisioning and management. I personally do not
see any technical reason why managing services via control plane should be
less resilient than doing so via management plane. However, to achieve this
some additional work is required.



Igor

----- Original Message ----- 
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <neil.2.harrison@bt.com>; <ibryskin@movaz.com>; <zali@cisco.com>;
<i_bryskin@yahoo.com>
Cc: <drake@movaz.com>; <dpapadimitriou@psg.com>;
<dimitri.papadimitriou@alcatel.be>; <yhwkim@etri.re.kr>;
<ccamp@ops.ietf.org>
Sent: Monday, October 31, 2005 9:40 AM
Subject: RE: Two Drafts for Resilience of Control Plane


Neil,

I don't think the discussion, at least from my perspective, has anything
to do with the NMS, other than this strange assertion that the NMS will
always be able to reach every node in the network even if there is a
control plane failure.

I have always considered the control plane to be a component in a larger
system that also includes the NMS, etc.

Thanks,

John

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Monday, October 31, 2005 6:32 AM
> To: ibryskin@movaz.com; Drake, John E; zali@cisco.com;
i_bryskin@yahoo.com
> Cc: drake@movaz.com; dpapadimitriou@psg.com;
> dimitri.papadimitriou@alcatel.be; yhwkim@etri.re.kr;
ccamp@ops.ietf.org
> Subject: RE: Two Drafts for Resilience of Control Plane
>
> 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
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
> > Sent: 31 October 2005 14:10
> > To: Drake, John E; Zafar Ali (zali); Igor Bryskin
> > Cc: drake@movaz.com; dpapadimitriou@psg.com;
> > dimitri.papadimitriou@alcatel.be; Kim Young Hwa; ccamp@ops.ietf.org
> > Subject: Re: Two Drafts for Resilience of Control Plane
> >
> >
> > 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
> >
> >
> >
> >
> >
> >
> >