[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two Drafts for Resilience of Control Plane
Igor Bryskin wrote:
igor - my two cents
RSVP over time has progressively borrowed mechanisms from "hard-state"
protocols, explicit deletion using PathTear is most noticeable and
initial example of this evolution !
but in any case, RSVP still relies is on idem-potent soft-states that
are flushed when not refreshed after certain time interval (or self-
maintained if previously negotiated) this prevents orphans in the
network (so unused resources) and provides for resilience - hence there
is by no means a need to introduce an additional protocol mechanism to
trigger or not such event via the "control plane" -
Refreshes are useful mechanism but only between neighbors that maintain
Hello communication. In this case the absence of Path refreshes is as good
indication that data plane must be destroyed as received PathTear message.
the base function of state refresh and usefulness is independent of
hello adjacency maintenance (or any other control channel maintenance)
However, when a controller does not receive Path refreshes from a neighbor
it does not have any control plane communication with, it can assume neither
a problem in the data plane nor intention to destroy it.
as the node did not negotiate any channel/node fault recovery (due in
part. to the absence of Hello adjacency with its neighbor) and if no
other independent control channel failure is provided (this is an add-on
of RFC3471/3), the simple absence of refresh is simply intepreted as
you are mis-interpreting the following sentence of RFC3471
" Note that these cases only apply when there are mechanisms to detect
data channel failures independent of control channel failures."
there is no retro-fit on the use of Refreshes in absence of control
channel failure detection mechanism
Hence, as it was
specified in RFC3471, it *must* maintain both control and data plane states
throughout the failure.
btw, the paragraph you mention in RFC3471 does not say "soft state
protocols do not work well for non-packet environments" this is your
ps: you are still free to make use of RFC3472 in case (as you were
apparently looking for something else ;-)
Igor Bryskin wrote:
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
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,
example, there is a discussion why GMPLS is needed and how is it
from MPLS. One of the differences is the fact that soft state protocols
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
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
time. Once communication is restored the underlying signaling
must indicate that the nodes have maintained their state through the
What is more important is the reality of life: The customers simply say
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
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,
we provision the services via NMS, we do not have to destroy the
we have problems in the management network. It is that simple.