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

[Dan Li <[e-mail]>]

Hi,

Please see my comments below.

Regards,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Bardalai, Snigdho" <[e-mail]>; "Ccamp (E-mail)" <[e-mail]>
Sent: Saturday, October 06, 2007 7:12 PM
Subject: Re: Questions on RSVP-TE Graceful Restart and the new Extensions


> 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.

[dan] Agree. Changing the behavior of SRefresh message would not help.

> 
> 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.

[dan] The time window size depends on how quickly the restarted node sends 
out the Hello message after the communication comes back. I would like to see 
N2 ignore all received messages until it receives the ACK of the Hello message 
from N1.
 
> 
> 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
>

[dan] Agree with Adrian.
 
> 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.

[dan] Usually the traffic carried by the data plane is required not be touched
when the control plane fails. So N1 should be very careful to take any actions
to tear down the LSP.

> 
> 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.

[dan] Yes, you're welcome to send us the proposed text for GR-Description ID.

> 
> 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
> 
> 
> 
>