The MPLS WG Archive

[Nic Neate <Nic.Neate@dataconnection.com>]

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:adrian@olddog.co.uk]
Sent: Monday, October 27, 2003 2:00 PM
To: Nic Neate; Juniper - Kireeti Kompella
Cc: 'mpls@uu.net'; ccamp@ops.ietf.org
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" <Nic.Neate@dataconnection.com>
To: "Juniper - Kireeti Kompella" <kireeti@juniper.net>
Cc: "'mpls@uu.net'" <mpls@UU.NET>; <ccamp@ops.ietf.org>
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?
>
> Nic
>
> -----Original Message-----
> From: Juniper - Kireeti Kompella
> Sent: Friday, October 24, 2003 7:40 PM
> To: Nic Neate
> Cc: 'mpls@uu.net'; 'ccamp@ops.ietf.org'
> 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.
>
>