[c-nsp] RFC4090 and Implementation in Cisco

alaerte.vidali at nsn.com alaerte.vidali at nsn.com
Wed Apr 18 21:32:01 EDT 2007


 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.
========================================================================
=

Tks,
Alaerte



More information about the cisco-nsp mailing list