[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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).
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Igor Bryskin
> Sent: 31 October 2005 14:10
> To: Drake, John E; Zafar Ali (zali); Igor Bryskin
> Cc: firstname.lastname@example.org; email@example.com;
> firstname.lastname@example.org; Kim Young Hwa; email@example.com
> Subject: Re: Two Drafts for Resilience of Control Plane
> > > >
> > >
> > > 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.
> > >
> 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
> 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.