Subject: RE: Two Drafts for Resilience of Control Plane

From: "Drake, John E" <[email-masked]>
Date: Mon, 31 Oct 2005 07:26:06 -0800

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]]
> Sent: Monday, October 31, 2005 7:19 AM
> To: Drake, John E; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
[email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, October 31, 2005 6:32 AM
> > To: [email-masked]; Drake, John E; [email-masked];
> [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked];
> [email-masked]
> > 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: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Igor Bryskin
> > > 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]
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 31 Oct 2005 10:42:36 -0500

John,

[JD]

No John,

This is not true, I gave you a very specific problem - provide mechanisms to
manage LSPs with impaired control plane (when one or more controllers are
out of service).
You said that this is not a problem, because RSVP is a soft state protocol
and once there are no refreshes the control data plane states must be
destroyed and hence there is nothing to manage.
And I tried very hard to explain you why this is not acceptable and hence
must be addressed.
I have a solution and am planning to write a draft. I'd like this work to
live in CCAMP.

Igor

with
do
should be
[JD]

[JD]

anything
will
larger
[email-masked]
not