Re: Last call - RSVP problems

[Jennifer Yates <jyates@research.att.com>]

Hi Suresh,

>
> Ofcourse, (2) & (3) introduces some problems when the control channel
> comes alive. How do two neighboring nodes sync up on what circuits are
> still alive and what is gone? This is kind of addressed in ATM and we could
> borrow ideas from there. If we all agree on above persistency levels or just
> with (3), then I can provide information on how to sync up etc once nodes
> come back alive.

Another option (as Guangzhi pointed out) is that the refresh still be used, but
state NOT removed on timeout. That way, the refreshes can be used for
re-synching the state, but we don't have the problem of connections being
erroneously removed. It may also have a nice side benefit that if we have a
connection that is not torn down completely when it should have been (ie., some
links still remain up, even though the user attempted to remove the connection),
then we can use out-of-band techniques (e.g., network operator) for tearing down
this state rather than having it sit around in the network forever. The
important point is that the connection is not torn down automatically on loss of
refreshes.

Other solutions are to have the refreshes tunneled around failed signaling
channels, or have nodes downstream of a failure detect the failure and then
generate the necessary refreshes to keep the connection alive. I am not fond of
either of these last two solutions.

Finally, we could introduce a new mechanism for the synching up of state after
signaling node failure.
Borrowing ideas from other technologies is always worth investigating.

I think that this issue needs to be solved before we can take these documents to
last call.

Jen