The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <HBP2CP$6F20D5377D18994A28CE4DF5D4F8E331@libero.it>, "john151@libero
.it" writes:
> Hi all,
> 
> i see at least two advantages in using Opaque LSA insted of PathErr (quite th
> e same for the Notifies ) in this scenario: precalculated and presignalled ba
> ckup disjoint paths for protected LSPs in MPLS Network, availability of fast 
> detection mechanism ( from lower levels ) of link failure.
> 
> 1) Since Opaque LSAs don' t trigger an SPF calculation in the routers they cr
> oss, all the Network is soon informed about the link failure event and IN PAR
> ALLEL each router can do the label switching on the backup LSPs ( after havin
> g controlled the presence of protected LSPs starting from it and interested b
> y the link failure ). 
> 
> 2) Since i refer to protected LPSs ( they are relatively few ), thinking in a
>  scenario in which there should be a return to the first active LSP when the 
> link failed returns to be UP ( that is a second switch from backup LSP to the
>   first active LSP ), could it be not necessary to send the PathTears immedia
> tely to cleanup resources? This will bring two beneficts: no PathTears and Re
> svTear sent immediately in  the Network and no signalling messages storm when
>  the link returns up ( after a not long period ), when it's probable that all
>  the backup LSPs will return on that link (the link that went down). 
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni di Giacomo


The way this works in practice depends on whether the tunnel is
configured to take a specific primary path or is dymanicly routed but
in either case a *new* primary LSP is created with a new LSP-id but
sharing bandwidth as in make-before-break.

If path is configured, the LSR has two choices, 1) retry signaling on
a new primary LSP as long as the immediate next hop in the path is UP
(ie: don't trust the IGP, some argue don't run one), 2) wait until the
IGP indicates the path is feasible then signal a new primary LSP.  The
former is problematic particularly with no IGP at all (retry often and
incur high overhead, or long retry intervals and slow reaction
although this could be considered a feature - see below).

If the primary path is dynamic, then the standby will carry traffic
only as long as it take to bring up a new primary and a new standby.
At some point all three LSPs are up and sharing bandwidth.  Traffic is
switched to the new primary.  The new primary is again fully
protected, or if there is now only one link somewhere, maximally
protected.  If the link comes back up, the adaptivity implementation
(longer term timers) reoptimizes the bandwidth, gradually moving
traffic back to the previously failed link.

A good feature of dynamic path selection with adaptivity is that links
which fail once often come up and fail again very shortly after, often
more than once.  If traffic is slow to move back to it the impact of
subsequent failures is less.  If a link is intermittent with a short
cycle, it will remain unused, even during the time that it is up.

To directly answer your concern, the *new* primary LSP is distinct
from the old one.  The LSP-id is changed.  They share bandwidth.
Tearing down the old primary LSP has no impact on signaling a new one.

Curtis