draft-ietf-rtgwg-uloop-delay-02.txt   draft-ietf-rtgwg-uloop-delay-03.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 5, 2016 C. Filsfils Expires: June 2, 2017 C. Filsfils
P. Francois P. Francois
Cisco Systems Cisco Systems
June 3, 2016 November 29, 2016
Microloop prevention by introducing a local convergence delay Micro-loop prevention by introducing a local convergence delay
draft-ietf-rtgwg-uloop-delay-02 draft-ietf-rtgwg-uloop-delay-03
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-steps convergence by introducing a
delay between the convergence of the node adjacent to the topology delay between the convergence of the node adjacent to the topology
change and the network wide convergence. change 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 and the IGP convergence. the link failure time and the IGP convergence.
The proposed mechanism will be limited to link down event in order to The proposed mechanism will be limited to the link down event in
keep simplicity. order to keep simplicity.
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 5, 2016. This Internet-Draft will expire on June 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transient forwarding loops side effects . . . . . . . . . . . 3 2. Transient forwarding loops side effects . . . . . . . . . . . 3
2.1. Fast reroute unefficiency . . . . . . . . . . . . . . . . 4 2.1. Fast reroute inefficiency . . . . . . . . . . . . . . . . 4
2.2. Network congestion . . . . . . . . . . . . . . . . . . . 6 2.2. Network congestion . . . . . . . . . . . . . . . . . . . 6
3. Overview of the solution . . . . . . . . . . . . . . . . . . 7 3. Overview of the solution . . . . . . . . . . . . . . . . . . 7
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 7 4.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 7
4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Local delay for link down . . . . . . . . . . . . . . . . 8 4.4. Local delay for link down . . . . . . . . . . . . . . . . 9
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Applicable case : local loops . . . . . . . . . . . . . . 9 5.1. Applicable case: local loops . . . . . . . . . . . . . . 9
5.2. Non applicable case : remote loops . . . . . . . . . . . 9 5.2. Non applicable case: remote loops . . . . . . . . . . . . 10
6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Deployment considerations . . . . . . . . . . . . . . . . . . 11 7. Deployment considerations . . . . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Local link down . . . . . . . . . . . . . . . . . . . . . 12 8.1. Local link down . . . . . . . . . . . . . . . . . . . . . 12
8.2. Local and remote event . . . . . . . . . . . . . . . . . 15 8.2. Local and remote event . . . . . . . . . . . . . . . . . 15
8.3. Aborting local delay . . . . . . . . . . . . . . . . . . 17 8.3. Aborting local delay . . . . . . . . . . . . . . . . . . 17
9. Comparison with other solutions . . . . . . . . . . . . . . . 19 9. Comparison with other solutions . . . . . . . . . . . . . . . 19
9.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. OFIB . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. OFIB . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Existing implementations . . . . . . . . . . . . . . . . . . 20 10. Existing implementations . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
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 local to the failure; based on mechanism that solves micro-loops that are local to the failure;
network analysis, these are a significant portion of the micro- based on network analysis, these are a significant portion of the
forwarding loops. A simple and easily deployable solution to these micro-forwarding loops. A simple and easily deployable solution for
local micro-loops is critical because these local loops cause traffic these local micro-loops is critical because these local loops cause
loss after an advanced fast-reroute alternate has been used (see some traffic loss after a fast-reroute alternate has been used (see
Section 2.1). 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 technique used, when S converges to the new advanced fast-reroute (FRR) technique used, when S converges to the
topology, it will send its traffic to a neighbor that was not loop- new topology, it will send its traffic to a neighbor that was not
free and thus cause a local micro-loop. The deployment of advanced loop-free and thus cause a local micro-loop. The deployment of
fast-reroute techniques motivates this simple router-local mechanism advanced fast-reroute techniques motivates this simple router-local
to solve this targeted problem. This solution can be work with the mechanism to solve this targeted problem. This solution can be work
various techniques described in [RFC5715]. with the various techniques described in [RFC5715].
1 1
D ------ C D ------ C
| | | |
1 | | 5 1 | | 5
| | | |
S ------ B S ------ B
1 1
Figure 1 Figure 1
When S-D fails, a transient forwarding loop may appear between S and When S-D fails, a transient forwarding loop may appear between S and
B if S updates its forwarding entry to D before B. B if S updates its forwarding entry to D before B.
2. Transient forwarding loops side effects 2. Transient forwarding loops side effects
Even if they are very limited in duration, transient forwarding loops Even if they are very limited in duration, transient forwarding loops
may cause high damage for the network. may cause high damage for the network.
2.1. Fast reroute unefficiency 2.1. Fast reroute inefficiency
D D
1 | 1 |
| 1 | 1
A ------ B A ------ B
| | ^ | | ^
10 | | 5 | T 10 | | 5 | T
| | | | | |
E--------C E--------C
| 1 | 1
1 | 1 |
S S
Figure 2 - RSVPTE FRR case Figure 2 - RSVP-TE FRR case
In figure 2, a RSVP-TE tunnel T, provisionned on C and terminating on In figure 2, an RSVP-TE tunnel T, provisioned on C and terminating on
B, is used to protect against C-B link failure (IGP shortcut B, is used to protect against C-B link failure (IGP shortcut
activated on C). Primary path of T is C->B and FRR is activated on T activated on C). The primary path of T is C->B and FRR is activated
providing a FRR bypass or detour using path C->E->A->B. On C, on T providing an FRR bypass or detour using path C->E->A->B. On the
nexthop to D is tunnel T thanks to IGP shortcut. When C-B link fails router C, the nexthop to D is tunnel T thanks to 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, traffic path from S to D is : 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 IGP convergence and TE tunnel 2. In parallel, on router C, both IGP convergence and TE tunnel
convergence (tunnel path recomputation) are occuring : convergence (tunnel path recomputation) are occurring:
* T path is recomputed : C->E->A->B * T path is recomputed and now uses C->E->A->B.
* IGP path to D is recomputed : C->E->A->D * IGP path to D is recomputed and now uses C->E->A->D.
3. On C, tail-end of the TE tunnel (router B) is no more on SPT to 3. On C, the tail-end of the TE tunnel (router B) is no more on the
D, so C does not encapsulate anymore the traffic to D using the shortest-path tree (SPT) to D, so C does not encapsulate anymore
tunnel T and update forwarding entry to D using nexthop E. the traffic to D using the tunnel T and updates its forwarding
entry to D using nexthop E.
If C updates its forwarding entry to D before router E, there would If C updates its forwarding entry to D before router E, there would
be a transient forwarding loop between C and E until E has converged. be a transient forwarding loop between C and E until E has converged.
+-----------+------------+------------------+-----------------------+ +-----------+------------+------------------+-----------------------+
| Network | Time | Router C events | Router E events | | Network | Time | Router C events | Router E events |
| condition | | | | | condition | | | |
+-----------+------------+------------------+-----------------------+ +-----------+------------+------------------+-----------------------+
| S->D | | | | | S->D | | | |
| Traffic | | | | | Traffic | | | |
skipping to change at page 6, line 13 skipping to change at page 6, line 14
| 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 ...). Fast-reroute reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). The
is working perfectly but ensures protection, by definition, only protection enabled by fast-reroute is working perfectly, but ensures
until the PLR has converged. When implementing FRR, a service protection, by definition, only until the PLR has converged. When
provider wants to guarantee a very limited loss of connectivity time. implementing FRR, a service provider wants to guarantee a very
The previous example shows that the benefit of FRR may be completely limited loss of connectivity time. The previous example shows that
lost due to a transient forwarding loop appearing when PLR has the benefit of FRR may be completely lost due to a transient
converged. Delaying FIB updates after IGP convergence may permit to forwarding loop appearing when PLR has converged. Delaying FIB
keep fast-reroute path until neighbor has converged and preserve updates after IGP convergence may allow to keep fast-reroute path
customer traffic. until the 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
In the figure above, as presented in Section 1, when link S-D fails, In the figure above, as presented in Section 1, when the link S-D
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 S-B link will constantly increase due destination D. The traffic on the S-B link will constantly increase
to the looping traffic to D. Depending on TTL of packets, traffic due to the looping traffic to D. Depending on the TTL of the
rate destinated to D and bandwidth of link, the S-B link may be packets, the traffic rate destinated to D and the bandwidth of the
congestioned in few hundreds of milliseconds and will stay overloaded link, the S-B link may be congested in few hundreds of milliseconds
until the loop is solved. and will stay overloaded until the loop is solved.
Congestion introduced by transient forwarding loops are problematic The congestion introduced by transient forwarding loops is
as they are impacting traffic that is not directly concerned by the problematic as it is impacting traffic that is not directly concerned
failing network component. In our example, the congestion of S-B by the failing network component. In our example, the congestion of
link will impact customer traffic that is not directly concerned by the S-B link will impact some customer traffic that is not directly
the failure : e.g. A to B, F to B, E to B. Class of services may be concerned by the failure: e.g. A to B, F to B, E to B. Some class
implemented to mitigate the congestion but some traffic not directly of services may be implemented to mitigate the congestion, but some
concerned by the failure would still be dropped as a router is not traffic not directly concerned by the failure would still be dropped
able to identify looped traffic from normal traffic. as a router is not able to identify the looping traffic from the
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 the 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. The proposed solution is kept limited to local link down events for
simplicity reason.
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 one hop distance. As a defined in [RFC6976], but limited to only a "one hop" distance. As a
consequence, it is simpler and becomes a local only feature not consequence, it is simpler and becomes a local only feature not
requiring interoperability; at the cost of only covering the requiring interoperability; at the cost of only covering the
transient forwarding loops involving this local router. The proposed transient forwarding loops involving this local router. The proposed
mechanism also reuses some concept described in mechanism also reuses some concept described in
[I-D.ietf-rtgwg-microloop-analysis] with some limitation. [I-D.ietf-rtgwg-microloop-analysis] with some limitations.
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: to batch multiple local events in one single local o LSP_GEN_TIMER: used to batch multiple local events in one single
LSP update. It is often associated with damping mechanism to local LSP update. It is often associated with a damping mechanism
slowdown reactions by incrementing the timer when multiple to slow down reactions by incrementing the timer when multiple
consecutive events are detected. consecutive events are detected.
o SPF_TIMER: to batch multiple events in one single computation. It o SPF_TIMER: used to batch multiple events in one single
is often associated with damping mechanism to slowdown reactions computation. It is often associated with a damping mechanism to
by incrementing the timer when the IGP is instable. slow down reactions by incrementing the timer when the IGP becomes
unstable.
This document introduces the following a new timer : This document introduces the following new timer:
o ULOOP_DELAY_DOWN_TIMER: slowdown the local node convergence in o ULOOP_DELAY_DOWN_TIMER: used to slow down the local node
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 status on an adjacency/link, the existing behavior Upon a change of the status of an adjacency/link, the existing
of the router advertising the event is the following: behavior of the router advertising the event is the following:
1. UP/Down event is notified to IGP. 1. The Up/Down event is notified to the IGP.
2. IGP processes the notification and postpones the reaction in 2. The IGP processes the notification and postpones the reaction in
LSP_GEN_TIMER msec. LSP_GEN_TIMER msec.
3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods 3. Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and
it. floods it.
4. SPF is scheduled in SPF_TIMER msec. 4. The SPF computation is scheduled in SPF_TIMER msec.
5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are 5. Upon SPF_TIMER expiration, the SPF is computed, then the RIB and
updated. FIB are updated.
4.3. Local events 4.3. Local events
The mechanisms described in this document assume 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). There are three types of single failures: local link, Section 4.2).
local node, and remote failure.
Example : To determine if the mechanism can be applicable or not, an
implementation SHOULD implement a logic to correlate the protocol
messages (LSP/LSA) received during the SPF scheduling period in order
to determine the topology changes that occured. This is necessary as
multiple protocol messages may describe the same topology change and
a single protocol message may describe multiple topology changes. As
a consequence, determining a particular topology change MUST be
independent of the order of reception of those protocol messages.
How the logic works is let to implementation details.
Using this logic, if an implementation determines that the associated
topology change is a single local link failure, then the router MAY
use the mechanism described in this document, otherwise the standard
IP convergence MUST be used.
Example:
+--- E ----+--------+ +--- E ----+--------+
| | | | | |
A ---- B -------- C ------ D A ---- B -------- C ------ D
Let B be the computing router when the link B-C fails. B updates its Let router B be the computing router when the link B-C fails. B
local LSP/LSA describing the link B->C as down, C does the same, and updates its local LSP/LSA describing the link B->C as down, C does
both start flooding their updated LSP/LSAs. During the SPF_TIMER the same, and both start flooding their updated LSP/LSAs. During the
period, B and C learn all the LSPs/LSAs to consider. B sees that C SPF_TIMER period, B and C learn all the LSPs/LSAs to consider. B
is flooding as down a link where B is the other end and that B and C sees that C is flooding as down a link where B is the other end and
are describing the same single event. Since B receives no other that B and C are describing the same single event. Since B receives
changes, B can determine that this is a local link failure. no other changes, B can determine that this is a local link failure
and may decide to activate the mechanism described in this document.
An implementation SHOULD implement a logic to correlate protocol
messages (LSP/LSA) received during SPF scheduling and topology
changes as multiple protocol messages may describe the same topology
change. As a consequence, determining a particular topology change
MUST be independent of the order of reception of those protocol
messages. How the logic works is let to implementation details.
Using this logic, if an implementation determines that the associated
event is a single local link failure, then the router MAY use the
mechanism described in this document, otherwise standard IP
convergence MUST be used.
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 in order to delay the local convergence compared to the in step 5 (Section 4.2) in order to delay the local convergence
network wide convergence: the node SHOULD delay the forwarding entry compared to the network wide convergence: the node SHOULD delay the
updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be forwarding entry updates by ULOOP_DELAY_DOWN_TIMER. Such delay
introduced if all the LSDB modifications processed are only reporting SHOULD only be introduced if all the LSDB modifications processed are
down local events . Note that determining that all topological only reporting a single local link down event (Section 4.3). If a
change are only local down events requires analyzing all modified subsequent LSP/LSA is received/updated and a new SPF computation is
LSP/LSA as a local link or node failure will typically be notified by triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the
multiple nodes. If a subsequent LSP/LSA is received/updated and a same evaluation SHOULD be performed.
new SPF computation is triggered before the expiration of
ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed.
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 non urgent convergence, such as for administrative de-activation for a non-urgent convergence, such as for administrative de-
(maintenance) or when the traffic is Fast ReRouted. activation (maintenance) or when the traffic is protected by fast-
reroute.
5. Applicability 5. Applicability
As previously stated, the mechanism only avoids the forwarding loops As previously stated, the 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 neighbor.
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 2
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 CE fails, if C updates its forwarding entry G->D->C->E->F. When link C-E fails, if C updates its forwarding
for F before D, a transient loop occurs. This is sub-optimal as C entry for F before D, a transient loop occurs. This is sub-optimal
has FRR enabled and it breaks the FRR forwarding while all upstream as C has FRR enabled and it breaks the FRR forwarding while all
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
CE link fails, C delays the update of his 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 let some time for D to converge. FRR keeps protecting the
traffic during this period. When the timer expires on C, forwarding traffic during this period. When the timer expires on C, its
entry to F is updated. There is no transient forwarding loop on the forwarding entry to F is updated. There is no transient forwarding
link CD. 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 3
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 CF 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 CF fails, C delays the update of his 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, letting 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 occuring. the mechanism may still avoid the forwarding loop that was occurring.
6. Simulations 6. Simulations
Simulations have been run on multiple service provider topologies. Simulations have been run on multiple service provider topologies.
So far, only link down event have been tested.
+----------+------+ +----------+------+
| Topology | Gain | | Topology | Gain |
+----------+------+ +----------+------+
| T1 | 71% | | T1 | 71% |
| T2 | 81% | | T2 | 81% |
| T3 | 62% | | T3 | 62% |
| T4 | 50% | | T4 | 50% |
| T5 | 70% | | T5 | 70% |
| T6 | 70% | | T6 | 70% |
skipping to change at page 11, line 20 skipping to change at page 11, line 23
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 neighbor 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 Gain is how much loops (remote and local) we succeed to suppress. o The gain is how much loops (remote and local) we succeed to
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 obviously solved and only
remote loops are remaining. remote loops are remaining.
7. Deployment considerations 7. Deployment considerations
Transient forwarding loops have the following drawbacks : Transient forwarding loops have the following drawbacks:
o Limit FRR efficiency : even if FRR is activated in 50msec, as soon o They limit FRR efficiency: even if FRR is activated in 50msec, as
as PLR has converged, traffic may be affected by a transient loop. soon as PLR has converged, the traffic may be affected by a
transient loop.
o It may impact traffic not directly concerned by the failure (due o They may impact traffic not directly concerned 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 address 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 for both
vendors to implement and Service Providers to deploy. Delaying 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 |
skipping to change at page 12, line 19 skipping to change at page 12, line 23
| | ^ | | ^
10 | | 5 | T 10 | | 5 | T
| | | | | |
E--------C E--------C
| 1 | 1
1 | 1 |
S S
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 FRR 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 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
microloop is formed. microloop is formed.
+-----------+-------------+------------------+----------------------+ +-----------+-------------+------------------+----------------------+
| Network | Time | Router C events | Router E events | | Network | Time | Router C events | Router E events |
| condition | | | | | condition | | | |
+-----------+-------------+------------------+----------------------+ +-----------+-------------+------------------+----------------------+
| S->D | | | | | S->D | | | |
| Traffic | | | | | Traffic | | | |
skipping to change at page 17, line 17 skipping to change at page 17, line 21
| | | | | | | | | |
+-----------+------------+-----------------+------------------------+ +-----------+------------+-----------------+------------------------+
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 associating 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 F-X
link will fail during local delay run. C will first apply local link will fail during local delay run. C will first apply local
delay, but when the new event happens, it will fallback to the delay, but when the new event happens, it will fall back to the
standard convergence mechanism without delaying route insertion standard convergence mechanism without delaying route insertion
anymore. In this example, we consider a ULOOP_DELAY_DOWN_TIMER anymore. In this example, we consider a ULOOP_DELAY_DOWN_TIMER
configured to 2 seconds. 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 | | | |
skipping to change at page 19, line 29 skipping to change at page 19, line 33
9. Comparison with other solutions 9. Comparison with other solutions
As stated in Section 3, our solution reuses some concepts already As stated in Section 3, our solution reuses some concepts already
introduced by other IETF proposals but tries to find a tradeoff introduced by other IETF proposals but tries to find a tradeoff
between efficiency and simplicity. This section tries to compare between efficiency and simplicity. This section tries to compare
behaviors of the solutions. behaviors of the solutions.
9.1. PLSN 9.1. PLSN
PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism
where each node in the network tries a avoid transient forwarding where each node in the network tries to avoid transient forwarding
loops upon a topology change by always keeping traffic on a loop-free loops upon a topology change by always keeping traffic on a loop-free
path for a defined duration (locked path to a safe neighbor). The path for a defined duration (locked path to a safe neighbor). The
locked path may be the new primary nexthop, another neighbor, or the locked path may be the new primary nexthop, another neighbor, or the
old primary nexthop depending how the safety condition is satisified. old primary nexthop depending how the safety condition is satisfied.
PLSN does not solve all transient forwarding loops (see PLSN does not solve all transient forwarding loops (see
[I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details). [I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details).
Our solution reuse some concept of PLSN but in a more simple fashion Our solution reuses some concept of PLSN but in a more simple
: fashion:
o PLSN has 3 different behavior : keep using old nexthop, use new o PLSN has three different behaviors: keep using old nexthop, use
primary nexthop if safe, or use another safe nexthop, while our new primary nexthop if it is safe, or use another safe nexthop,
solution only have one : keep using the current nexthop (old while our solution only have one: keep using the current nexthop
primary, or already activated FRR path). (old primary, or already activated FRR path).
o PLSN may cause some damage while using a safe nexthop which is not o PLSN may cause some damage while using a safe nexthop which is not
the new primary nexthop in case the new safe nexthop does not the new primary nexthop in case the new safe nexthop does not
enough provide enough bandwidth (see enough provide enough bandwidth (see [RFC7916]). Our solution may
[I-D.ietf-rtgwg-lfa-manageability]). Our solution may not not experience this issue as the service provider may have control
experience this issue as the service provider may have control on on the FRR path being used preventing network congestion.
the FRR path being used preventing network congestion.
o PLSN applies to all nodes in a network (remote or local changes), o PLSN applies to all nodes in a network (remote or local changes),
while our mechanism applies only on the nodes connected to the while our mechanism applies only on the nodes connected to the
topology change. topology change.
9.2. OFIB 9.2. OFIB
OFIB ([RFC6976]) describes a mechanism where convergence of the OFIB ([RFC6976]) describes a mechanism where the convergence of the
network upon a topology change is made ordered to prevent transient network upon a topology change is made ordered to prevent transient
forwarding loops. Each router in the network must deduce the failure forwarding loops. Each router in the network must deduce the failure
type from the LSA/LSP received and compute/apply a specific FIB type from the LSA/LSP received and computes/applies a specific FIB
update timer based on the failure type and its rank in the network update timer based on the failure type and its rank in the network
considering the failure point as root. considering the failure point as root.
This mechanism permit to solve all the transient forwarding loop in a This mechanism allows to solve all the transient forwarding loop in a
network at the price of introducing complexity in the convergence network at the price of introducing complexity in the convergence
process that may require strong monitoring by the service provider. process that may require a strong monitoring by the service provider.
Our solution reuses the OFIB concept but limits it to the first hop Our solution reuses the OFIB concept but limits it to the first hop
that experience the topology change. As demonstrated, our proposal that experiences the topology change. As demonstrated, our proposal
permits to solve all the local transient forwarding loops that allows to solve all the local transient forwarding loops that
represents a high percentage of all the loops. Moreover limiting the represents an high percentage of all the loops. Moreover limiting
mechanism to one hop permit to keep the network-wide convergence the mechanism to one hop allows to keep the network-wide convergence
behavior. behavior.
10. Existing implementations 10. Existing implementations
At this time, there is three different implementations of this At this time, there are three different implementations of this
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. No side effects have behavior in term of local micro-loop avoidance. The feature has also
been found. been deployed in some live networks. No side effects have been
found.
11. Security Considerations 11. Security Considerations
This document does not introduce change in term of IGP security. The This document does not introduce any change in term of IGP security.
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 attack vector as an attacker could only trigger this
mechanism if he already has be ability to disable or enable an IGP mechanism if he already has be ability to disable or enable an IGP
link. The local delay does not increase the negative consequences as link. The local delay does not increase the negative consequences as
if an attacker has the ability to disable or enable an IGP link, it if an attacker has the ability to disable or enable an IGP link, it
can already harm the network by creating instability and harm the can already harm the network by creating instability and harm the
traffic by creating forwarding packet loss and forwarding loss for traffic by creating forwarding packet loss and forwarding loss for
the traffic crossing that link. the traffic crossing that link.
12. Acknowledgements 12. Acknowledgements
We wish 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
skipping to change at page 21, line 30 skipping to change at page 21, line 30
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 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>. 2010, <http://www.rfc-editor.org/info/rfc5715>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and
M. Horneffer, "Operational management of Loop Free
Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work
in progress), June 2015.
[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 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>. <http://www.rfc-editor.org/info/rfc3630>.
skipping to change at page 22, line 16 skipping to change at page 22, line 10
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. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>. <http://www.rfc-editor.org/info/rfc7490>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <http://www.rfc-editor.org/info/rfc7916>.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Bruno Decraene Bruno Decraene
Orange Orange
 End of changes. 78 change blocks. 
179 lines changed or deleted 187 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/