draft-ietf-rtgwg-uloop-delay-03.txt   draft-ietf-rtgwg-uloop-delay-04.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: June 2, 2017 C. Filsfils Expires: October 8, 2017 C. Filsfils
P. Francois P. Francois
Cisco Systems Cisco Systems
November 29, 2016 April 6, 2017
Micro-loop prevention by introducing a local convergence delay Micro-loop prevention by introducing a local convergence delay
draft-ietf-rtgwg-uloop-delay-03 draft-ietf-rtgwg-uloop-delay-04
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
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 June 2, 2017. This Internet-Draft will expire on October 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 inefficiency . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 8
4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Local events . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Local delay for link down . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . 10 5.2. Non applicable case: remote loops . . . . . . . . . . . . 10
6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Deployment considerations . . . . . . . . . . . . . . . . . . 11 7. Deployment considerations . . . . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 21
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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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 damages for a network.
2.1. Fast reroute inefficiency 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 - RSVP-TE FRR case Figure 2 - RSVP-TE FRR case
In figure 2, an RSVP-TE tunnel T, provisioned on C and terminating on In the Figure 2, an RSVP-TE tunnel T, provisioned on C and
B, is used to protect against C-B link failure (IGP shortcut terminating on B, is used to protect against C-B link failure (IGP
activated on C). The primary path of T is C->B and FRR is activated shortcut is activated on C). The primary path of T is C->B and FRR
on T providing an FRR bypass or detour using path C->E->A->B. On the is activated on T providing an FRR bypass or detour using path
router C, the nexthop to D is tunnel T thanks to IGP shortcut. When C->E->A->B. On the router C, the nexthop to D is the tunnel T thanks
C-B link fails: 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 IGP convergence and TE tunnel 2. In parallel, on router C, both the IGP convergence and the TE
convergence (tunnel path recomputation) are occurring: tunnel convergence (tunnel path recomputation) are occurring:
* T path is recomputed and now uses C->E->A->B. * The Tunnel T path is recomputed and now uses C->E->A->B.
* IGP path to D is recomputed and now uses C->E->A->D. * The IGP path to D is recomputed and now uses C->E->A->D.
3. On C, the tail-end of the TE tunnel (router B) is no more on the 3. On C, the tail-end of the TE tunnel (router B) is no more on the
shortest-path tree (SPT) to D, so C does not encapsulate anymore shortest-path tree (SPT) to D, so C does not encapsulate anymore
the traffic to D using the tunnel T and updates its forwarding the traffic to D using the tunnel T and updates its forwarding
entry to D using nexthop E. entry to D using the 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 16 skipping to change at page 6, line 16
| 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 ...). The
protection enabled by fast-reroute is working perfectly, but ensures protection enabled by fast-reroute is working perfectly, but ensures
protection, by definition, only until the PLR has converged. When a protection, by definition, only until the PLR has converged. When
implementing FRR, a service provider wants to guarantee a very implementing FRR, a service provider wants to guarantee a very
limited loss of connectivity time. The previous example shows that limited loss of connectivity time. The previous example shows that
the benefit of FRR may be completely lost due to a transient the benefit of FRR may be completely lost due to a transient
forwarding loop appearing when PLR has converged. Delaying FIB forwarding loop appearing when PLR has converged. Delaying FIB
updates after IGP convergence may allow to keep fast-reroute path updates after the IGP convergence may allow to keep the fast-reroute
until the neighbors have converged and preserves the customer path until the neighbors have converged and preserves the customer
traffic. 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
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 limitations. [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: used to batch multiple local events in one single o LSP_GEN_TIMER: The delay used to batch multiple local events in
local LSP update. It is often associated with a damping mechanism one single local LSP/LSA update. It is often associated with a
to slow down reactions by incrementing the timer when multiple damping mechanism to slow down reactions by incrementing the timer
consecutive events are detected. when multiple consecutive events are detected.
o SPF_TIMER: used to batch multiple events in one single o SPF_DELAY: The delay between the first IGP event triggering a new
routing table computation and the start of that routing table
computation. It is often associated with a damping mechanism to computation. It is often associated with a damping mechanism to
slow down reactions by incrementing the timer when the IGP becomes slow down reactions by incrementing the timer when the IGP becomes
unstable. unstable. As an example, [I-D.ietf-rtgwg-backoff-algo] defines a
standard SPF delay algorithm.
This document introduces the following new timer: This document introduces the following new timer:
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 in
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_TIMER msec. 4. The SPF computation is scheduled in SPF_DELAY msec.
5. Upon SPF_TIMER expiration, the SPF is computed, then the RIB and 5. Upon SPF_DELAY expiration, the SPF is computed, then the RIB and
FIB are updated. 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).
skipping to change at page 8, line 44 skipping to change at page 9, line 4
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
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_TIMER 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 as down a link where B is the other end and
that B and C are describing the same single event. Since B receives that B and C are describing the same single event. Since B receives
no other 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. 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 node SHOULD delay the
skipping to change at page 21, line 30 skipping to change at page 21, line 44
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-backoff-algo]
Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
Francois, P., and C. Bowers, "SPF Back-off algorithm for
link state IGPs", draft-ietf-rtgwg-backoff-algo-04 (work
in progress), January 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 [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>.
 End of changes. 23 change blocks. 
32 lines changed or deleted 39 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/