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

["Adrian Farrel" <[e-mail]>]

Hi Snigdho,

Always good to have reports of use of the more advanced functions.

Some thoughts...

We can do some work to fix up the SRefresh behavior, but I don't think it 
actually helps, because if Summary Refresh is not being used, exactly the 
same scenario can arise with a Path Refresh. In other words, fixing the 
SRefresh would not fix the problem.

In some circumstances, the window in the scenario you have drawn is very 
small.. The SRefresh *and* the Path Refresh must be sent by N1 between N2 
completing restart and N2's first Hello arriving at N1. One could say that 
N2 should ignore all received messages until it has Hellos up and running. 
That would guarantee that N1 knew about the restart.

That simply requires that when startup completes N2 must:
- either
    - immediately send a new Hello to each neighbor
  or
     - respond to any first received message from a
       neighbor with which it does not have an active
       Hello exchange by sending a Hello
- ignore all subsequent RSVP messages except Hellos
  from neighbors with which it does not have an active
  Hello exchange

We should understand why N2 sends PathErr. "Resources in use" could either 
mean that *all* resources are already in use, or the limit resources 
required on the Path message (i.e. Upstream Label or Label Set) are already 
in use.

In all cases, the error code should indicate that the requested new resource 
allocation cannot be satisfied (N2 thinks this is a new LSP).

In the case of no resource being available, the PathErr MUST [3473] contain 
"Routing problem/MPLS label allocation failure".
In the case of failure because the Label Set cannot be satisfied, the 
PathErr MUST [3473] carry "Routing problem/Label Set". In the case of 
failure because of Upstream Label N2 MUST [3473] send a PathErr with 
"Routing problem/Unacceptable label value" and MAY include an Acceptable 
Label Set object.

So, I would suggest that N1 may be over-reacting to the PathErr from N2. 
Presumably N1 expects that the LSP is up and running - ii already has Resv 
state and data is probably flowing. So any of these three error codes (all 
of which represent LSP setup errors) should cause N1 to suspect something 
slightly strange is happening. Before getting too agitated and taking the 
dramatic step of tearing the LSP, it should just check that everything else 
is functioning correctly, and part of that process would be to send a Hello 
if one has not been sent/received for a considerable period of time.

In fact, your situation arises either because the Hello period is set far to 
large (i.e. larger than the neighbor's whole restart cycle) or because N1 is 
not considering any difference between normal and hello-degraded states. The 
former is a configuration error. The latter should allow the PathErr to be 
treated with more care than a simple PathTear.

With regard to your second question. Yes, we believe that all cases of 
multiple failures are handled by the restart procedures without refresh 
failure causing state to be deleted. However, the text for this was removed 
from the graceful restart draft before publication (actually, long ago) as 
second order failures really clogged up the draft. Instead, we have 
draft-ietf-ccamp-gr-description-00.txt.

I suggest:

1. The situation you describe in your first scenario (with and without 
SRefresh) should be included in the GR-Description I-D.

2. You should check the GR-Description I-D to see whether it answers your 
questions about multiple failures.

In both cases, I am sure the authors would welcome suggested text and 
pointer to what they could change.

Cheers,
Adrian
----- Original Message ----- 
From: "Bardalai, Snigdho" <[e-mail]>
To: "Ccamp (E-mail)" <[e-mail]>
Sent: Friday, October 05, 2007 5:18 PM
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