Subject: RE: RSVP Graceful Restart

From: Nic Neate <[email-masked]>
Date: Mon, 27 Oct 2003 13:23:58 -0000

Hi Kireeti,

As you say, FRR and GR solve very different problems, and that is why it's
desirable to have both in the same network.

The issue with that is not with overlap in the problems they are solving,
but in recovering FRR backup and protected LSPs (which may not be being
refreshed from upstream) after a restart.  Is this a problem that interests
you?

Nic

-----Original Message-----
From: Juniper - Kireeti Kompella 
Sent: Friday, October 24, 2003 7:40 PM
To: Nic Neate
Cc: [email-masked]'; [email-masked]'
Subject: RE: RSVP Graceful Restart

Hi Nic,

On Wed, 22 Oct 2003, Nic Neate wrote:

> Together with some colleagues at Data Connection, I have done some work
> looking at how GMPLS Restart could work with RSVP Fast Reroute LSPs.

FRR and GR solve *very* different problems: the first is for link or
node failures where the data plane is affected, the second for control
plane failures (a special subset of node failures).

Could you explain the problem you see here?

Kireeti.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2003 14:00:19 -0000

Nic,

Could you set out the problem in a couple of paragraphs (perhaps with an example) and let
everyone see what it is you're working on so that they can join in the discussions.

Thanks,
Adrian

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 28 Oct 2003 06:47:11 -0800 (PST)

Hi Nic,

> refreshed from upstream) after a restart.  Is this a problem that interests

Thanks for clarifying.  I agree that networks will have both GR and
FRR.  In principle, I agree that this (recovering FRR sessions during
GR) is a problem that needs to be solved.  However, the premise here
is that during GR (hopefully a small time window, say a couple of
minutes), you have a second failure (of a link or a node).

Yes, it's possible to have multiple failures, but the combination of a
control plane failure recoverable by GR and a link/node failure that
requires FRR seems remote.

A practical solution (that may not satisfy all) is for GR to recover
'regular' LSPs sessions, and to re-initiate FRR sessions; and to abort
GR if a second failure occurs that would have necessitated FRR.

On the other hand, let me not discourage you.  Let's take a look at
solutions, and see how simple/complex they are before ruling on the
protocol work.

Kireeti.
-------

---

From: Alia Atlas <[email-masked]>
Date: Tue, 28 Oct 2003 10:26:28 -0500

Hi Nic & Kireeti,

Why is it necessary to recover a protected LSP between the active PLR and 
the merge node?  That protected LSP will not be used; if one reverts back 
to it, then it can be actively recreated, which has to happen today anyhow.

The merge node can ensure that the primary is recovered for itself and 
downstream.  The PLR can ensure it recovers its backup and the primary itself.

What I am missing in the problem statement?

Thanks,
Alia