Questions on RSVP-TE Graceful Restart and the new Extensions

["Bardalai, Snigdho" <[e-mail]>]

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