Subject: Re: RSVP Graceful Restart Extensions

From: Reshad Rahman <[email-masked]>
Date: Mon, 01 Mar 2004 10:30:15 -0500

Hi all,

The problems which the 2 drafts address are very similar, but 
draft-aruns addresses a wider issue (full state recovery instead of just 
ERO). The solutions proposed are also very similar: draft-rrahman, which 
was initially presented in the MPLS WG at IETF58, has a new recovery ERO 
object whereas draft-aruns has a new recovery Path msg.

We are interested in merging the drafts.

In our opinion, draft-aruns has the following potential issues which 
should be addressed:
- Downstream neighbour of restarting node sends RecoveryPath for *each* 
LSP associated with the restarting node for which it has sent a Resv 
message. With lots of LSPs this could be wasteful since the restarting 
node may need the RecoveryPath for only a small subset of LSPs. One way 
to avoid this is e.g. to define a new hop-by-hop "recovery" object (or 
flag) in the Path msg where each node indicates to its downstream nbor 
whether it would want the RecoveryPath message for that LSP if it restarts.
- There is no mention of "pacing" RecoveryPath messages. For large 
number of LSPs this could be an issue. There should be a mechanism 
similar to section 9.5.3. of RFC3473.

Regards,
Reshad.

Arun Satyanarayana wrote:

>Adrian,
>
>The following is the problem space as we see it (this includes GMPLS):
>
>  - Recovery of *full* signaling state on ingress nodes after a restart.
>
>  - Recovery of *full* signaling state transit nodes after a restart. (Egress
>    is already covered by existing mechanisms.)
>
>  - Full signaling state includes: dynamically computed objects such as
>    ERO/RRO; HOP when forwarding state is not saved across a restart; and any
>    other objects including transparently processed objects.
>
>  - Perform all such recovery without perturbing the signaling state on any of
>    the other nodes participating in the LSP.
>
>  - Maintaining backwards compatibility:
>    - Notably with existing hello mechanisms as defined in rfc3209 and
>      rfc3473.
>
>
>The following parts of the problem space are being addressed in
>draft-aruns-ccamp-rsvp-restart-ext-00.txt:
>
>  - Address single node restarts under all conditions including when the
>    restarting node is the ingress, and, when the ingress does not save full
>    or partial forwarding state across the restart. Note that this does not
>    require any signaling state beyond interface configuration to be restored
>    after a restart. Also covered is the case where the restarting node
>    dynamically adds/computes/changes any objects in the received Path
>    message.
>
>  - Achieve recovery without perturbing the signaling state on the remaining
>    participating nodes of the LSP.
>
>  - Fully backwards compatible with existing implementations.
>
>
>We see the following limitations with the alternate solution in
>draft-rahman-rsvp-restart-extensions-00.txt:
>
>  - Ingress node restarts are not addressed (or, require some signaling state
>    saved across the restart).
>
>  - There could be backward compatibility issues with the change to the Hello
>    message contents (Restart Caps object contents, specifically).
>
>  - The change to Hellos, is to address adjaceny node restarts, which is in
>    itself limited to two adjacent nodes. Beyond this, the solution is the
>    same as in rfc3473. The following example explains the situation (as
>    applicable to draft-rahman-rsvp-restart-extensions-00.txt):
>
>           R1-------R2-------R3-------R4
>
>    An LSP spans across R1-R2-R3-R4. If R2, R3 and R4 restart simultaneously,
>    without locally saved signaling state on at least R3 (i.e., R3 is able to
>    recover mandatory signaling state on its own) the following happens: R1
>    sends a Path with Recovery Label to R2. R2 may at best recover the
>    outgoing interface information from the forwarding state. R2 then sends a
>    Path with a minimal Recovery ERO (eg: incoming interface on R2, R4 as
>    loose). R3 does the same. Effectively, this is the same behaviour as
>    defined in RFC3473 (with clarification regarding contents of the
>    transmitted [Recovery] ERO).
>
>    (Please see section 9.5.2, paragraph 4 "When a node receives a Path
>    message during the Recovery Period, ..." which covers the adjacent node
>    restart case, when a Path message could be received by the downstream
>    restarting node without a Recovery Label).
>
>Thanks,
>_arun_
>============================================================
>On Sat, 21 Feb 2004, Adrian Farrel wrote:
>
>  
>
>>Date: Sat, 21 Feb 2004 22:13:31 -0000
>>From: Adrian Farrel <[email-masked]>
>>To: [email-masked], 'Anca Zamfir' <[email-masked]>, [email-masked],
>>     [email-masked], Lou Berger <[email-masked]>,
>>     [email-masked]
>>Cc: [email-masked]
>>Subject: RSVP Graceful Restart Extensions
>>
>>Hi all,
>>
>>draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
>>draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.
>>
>>I would appreciate your views on how the problem (rather than the solution differs).
>>
>>If the overlap between the problems is significant, can you tell me whether is likelihood
>>of persuading you to merge the drafts or whether the solutions are so radically different
>>that the WG must select one solution or the other.
>>
>>Thanks,
>>Adrian
>>    
>>
>
>  
>