[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Two Drafts for Resilience of Control Plane
> -----Original Message-----
> From: Igor Bryskin [mailto:ibryskin@movaz.com]
> Sent: Monday, October 31, 2005 7:19 AM
> To: Drake, John E; neil.2.harrison@bt.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
> Subject: Re: Two Drafts for Resilience of Control Plane
>
> John,
>
>
>
> This discussion is about resilience of control plane and whether some
> standardized solutions (and hence additional work in CCAMP) is needed.
[JD]
We're still waiting for you to describe what you think is needed. All
you do is continue to assert that additional work 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.
[JD]
As I said in my note, I don't consider the two to be competing.
> However, to achieve
> this
> some additional work is required.
[JD]
Argument by emphatic repetition?
>
>
>
> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >