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

[蒋维廉 <[e-mail]>]

Hi, For your first question, I think the key is the restarted node. 
 
As in our early draft 'draft-jian-ccamp-multinodes-rsvp-restart-00', by adopting multicast destination address the restarted node can 
periodically send the GR HELLO message outward in the anterior 1/2 RecoveryTime through all the RSVP interfaces to inform its GR 
capability to its neighbors. When the neighbor receives the GR HELLO request message with this multicast destination address, the 
neighbor should know the source node has been restarted, then the two nodes can enter the GR Recovery stage together. 
 
And in the anterior 1/2 RecoveryTime the restarted node can ignore the Srefresh messages from neighbors. 
 
Do you think this way is helpful?  If you concern this way, I wish you would read our draft,and give us your suggestions. For your another question, I can't understand this: 'Nodes C, D and E are isolated. If this condition persists and node's C,D and E restarts'.      As in your figure, what is the meaning that 'B-x...x-C' or 'E-x...x-F' ?      'node's C,D and E restarts' means the Nodes C, D and E both restart?
  Regards, Jiang weilian


Subject: Questions on RSVP-TE Graceful Restart and the new ExtensionsDate: Fri, 5 Oct 2007 11:18:36 -0500From: [e-mail]: [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 
_________________________________________________________________
MSN 中文网，最新时尚生活资讯，白领聚集门户。
http://cn.msn.com