It's better to ignore the refresh message for N2 during the recovery
process, i.e., before N2 receives the ACK message from N1 for the Hello message
which indicates N2 restarts, N2 should ignore any refresh messages it received
from N1. When N1 receives the Hello message from N2 in this case, the Srefresh
message should be suppressed in N1 according to RFC3473.
As the editor of GR-description ID, we would like to add more text to
address this important issue if the group come up with the decision.
For the second issue, the RFC3473 can be applied. If the upstream node of
node C and the downstream node of node E both restart, node C and E should wait
until their LSP states recovered. If node D restarts, its LSP states can be
recovered from node C and E according to GR-EXT draft. Actually in the real
deployment, the LSP in data plane is required not to be touched even the control
plane fails, it's a local policy.
----- Original Message -----
Sent: Saturday, October 06, 2007 12:18
AM
Subject: Questions on RSVP-TE Graceful
Restart and the new Extensions
Hi,
I have a couple of questions on RSVP-TE
Graceful Restart and the new extensions being propose in
draft-ietf-ccamp-rsvp-restart-ext-09.
Did anybody come across any issues when the
hello interval duration times the failure multiple (typically 3) is too large
compared to the neighboring node restart duration? For example, if the RSVP-TE
interval is 10 seconds, the multiple is 3 and the neighboring node restarts
within 10 seconds then it is possible that the RSVP-TE hello will never detect
a hello failure.
RFC3473 does describe detection of a node
restart in this case based on a new source instance in the hello message, but
we have come across an issue with NACKs being generated for an Srefresh
message in this scenario.
Please look-at the sequence diagram
below:
N1
N2
|
|
|
X (Restart start)
|
HELLO
|
|-------------------------------->|
|
|
|
SRefresh
|
|-------------------------------->|
|
|
|
HELLO
|
|-------------------------------->|
|
|
|
X (Restart complete)
|
SRefresh
|
|-------------------------------->|
|
NACK
|
|<--------------------------------|
| Path (without recovery label) |
|-------------------------------->|
|
X (resoure allocation failed because the resouces are in use)
|
PathErr
|
|<--------------------------------|
|
PathTear
|
|-------------------------------->|
X (CON
deletion)
X (XCON deletion)
|
|
The issue is because N1 did not detect a
hello failure it continues sending SRefreshes which may get NACKed by N2 once
restart completes because there is no Path state corresponding to the SRefresh
message. This NACK causes a Path refresh message to be generated but there is
no RECOVERY_LABEL because N1 did not yet detect that N2 has restarted because
hello exchanges have not yet started. PLEASE NOTE: This is based on an actual
implementation and a real test.
What is the solution to this issue because
I don't see either N1 or N2 doing anything that is not compliant as per the
current RFCs? Or is there something I have missed?
The other issue I wanted to understand is
with respect to the graceful restart extension. Will the RecoveryPath message
handle issues when communication fails and a node restarts? There may be
issues when somes nodes in the LSP path gets isolated from both upstream and
downstream ends.
Example,
A---B-x...x-C---D---E-x...x-F---G
Nodes C, D and E are isolated. If this
condition persists and node's C,D and E restarts. Will the LSP get deleted
after the recovery timer expires in node D? Can this be prevented ?
Would appreciate your response.
Regards,
Snigdho