Re: Questions on RSVP-TE Graceful Restart and the new Extensions

[Dan Li <[e-mail]>]

Questions on RSVP-TE Graceful Restart and the new ExtensionsHi Snigdho,

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.

Regards,

Dan


  ----- Original Message ----- 
  From: Bardalai, Snigdho 
  To: Ccamp (E-mail) 
  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