[c-nsp] RFC4090 and Implementation in Cisco

[Oliver Boehmer (oboehmer)]

alaerte.vidali at nsn.com <> wrote on Thursday, April 19, 2007 3:32 AM:

>  Do you know if Cisco follows recommendation of RFC4090 in IOS
> 12.2.18.SXF5 to decrease the impact of link flapping when router
> performing FRR detects the interface was recovered (but is flapping)?
> 
> snapshot of RFC4090 concerned the issue
>
========================================================================
> =
> Revertive Behavior
> 
>    Upon a failure event, a protected TE LSP is locally repaired by the
>    PLR.  There are two basic strategies for restoring the TE LSP to a
>    full working path.
> 
>     - Global revertive mode: The head-end LSR of each tunnel is
>       responsible for reoptimizing the TE LSPs that used the failed
>       resource.  There are several potential reoptimization triggers:
>       RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
>       timers.  Note that this re-optimization process may proceed as
>       soon as the failure is detected.  It is not tied to the
>       restoration of the failed resource.
> 
>     - Local revertive mode: Upon detecting that the resource is
>       restored, the PLR re-signals each of the TE LSPs that used to be
>       routed over the restored resource.  Every TE LSP successfully
>       re-signaled along the restored resource is switched back.
> 
>    There are several circumstances in which a local revertive mode
>    might not be desirable.  In the case of resource flapping (not an
>    uncommon failure type), this could generate multiple traffic
>    disruptions. Therefore, in the local revertive mode, the PLR
>    should implement a means to dampen the re-signaling process in
>    order to limit potential disruptions due to flapping.
>
========================================================================


Local revertive mode is not implemented as far as I know. 

As mentioned in my other mail: use link dampening, and if your links are
really not stable, think twice before enabling link-up reoptimization
(which disabled by default). So by default a link coming back into
service is not used by existing TE tunnels until their periodic
reoptimization timer (1 hour) expires.

	oli