Carsten,
When fast reroute is invoked the LSP is likely to be taking a less than
optimum path from the point of view of the ingress router. Thus when fast
reroute is invoked the router in the path which has initiated the detour
will signal that fact back to the ingress router. The ingress router can now
calculate the best path to the destination knowing about the failure. If a
secondary path has been configured it will use that because it will be
better than a sub-optimal primary.
Fatst reroute is a short term tactical fix for an LSP wich is initiated by a
transit LSR in the path. The transit LSR cannot know the best path through
the network for the LSP as it isn't the ingress router. Only the ingress
router fully understands the best path (all elements considered) for that
LSP. If no secondary LSP is configured, the ingress router should
recalculate the best path for the LSP if it receives a signal via RSVP that
fast reroute has been invoked.
Dave
-----Original Message-----
From: Strahler, Carsten [mailto:Carsten.Strahler@lambdanet.net]
Sent: 02 July 2002 08:28
To: 'Dave Humphrey'; Strahler, Carsten; juniper-nsp@puck.nether.net
Subject: [j-nsp] AW: MPLS redundancy - fast reroute or secondary path
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