[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