draft-ietf-rtgwg-uloop-delay-05.txt   draft-ietf-rtgwg-uloop-delay-06.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene Internet-Draft B. Decraene
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: December 23, 2017 C. Filsfils Expires: February 9, 2018 C. Filsfils
Cisco Systems Cisco Systems
P. Francois P. Francois
Individual Individual
June 21, 2017 August 8, 2017
Micro-loop prevention by introducing a local convergence delay Micro-loop prevention by introducing a local convergence delay
draft-ietf-rtgwg-uloop-delay-05 draft-ietf-rtgwg-uloop-delay-06
Abstract Abstract
This document describes a mechanism for link-state routing protocols This document describes a mechanism for link-state routing protocols
to prevent local transient forwarding loops in case of link failure. to prevent local transient forwarding loops in case of link failure.
This mechanism proposes a two-steps convergence by introducing a This mechanism proposes a two-step convergence by introducing a delay
delay between the convergence of the node adjacent to the topology between the convergence of the node adjacent to the topology change
change and the network wide convergence. and the network wide convergence.
As this mechanism delays the IGP convergence it may only be used for As this mechanism delays the IGP convergence it may only be used for
planned maintenance or when fast reroute protects the traffic between planned maintenance or when fast reroute protects the traffic between
the link failure time and the IGP convergence. the link failure time and the IGP convergence.
The proposed mechanism will be limited to the link down event in The proposed mechanism is limited to the link down event in order to
order to keep simplicity. keep the mechanism simple.
Simulations using real network topologies have been performed and Simulations using real network topologies have been performed and
show that local loops are a significant portion (>50%) of the total show that local loops are a significant portion (>50%) of the total
forwarding loops. forwarding loops.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2017. This Internet-Draft will expire on February 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Micro-forwarding loops and some potential solutions are well Micro-forwarding loops and some potential solutions are well
described in [RFC5715]. This document describes a simple targeted described in [RFC5715]. This document describes a simple targeted
mechanism that solves micro-loops that are local to the failure; mechanism that prevents micro-loops that are local to the failure.
based on network analysis, these are a significant portion of the Based on network analysis, local failure make up a significant
micro-forwarding loops. A simple and easily deployable solution for portion of the micro-forwarding loops. A simple and easily
these local micro-loops is critical because these local loops cause deployable solution for these local micro-loops is critical because
some traffic loss after a fast-reroute alternate has been used (see these local loops cause some traffic loss after a fast-reroute
Section 2.1). alternate has been used (see Section 2.1).
Consider the case in Figure 1 where S does not have an LFA to protect Consider the case in Figure 1 where S does not have an LFA to protect
its traffic to D. That means that all non-D neighbors of S on the its traffic to D. That means that all non-D neighbors of S on the
topology will send to S any traffic destined to D if a neighbor did topology will send to S any traffic destined to D if a neighbor did
not, then that neighbor would be loop-free. Regardless of the not, then that neighbor would be loop-free. Regardless of the
advanced fast-reroute (FRR) technique used, when S converges to the advanced fast-reroute (FRR) technique used, when S converges to the
new topology, it will send its traffic to a neighbor that was not new topology, it will send its traffic to a neighbor that was not
loop-free and thus cause a local micro-loop. The deployment of loop-free and thus cause a local micro-loop. The deployment of
advanced fast-reroute techniques motivates this simple router-local advanced fast-reroute techniques motivates this simple router-local
mechanism to solve this targeted problem. This solution can be work mechanism to solve this targeted problem. This solution can be work
skipping to change at page 4, line 21 skipping to change at page 4, line 21
| | ^ | | ^
10 | | 5 | T 10 | | 5 | T
| | | | | |
E--------C E--------C
| 1 | 1
1 | 1 |
S S
Figure 2 - RSVP-TE FRR case Figure 2 - RSVP-TE FRR case
In the Figure 2, an RSVP-TE tunnel T, provisioned on C and In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE
terminating on B, is used to protect against C-B link failure (IGP tunnel T, provisioned on C and terminating on B, is used to protect
shortcut is activated on C). The primary path of T is C->B and FRR the traffic against C-B link failure (IGP shortcut is activated on
is activated on T providing an FRR bypass or detour using path C). The primary path of T is C->B and FRR is activated on T
C->E->A->B. On the router C, the nexthop to D is the tunnel T thanks providing an FRR bypass or detour using path C->E->A->B. On the
to the IGP shortcut. When C-B link fails: router C, the nexthop to D is the tunnel T thanks to the IGP
shortcut. When C-B link fails:
1. C detects the failure, and updates the tunnel path using 1. C detects the failure, and updates the tunnel path using
preprogrammed FRR path, the traffic path from S to D becomes: preprogrammed FRR path, the traffic path from S to D becomes:
S->E->C->E->A->B->A->D. S->E->C->E->A->B->A->D.
2. In parallel, on router C, both the IGP convergence and the TE 2. In parallel, on router C, both the IGP convergence and the TE
tunnel convergence (tunnel path recomputation) are occurring: tunnel convergence (tunnel path recomputation) are occurring:
* The Tunnel T path is recomputed and now uses C->E->A->B. * The Tunnel T path is recomputed and now uses C->E->A->B.
skipping to change at page 6, line 14 skipping to change at page 6, line 15
| S->D | t0+443msec | | E updates its RIB/FIB | | S->D | t0+443msec | | E updates its RIB/FIB |
| Traffic | | | for D | | Traffic | | | for D |
| OK | | | | | OK | | | |
| | | | | | | | | |
| | t0+470msec | | E convergence ends | | | t0+470msec | | E convergence ends |
+-----------+------------+------------------+-----------------------+ +-----------+------------+------------------+-----------------------+
Route computation event time scale Route computation event time scale
The issue described here is completely independent of the fast- The issue described here is completely independent of the fast-
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). The reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the
protection enabled by fast-reroute is working perfectly, but ensures primary path uses hop-by-hop routing. The protection enabled by
a protection, by definition, only until the PLR has converged. When fast-reroute is working perfectly, but ensures a protection, by
implementing FRR, a service provider wants to guarantee a very definition, only until the PLR has converged. When implementing FRR,
limited loss of connectivity time. The previous example shows that a service provider wants to guarantee a very limited loss of
the benefit of FRR may be completely lost due to a transient connectivity time. The previous example shows that the benefit of
forwarding loop appearing when PLR has converged. Delaying FIB FRR may be completely lost due to a transient forwarding loop
updates after the IGP convergence may allow to keep the fast-reroute appearing when PLR has converged. Delaying FIB updates after the IGP
path until the neighbors have converged and preserves the customer convergence may allow to keep the fast-reroute path until the
traffic. neighbors have converged and preserves the customer traffic.
2.2. Network congestion 2.2. Network congestion
1 1
D ------ C D ------ C
| | | |
1 | | 5 1 | | 5
| | | |
A -- S ------ B A -- S ------ B
/ | 1 / | 1
F E F E
Figure 3
In the figure above, as presented in Section 1, when the link S-D In the figure above, as presented in Section 1, when the link S-D
fails, a transient forwarding loop may appear between S and B for fails, a transient forwarding loop may appear between S and B for
destination D. The traffic on the S-B link will constantly increase destination D. The traffic on the S-B link will constantly increase
due to the looping traffic to D. Depending on the TTL of the due to the looping traffic to D. Depending on the TTL of the
packets, the traffic rate destinated to D and the bandwidth of the packets, the traffic rate destined to D, and the bandwidth of the
link, the S-B link may be congested in few hundreds of milliseconds link, the S-B link may become congested in a few hundreds of
and will stay overloaded until the loop is solved. milliseconds and will stay congested until the loop is eliminated.
The congestion introduced by transient forwarding loops is The congestion introduced by transient forwarding loops is
problematic as it is impacting traffic that is not directly concerned problematic as it can affect traffic that is not directly affected by
by the failing network component. In our example, the congestion of the failing network component. In our example, the congestion of the
the S-B link will impact some customer traffic that is not directly S-B link will impact some customer traffic that is not directly
concerned by the failure: e.g. A to B, F to B, E to B. Some class affected by the failure: e.g. A to B, F to B, E to B. Class of
of services may be implemented to mitigate the congestion, but some service may mitigate the congestion for some traffic. However, some
traffic not directly concerned by the failure would still be dropped traffic not directly affected by the failure will still be dropped as
as a router is not able to identify the looping traffic from the a router is not able to distinguish the looping traffic from the
normally forwarded traffic. normally forwarded traffic.
3. Overview of the solution 3. Overview of the solution
This document defines a two-step convergence initiated by the router This document defines a two-step convergence initiated by the router
detecting the failure and advertising the topological changes in the detecting a failure and advertising the topological changes in the
IGP. This introduces a delay between the convergence of the local IGP. This introduces a delay between the convergence of the local
router and the network wide convergence. router and the network wide convergence.
The proposed solution is kept limited to local link down events for The proposed solution is limited to local link down events in order
simplicity reason. to keep the solution simple.
This ordered convergence, is similar to the ordered FIB proposed This ordered convergence, is similar to the ordered FIB proposed
defined in [RFC6976], but limited to only a "one hop" distance. As a defined in [RFC6976], but it is limited to only a "one hop" distance.
consequence, it is simpler and becomes a local only feature not As a consequence, it is simpler and becomes a local only feature that
requiring interoperability; at the cost of only covering the does not require interoperability. This benefit comes at the expense
transient forwarding loops involving this local router. The proposed of eliminating transient forwarding loops involving the local router.
mechanism also reuses some concept described in The proposed mechanism also reuses some concepts described in
[I-D.ietf-rtgwg-microloop-analysis] with some limitations. [I-D.ietf-rtgwg-microloop-analysis].
4. Specification 4. Specification
4.1. Definitions 4.1. Definitions
This document will refer to the following existing IGP timers: This document will refer to the following existing IGP timers:
o LSP_GEN_TIMER: The delay used to batch multiple local events in o LSP_GEN_TIMER: The delay used to batch multiple local events in
one single local LSP/LSA update. It is often associated with a one single local LSP/LSA update. It is often associated with a
damping mechanism to slow down reactions by incrementing the timer damping mechanism to slow down reactions by incrementing the timer
skipping to change at page 8, line 12 skipping to change at page 8, line 12
o ULOOP_DELAY_DOWN_TIMER: used to slow down the local node o ULOOP_DELAY_DOWN_TIMER: used to slow down the local node
convergence in case of link down events. convergence in case of link down events.
4.2. Current IGP reactions 4.2. Current IGP reactions
Upon a change of the status of an adjacency/link, the existing Upon a change of the status of an adjacency/link, the existing
behavior of the router advertising the event is the following: behavior of the router advertising the event is the following:
1. The Up/Down event is notified to the IGP. 1. The Up/Down event is notified to the IGP.
2. The IGP processes the notification and postpones the reaction in 2. The IGP processes the notification and postpones the reaction for
LSP_GEN_TIMER msec. LSP_GEN_TIMER msec.
3. Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and 3. Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and
floods it. floods it.
4. The SPF computation is scheduled in SPF_DELAY msec. 4. The SPF computation is scheduled in SPF_DELAY msec.
5. Upon SPF_DELAY expiration, the SPF is computed, then the RIB and 5. Upon SPF_DELAY timer expiration, the SPF is computed, then the
FIB are updated. RIB and FIB are updated.
4.3. Local events 4.3. Local events
The mechanism described in this document assumes that there has been The mechanism described in this document assumes that there has been
a single link failure as seen by the IGP area/level. If this a single link failure as seen by the IGP area/level. If this
assumption is violated (e.g. multiple links or nodes failed), then assumption is violated (e.g. multiple links or nodes failed), then
standard IP convergence MUST be applied (as described in standard IP convergence MUST be applied (as described in
Section 4.2). Section 4.2).
To determine if the mechanism can be applicable or not, an To determine if the mechanism can be applicable or not, an
implementation SHOULD implement a logic to correlate the protocol implementation SHOULD implement logic to correlate the protocol
messages (LSP/LSA) received during the SPF scheduling period in order messages (LSP/LSA) received during the SPF scheduling period in order
to determine the topology changes that occured. This is necessary as to determine the topology changes that occured. This is necessary as
multiple protocol messages may describe the same topology change and multiple protocol messages may describe the same topology change and
a single protocol message may describe multiple topology changes. As a single protocol message may describe multiple topology changes. As
a consequence, determining a particular topology change MUST be a consequence, determining a particular topology change MUST be
independent of the order of reception of those protocol messages. independent of the order of reception of those protocol messages.
How the logic works is let to implementation details. How the logic works is left to the implementation.
Using this logic, if an implementation determines that the associated Using this logic, if an implementation determines that the associated
topology change is a single local link failure, then the router MAY topology change is a single local link failure, then the router MAY
use the mechanism described in this document, otherwise the standard use the mechanism described in this document, otherwise the standard
IP convergence MUST be used. IP convergence MUST be used.
Example: Example:
+--- E ----+--------+ +--- E ----+--------+
| | | | | |
A ---- B -------- C ------ D A ---- B -------- C ------ D
Figure 4
Let router B be the computing router when the link B-C fails. B Let router B be the computing router when the link B-C fails. B
updates its local LSP/LSA describing the link B->C as down, C does updates its local LSP/LSA describing the link B->C as down, C does
the same, and both start flooding their updated LSP/LSAs. During the the same, and both start flooding their updated LSP/LSAs. During the
SPF_DELAY period, B and C learn all the LSPs/LSAs to consider. B SPF_DELAY period, B and C learn all the LSPs/LSAs to consider. B
sees that C is flooding as down a link where B is the other end and sees that C is flooding an advertisement that indicates that a link
that B and C are describing the same single event. Since B receives is down, and B is the other end of that link. B determines that B
no other changes, B can determine that this is a local link failure and C are describing the same single event. Since B receives no
and may decide to activate the mechanism described in this document. other changes, B can determine that this is a local link failure and
may decide to activate the mechanism described in this document.
4.4. Local delay for link down 4.4. Local delay for link down
Upon an adjacency/link down event, this document introduces a change Upon an adjacency/link down event, this document introduces a change
in step 5 (Section 4.2) in order to delay the local convergence in step 5 (Section 4.2) in order to delay the local convergence
compared to the network wide convergence: the node SHOULD delay the compared to the network wide convergence. The new step 5 is
forwarding entry updates by ULOOP_DELAY_DOWN_TIMER. Such delay described below:
SHOULD only be introduced if all the LSDB modifications processed are
only reporting a single local link down event (Section 4.3). If a 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the
subsequent LSP/LSA is received/updated and a new SPF computation is condition of a single local link-down event has been met, then an
triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the update of the RIB and the FIB SHOULD be delayed for
same evaluation SHOULD be performed. ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD
be updated immediately.
If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running,
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated
as part of the new convergence event.
As a result of this addition, routers local to the failure will As a result of this addition, routers local to the failure will
converge slower than remote routers. Hence it SHOULD only be done converge slower than remote routers. Hence it SHOULD only be done
for a non-urgent convergence, such as for administrative de- for a non-urgent convergence, such as for administrative de-
activation (maintenance) or when the traffic is protected by fast- activation (maintenance) or when the traffic is protected by fast-
reroute. reroute.
5. Applicability 5. Applicability
As previously stated, the mechanism only avoids the forwarding loops As previously stated, this mechanism only avoids the forwarding loops
on the links between the node local to the failure and its neighbor. on the links between the node local to the failure and its neighbors.
Forwarding loops may still occur on other links. Forwarding loops may still occur on other links.
5.1. Applicable case: local loops 5.1. Applicable case: local loops
A ------ B ----- E A ------ B ----- E
| / | | / |
| / | | / |
G---D------------C F All the links have a metric of 1 G---D------------C F All the links have a metric of 1
Figure 2 Figure 5
Let us consider the traffic from G to F. The primary path is Let us consider the traffic from G to F. The primary path is
G->D->C->E->F. When link C-E fails, if C updates its forwarding G->D->C->E->F. When link C-E fails, if C updates its forwarding
entry for F before D, a transient loop occurs. This is sub-optimal entry for F before D, a transient loop occurs. This is sub-optimal
as C has FRR enabled and it breaks the FRR forwarding while all as C has FRR enabled and it breaks the FRR forwarding while all
upstream routers are still forwarding the traffic to itself. upstream routers are still forwarding the traffic to itself.
By implementing the mechanism defined in this document on C, when the By implementing the mechanism defined in this document on C, when the
C-E link fails, C delays the update of its forwarding entry to F, in C-E link fails, C delays the update of its forwarding entry to F, in
order to let some time for D to converge. FRR keeps protecting the order to allow some time for D to converge. FRR on C keeps
traffic during this period. When the timer expires on C, its protecting the traffic during this period. When the timer expires on
forwarding entry to F is updated. There is no transient forwarding C, its forwarding entry to F is updated. There is no transient
loop on the link C-D. forwarding loop on the link C-D.
5.2. Non applicable case: remote loops 5.2. Non applicable case: remote loops
A ------ B ----- E --- H A ------ B ----- E --- H
| | | |
| | | |
G---D--------C ------F --- J ---- K G---D--------C ------F --- J ---- K
All the links have a metric of 1 except BE=15 All the links have a metric of 1 except BE=15
Figure 3 Figure 6
Let us consider the traffic from G to K. The primary path is Let us consider the traffic from G to K. The primary path is
G->D->C->F->J->K. When the C-F link fails, if C updates its G->D->C->F->J->K. When the C-F link fails, if C updates its
forwarding entry to K before D, a transient loop occurs between C and forwarding entry to K before D, a transient loop occurs between C and
D. D.
By implementing the mechanism defined in this document on C, when the By implementing the mechanism defined in this document on C, when the
link C-F fails, C delays the update of its forwarding entry to K, link C-F fails, C delays the update of its forwarding entry to K,
letting time for D to converge. When the timer expires on C, its allowing time for D to converge. When the timer expires on C, its
forwarding entry to F is updated. There is no transient forwarding forwarding entry to F is updated. There is no transient forwarding
loop between C and D. However, a transient forwarding loop may still loop between C and D. However, a transient forwarding loop may still
occur between D and A. In this scenario, this mechanism is not occur between D and A. In this scenario, this mechanism is not
enough to address all the possible forwarding loops. However, it enough to address all the possible forwarding loops. However, it
does not create additional traffic loss. Besides, in some cases does not create additional traffic loss. Besides, in some cases
-such as when the nodes update their FIB in the following order C, A, -such as when the nodes update their FIB in the following order C, A,
D, for example because the router A is quicker than D to converge- D, for example because the router A is quicker than D to converge-
the mechanism may still avoid the forwarding loop that was occurring. the mechanism may still avoid the forwarding loop that would have
otherwise occurred.
6. Simulations 6. Simulations
Simulations have been run on multiple service provider topologies. Simulations have been run on multiple service provider topologies.
+----------+------+ +----------+------+
| Topology | Gain | | Topology | Gain |
+----------+------+ +----------+------+
| T1 | 71% | | T1 | 71% |
| T2 | 81% | | T2 | 81% |
skipping to change at page 11, line 29 skipping to change at page 11, line 29
We evaluated the efficiency of the mechanism on eight different We evaluated the efficiency of the mechanism on eight different
service provider topologies (different network size, design). The service provider topologies (different network size, design). The
benefit is displayed in the table above. The benefit is evaluated as benefit is displayed in the table above. The benefit is evaluated as
follows: follows:
o We consider a tuple (link A-B, destination D, PLR S, backup o We consider a tuple (link A-B, destination D, PLR S, backup
nexthop N) as a loop if upon link A-B failure, the flow from a nexthop N) as a loop if upon link A-B failure, the flow from a
router S upstream from A (A could be considered as PLR also) to D router S upstream from A (A could be considered as PLR also) to D
may loop due to convergence time difference between S and one of may loop due to convergence time difference between S and one of
his neighbor N. his neighbors N.
o We evaluate the number of potential loop tuples in normal o We evaluate the number of potential loop tuples in normal
conditions. conditions.
o We evaluate the number of potential loop tuples using the same o We evaluate the number of potential loop tuples using the same
topological input but taking into account that S converges after topological input but taking into account that S converges after
N. N.
o The gain is how much loops (remote and local) we succeed to o The gain is how many loops (both remote and local) we succeed to
suppress. suppress.
On topology 1, 71% of the transient forwarding loops created by the On topology 1, 71% of the transient forwarding loops created by the
failure of any link are prevented by implementing the local delay. failure of any link are prevented by implementing the local delay.
The analysis shows that all local loops are obviously solved and only The analysis shows that all local loops are prevented and only remote
remote loops are remaining. loops remain.
7. Deployment considerations 7. Deployment considerations
Transient forwarding loops have the following drawbacks: Transient forwarding loops have the following drawbacks:
o They limit FRR efficiency: even if FRR is activated in 50msec, as o They limit FRR efficiency: even if FRR is activated within 50msec,
soon as PLR has converged, the traffic may be affected by a as soon as PLR has converged, the traffic may be affected by a
transient loop. transient loop.
o They may impact traffic not directly concerned by the failure (due o They may impact traffic not directly affected by the failure (due
to link congestion). to link congestion).
This local delay proposal is a transient forwarding loop avoidance This local delay proposal is a transient forwarding loop avoidance
mechanism (like OFIB). Even if it only addresses local transient mechanism (like OFIB). Even if it only addresses local transient
loops, the efficiency versus complexity comparison of the mechanism loops, the efficiency versus complexity comparison of the mechanism
makes it a good solution. It is also incrementally deployable with makes it a good solution. It is also incrementally deployable with
incremental benefits, which makes it an attractive option for both incremental benefits, which makes it an attractive option both for
vendors to implement and Service Providers to deploy. Delaying the vendors to implement and service providers to deploy. Delaying the
convergence time is not an issue if we consider that the traffic is convergence time is not an issue if we consider that the traffic is
protected during the convergence. protected during the convergence.
8. Examples 8. Examples
We will consider the following figure for the associated examples : We will consider the following figure for the associated examples :
D D
1 | F----X 1 | F----X
| 1 | | 1 |
A ------ B A ------ B
| | ^ | | ^
10 | | 5 | T 10 | | 5 | T
| | | | | |
E--------C E--------C
| 1 | 1
1 | 1 |
S S
Figure 7
The network above is considered to have a convergence time about 1 The network above is considered to have a convergence time about 1
second, so ULOOP_DELAY_DOWN_TIMER will be adjusted to this value. We second, so ULOOP_DELAY_DOWN_TIMER will be adjusted to this value. We
also consider that FRR is running on each node. also consider that FRR is running on each node.
8.1. Local link down 8.1. Local link down
The table below describes the events and associating timing that The table below describes the events and associating timing that
happens on router C and E when link B-C goes down. As C detects a happens on router C and E when link B-C goes down. As C detects a
single local event corresponding to a link down (its LSP + LSP from B single local event corresponding to a link down (its LSP + LSP from B
received), it decides to apply the local delay down behavior and no received), it decides to apply the local delay down behavior and no
skipping to change at page 17, line 30 skipping to change at page 17, line 32
| | | ends | | | | | ends | |
| | | | | | | | | |
| | t0+470msec | | E convergence ends | | | t0+470msec | | E convergence ends |
| | | | | | | | | |
+-----------+------------+-----------------+------------------------+ +-----------+------------+-----------------+------------------------+
Route computation event time scale Route computation event time scale
8.3. Aborting local delay 8.3. Aborting local delay
The table below describes the events and associating timing that The table below describes the events and associated timing that
happens on router C and E when link B-C goes down, in addition F-X happens on router C and E when link B-C goes down. In addition, we
link will fail during local delay run. C will first apply local consider what happens when F-X link fails during local delay of the
delay, but when the new event happens, it will fall back to the FIB update. C will first apply the local delay, but when the new
standard convergence mechanism without delaying route insertion event happens, it will fall back to the standard convergence
anymore. In this example, we consider a ULOOP_DELAY_DOWN_TIMER mechanism without delaying route insertion anymore. In this example,
configured to 2 seconds. we consider a ULOOP_DELAY_DOWN_TIMER configured to 2 seconds.
+-----------+------------+-------------------+----------------------+ +-----------+------------+-------------------+----------------------+
| Network | Time | Router C events | Router E events | | Network | Time | Router C events | Router E events |
| condition | | | | | condition | | | |
+-----------+------------+-------------------+----------------------+ +-----------+------------+-------------------+----------------------+
| S->D | | | | | S->D | | | |
| Traffic | | | | | Traffic | | | |
| OK | | | | | OK | | | |
| | | | | | | | | |
| S->D | t0 | Link B-C fails | Link B-C fails | | S->D | t0 | Link B-C fails | Link B-C fails |
skipping to change at page 21, line 11 skipping to change at page 21, line 11
mechanism: CISCO IOS-XR, CISCO IOS-XE and Juniper JUNOS. The three mechanism: CISCO IOS-XR, CISCO IOS-XE and Juniper JUNOS. The three
implementations have been tested in labs and demonstrated a good implementations have been tested in labs and demonstrated a good
behavior in term of local micro-loop avoidance. The feature has also behavior in term of local micro-loop avoidance. The feature has also
been deployed in some live networks. No side effects have been been deployed in some live networks. No side effects have been
found. found.
11. Security Considerations 11. Security Considerations
This document does not introduce any change in term of IGP security. This document does not introduce any change in term of IGP security.
The operation is internal to the router. The local delay does not The operation is internal to the router. The local delay does not
increase the attack vector as an attacker could only trigger this increase the number of attack vectors as an attacker could only
mechanism if he already has be ability to disable or enable an IGP trigger this mechanism if he already has be ability to disable or
link. The local delay does not increase the negative consequences as enable an IGP link. The local delay does not increase the negative
if an attacker has the ability to disable or enable an IGP link, it consequences. If an attacker has the ability to disable or enable an
can already harm the network by creating instability and harm the IGP link, it can already harm the network by creating instability and
traffic by creating forwarding packet loss and forwarding loss for harm the traffic by creating forwarding packet loss and forwarding
the traffic crossing that link. loss for the traffic crossing that link.
12. Acknowledgements 12. Acknowledgements
We would like to thanks the authors of [RFC6976] for introducing the We would like to thanks the authors of [RFC6976] for introducing the
concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano
Previdi, and Olivier Bonaventure. Previdi, and Olivier Bonaventure.
13. IANA Considerations 13. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-rtgwg-backoff-algo] [I-D.ietf-rtgwg-backoff-algo]
Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
Francois, P., and C. Bowers, "SPF Back-off algorithm for Francois, P., and C. Bowers, "SPF Back-off algorithm for
link state IGPs", draft-ietf-rtgwg-backoff-algo-05 (work link state IGPs", draft-ietf-rtgwg-backoff-algo-05 (work
in progress), May 2017. in progress), May 2017.
[I-D.ietf-rtgwg-microloop-analysis] [I-D.ietf-rtgwg-microloop-analysis]
Zinin, A., "Analysis and Minimization of Microloops in Zinin, A., "Analysis and Minimization of Microloops in
Link-state Routing Protocols", draft-ietf-rtgwg-microloop- Link-state Routing Protocols", draft-ietf-rtgwg-microloop-
analysis-01 (work in progress), October 2005. analysis-01 (work in progress), October 2005.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
(TE) Extensions to OSPF Version 2", RFC 3630, Convergence", RFC 5715, DOI 10.17487/RFC5715, January
DOI 10.17487/RFC3630, September 2003, 2010, <http://www.rfc-editor.org/info/rfc5715>.
<http://www.rfc-editor.org/info/rfc3630>.
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012,
<http://www.rfc-editor.org/info/rfc6571>.
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
Francois, P., and O. Bonaventure, "Framework for Loop-Free Francois, P., and O. Bonaventure, "Framework for Loop-Free
Convergence Using the Ordered Forwarding Information Base Convergence Using the Ordered Forwarding Information Base
(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
2013, <http://www.rfc-editor.org/info/rfc6976>. 2013, <http://www.rfc-editor.org/info/rfc6976>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <http://www.rfc-editor.org/info/rfc7916>. July 2016, <http://www.rfc-editor.org/info/rfc7916>.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Orange
 End of changes. 40 change blocks. 
118 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/