RE: Two Drafts for Resilience of Control Plane

[<neil.2.harrison@bt.com>]

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
> 
> 
> 
> 
> 
> 
>