Subject: RE: RSVP Graceful Restart

From: Nurit Sprecher <[email-masked]>
Date: Thu, 23 Oct 2003 16:24:55 +0200

Thanks for responding me. I am glad to see a (in the way) standard for the
Ingress recovery.
Regarding the FRR and Graceful restart I am not sure that the protocol
should not be modified. I'll investigate the issue next week and let you
know. But for sure an informational section should be applied.
Best regards, Nurit.

-----Original Message-----
From: Reshad Rahman [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 02:21
To: Nurit Sprecher
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: Re: RSVP Graceful Restart

Nurit Sprecher wrote:

>Hi,
>I did not have the chance yet to read the draft, but I really believe there
>is a need to extend the general description in the GMPL document.
>I hope that you new definition for the ERO recovery would help also to let
>the Ingress LER to recover.
>

Hi,

Yes, this will also let the ingress recover the ERO.

>
>One more thing that I would like to see in the extension, is how graceful
>restart works together with Fast Reroute Protection. Specifically the
>problematic points are the MP and the PLR. Do you have any intention to
>cover it as well?
>
Regarding GR + FRR, we currently believe that an informational section
would be sufficient, i.e. no need for protocol extensions.

Regards,
Reshad.

>
>Thanks in advance, Nurit.
> 
>

---

From: Nurit Sprecher <[email-masked]>
Date: Thu, 23 Oct 2003 17:13:26 +0200

Hi all,
We are in Seabridge are very interesting in such a solution. The FRR
mechanism is described in the MPLS WG. There is a very general description
in the GMPLS document (in the CCAMP WG) on the graceful restart procedure.
Unfortunately these two mechanisms do not work 'so good' together in the
same network. 
We would like to see a standard document, supplying a mechanism to support
both mechanisms together in the same network and let them work correctly. We
hope that the IETF will cover the issue.
Nurit.

 -----Original Message-----
From: 	Nic Neate [mailto:[email-masked]] 
Sent:	Wednesday, October 22, 2003 17:41
To:	Seabridge - Nurit Sprecher; [email-masked]'; [email-masked]';
[email-masked]'
Cc:	[email-masked]'; [email-masked]'
Subject:	RE: RSVP Graceful Restart

All,

Together with some colleagues at Data Connection, I have done some work
looking at how GMPLS Restart could work with RSVP Fast Reroute LSPs.  While
Restart was originally intended as a recovery mechanism for optical networks
and Fast Reroute more as a packet network protection scheme, they do both
provide data traffic preservation mechanisms that could be usefully deployed
in the same network.  We'd be interested in working with anyone looking at
progressing a solution for this.

There are various complications in recovering RSVP state when a node
supporting backup LSPs restarts, in particular following a failure of the
upstream or downstream protected LSP.  New mechanisms will be required to
reconstruct the FAST_REROUTE, DETOUR, ERO, RRO, SENDER_TSPEC, FLOWSPEC and
SESSION_ATTRIBUTES objects.

Again, we've got some ideas on this.  What is the general level of interest
in this area?

Nic

-----Original Message-----
From: Seabridge - Nurit Sprecher
Sent: Wednesday, October 22, 2003 10:43 AM
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RSVP Graceful Restart

Hi,

---

From: Nic Neate <[email-masked]>
Date: Tue, 28 Oct 2003 09:54:57 -0000

Ok, let me clarify the problem.

RSVP FRR provides fast switchover to a backup LSP in the case of data plane
failure.  If only the control plane, and not the data plane, fails then it
is desirable to use GMPLS Restart rather than FRR switchover.  This provides
even more seamless preservation of data traffic, and means the backups are
still available for any subsequent full data plane failure.  However, there
are problems that need to be solved before FRR LSPs can be recovered using
GMPLS Restart.

In RSVP, GMPLS Restart uses Path/Resv refreshes and the MPLS forwarding
table to reconstruct the control plane.  When FRR is in use, active LSPs may
not be receiving Path/Resv refreshes.

For example, at a merge point on the protected LSP when a failure has
occurred upstream, Path Refreshes arrive only on the backup LSP and not the
protected.  That makes it difficult to construct Path refreshes to be sent
downstream on the protected LSP.  The following questions (among others)
must be answered.

 - How do we know FRR is in use?  This is not obvious when a backup Path
Refresh using SENDER_TEMPLATE specific signaling is received.
 - How do we know which protection method is in use?  In most cases there
will be a single method for the whole network, but not always.
 - How do we reconstruct the FAST_REROUTE object when no Path Refreshes are
arriving for the protected path?  (And how do we know whether the LSP is
being signaled with the FAST_REROUTE object at all and not just the 'local
protection desired' flag?)
 - etc.

Nic

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, October 27, 2003 2:00 PM
To: Nic Neate; Juniper - Kireeti Kompella
Cc: [email-masked]'; [email-masked]
Subject: Re: RSVP Graceful Restart

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
----- Original Message ----- 
From: "Nic Neate" <[email-masked]>
To: "Juniper - Kireeti Kompella" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>; <[email-masked]>
Sent: Monday, October 27, 2003 1:23 PM
Subject: RE: RSVP Graceful Restart

> 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?
> From: Juniper - Kireeti Kompella
> Sent: Friday, October 24, 2003 7:40 PM
> To: Nic Neate
> Hi Nic,
> On Wed, 22 Oct 2003, Nic Neate wrote:
>
> > 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: Nic Neate <[email-masked]>
Date: Tue, 28 Oct 2003 15:47:27 -0000

Hi Alia,

The problem I described was actually at a merge point.

The sequence of events is this.
1.  MP set up as usual.
2.  Upstream failure on protected LSP triggers a reroute at the upstream
PLR.  The MP stops receiving Path Refreshes on the protected LSP.  It
continues to receive them on the merging backup over which data traffic is
also now arriving.
3.  MP has a control plane failure, but data plane survives.
4.  MP control plane restarts and GR mechanisms at that node have to
construct a Path Refresh to send downstream on the protected LSP when the
only Path Refreshes being received are on the merging backup.  There are
various issues here as described in my last email.

I don't think this is an insignificant timing window.  The lack of refreshes
at the MP should be resolved by either local revertive behavior on the
protected LSP or a make-before-break of the protected LSP, but that may take
some time.

Because no Path Refreshes are arriving on the protected LSP in this period,
it is not an option to just use regular restart mechanisms to recover the
LSP and then reinitiate the FRR protection.

Let me know if anything's not clear,

Nic

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, October 28, 2003 3:26 PM
To: Juniper - Kireeti Kompella
Cc: Nic Neate; [email-masked]'; [email-masked]'
Subject: RE: RSVP Graceful Restart

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

At 09:47 AM 10/28/2003, Kireeti Kompella wrote:
>Hi Nic,
>
>On Mon, 27 Oct 2003, Nic Neate wrote:
>
interests
> > you?
>
>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: Nurit Sprecher <[email-masked]>
Date: Tue, 28 Oct 2003 17:55:16 +0200

Hi,
1. There are also issues not necessarily related to multiple errors in the
network. A MP of multiple detours should know which detour should be
refreshed downstream, etc.
2. You say, "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.". 
a. The entire LSP should be tuned with this (upstream detours that are
merged in the restarted node are affected, etc.).  This becomes to be not so
graceful

I think that this interworking of FRR and graceful restart should be
analyzed and the protocol may be needed to support it.
Nurit,

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Tuesday, October 28, 2003 16:47
To: Nic Neate
Cc: [email-masked]'; [email-masked]'
Subject: RE: RSVP Graceful Restart

Hi Nic,

interests

Kireeti.
-------