The way to think about it is this, in a normal case, with no Fast ReRoute,
when you have a failed link the LSR from that failure will send a signal
back to the head-end LER which will mark the LSP down and begin the process
of switching over to a new path. How long that takes will depend on
whether you have a secondary path, a standby secondary path, etc.
With FastReroute the upstream LSR will immediately take the detour path so
that the LSP remains up AND THEN it will signal the LER about the link
failure. With no secondary path already defined, the LER will then compute
a new optimal path for the LSP, build the LSP and then cut the traffic over
to that new LSP. If you have a secondary path already set up it will cut
over to that path without having to compute it first.
So the FRR is really just a stop gap measure to have forwarding continue
during the signalling of the failure and the subsequent LER path change
computations/resignalling/cutover
GK
At 12:28 AM 7/2/2002, Strahler, Carsten wrote:
>Hi Dave,
>
>thanks for your response. You said, that secondary path + fast reroute is
>the fastest option.
>But why should I establish a secondary path when I use fast reroute?
>As I understand fast reroute each LSR on the path computes his own detour.
>When I configure a secondary LSP and the primary fails, the secondary
>becomes active. And if the seconadary fails too fast reroute will be used.
>Am I wrong ?
>
>Carsten
>
> > -----Ursprüngliche Nachricht-----
> > Von: Dave Humphrey [mailto:dave.humphrey@telindus.co.uk]
> > Gesendet: Montag, 1. Juli 2002 18:34
> > An: 'Strahler, Carsten'; juniper-nsp@puck.nether.net
> > Betreff: RE: MPLS redundancy - fast reroute or secondary path
> >
> >
> > There are various options which increase speed of recovery
> > but require more
> > state to be retained.
> >
> > Secondary LSP's can be configured to back-up a Primary, the
> > secondary LSP's
> > can be pre-signalled or not. Pre-signalling cuts down on the
> > time it will
> > take traffic to switch to the secondary because it will
> > already be up. the
> > downside is that the routers on the secondary path will have
> > to maintain
> > "state" for an LSP which is not being used. State ikn the
> > case is the RSVP
> > traffic (mainly refreshes) to maintain the LSP.
> >
> > Fast reroute in Juniper terms should be the quickest way of
> > recovering from
> > LSP failure. Each node in the path calculates a detour around it's
> > downstream neighbor which will kick in if that neighbot
> > dissappears. When
> > the failure is detected the node doing the rerouting will
> > signal back to the
> > ingress LSP that fast reroute has been invoked and the
> > ingress LSP can then
> > make its own decision about re-routing the LSP.
> >
> > If you configure a primary LSP reversion will always take
> > place at least
> > once. To avoid this configure two secondarys rather than a
> > primary and a
> > secondary. With this set-up there is no primary LSP to revert
> > to. Just make
> > sure that the path you want to use first is the secondary you
> > configure
> > first.
> >
> > To summarise:
> >
> > Primary no secondary = slowest. (Primary will recover via IGP
> > if possible)
> > Primary and non standby (non pre signalled) secondary = Next slowest.
> > Primary and standby secondary )pre signalled) = A bit faster
> > than above.
> > Primary and standby secondary with fast reroute = fastest.
> >
> > If reversion is not wanted then configure no primary and two
> > secondaries.
> >
> > Dave
> >
> > -----Original Message-----
> > From: Strahler, Carsten [mailto:Carsten.Strahler@lambdanet.net]
> > Sent: 01 July 2002 17:14
> > To: juniper-nsp@puck.nether.net
> > Subject: MPLS redundancy - fast reroute or secondary path
> >
> >
> > Hi,
> >
> > to minimize the paket loss when a LSP fails Juniper provides
> > two mechansim -
> > fast reroute and secondary path.
> > What are the pro and cons of both ? Are they revertive ?
> >
> > Thanks
> >
> >
> > ------------------------------------------------------------
> > Carsten Strahler
> >
> > IP Planning
> >
> > Lambdanet Communications GmbH (AS 13237)
> > web: www.lambdanet.net
> > -----------------------------------------------------------
> >
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:36 EDT