[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RSVP Graceful Restart Extensions

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