Re: Two Drafts for Resilience of Control Plane

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

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