Re: Control plane resiliency

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

Hi all,
              a quick comment in line.

Regards

Diego



"Adrian Farrel" <adrian@olddog.co.uk>@ops.ietf.org on 31/10/2005 23.37.34

Please respond to "Adrian Farrel" <adrian@olddog.co.uk>

Sent by:    owner-ccamp@ops.ietf.org


To:    <ccamp@ops.ietf.org>
cc:

Subject:    Control plane resiliency

[CUT]

4. *The* controller resiliency issue appears to be: How to manage and
teardown an LSP downstream of a broken controller. I do not understand why
the answer is not one of:
a. Wait for the controller to be repaired
b. Use the management plane
It seems that in-place modification of GMPLS LSPs is not a common
operational feature for an active LSP. This leaves us with teardown. For
teardown, option a does not seem to be very painful, but if it does cause
problems (and alarms *will* be raised) option b is available.
[dc] In last DRCN (http://drcn2005.telecomitalialab.com/) ww presented a
paper that illustrates a possible solution of this issues.
It works using signalling messages.
If someone is interesed in reading the paper please write me and I'll send
the paper.


[CUT]

8. In a transport network, we must accept an operator's right to entirely
eliminate soft state timeouts. That is, the failure of the control plane
for any length of time, must not impact the traffic (note that even though
RSVP is a soft state protocol, the refresh period may be set so high (32
bitsworth of milliseconds) as to be practically infinite. Note
specifically that the failure of Hellos is used in RFC3473 to temporarily
"turn off" the soft state nature of RSVP-TE.
[dc] I strongly agree with this.

[CUT]

Thanks,
Adrian