Re: RSVP Graceful Restart Extensions

[Arun Satyanarayana <aruns@movaz.com>]

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 <adrian@olddog.co.uk>
> To: rrahman@cisco.com, 'Anca Zamfir' <ancaz@cisco.com>, jisrar@cisco.com,
>      aruns@movaz.com, Lou Berger <lberger@movaz.com>,
>      dimitri.papadimitriou@alcatel.be
> Cc: ccamp@ops.ietf.org
> 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