Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene
Intended status: Standards Track Orange
Expires: October 7, 2016 C. Filsfils
P. Francois
Cisco Systems
April 5, 2016

Microloop prevention by introducing a local convergence delay
draft-ietf-rtgwg-uloop-delay-01

Abstract

This document describes a mechanism for link-state routing protocols to prevent local transient forwarding loops in case of link failure. This mechanism Proposes a two-steps convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network wide convergence.

As this mechanism delays the IGP convergence it may only be used for planned maintenance or when fast reroute protects the traffic between the link failure and the IGP convergence.

The proposed mechanism will be limited to link down event in order to keep simplicity.

Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 7, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Micro-forwarding loops and some potential solutions are well described in [RFC5715]. This document describes a simple targeted mechanism that solves micro-loops local to the failure; based on network analysis, these are a significant portion of the micro-forwarding loops. A simple and easily deployable solution to these local micro-loops is critical because these local loops cause traffic loss after an advanced fast-reroute alternate has been used (see Section 2.1).

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 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 advanced fast-reroute technique used, when S converges to the 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 advanced fast-reroute techniques motivates this simple router-local mechanism to solve this targeted problem. This solution can be work with the various techniques described in [RFC5715].

          1
     D ------ C
     |        |
   1 |        | 5
     |        |
     S ------ B        
          1
     Figure 1	 
		

When S-D fails, a transient forwarding loop may appear between S and B if S updates its forwarding entry to D before B.

2. Transient forwarding loops side effects

Even if they are very limited in duration, transient forwarding loops may cause high damage for the network.

2.1. Fast reroute unefficiency

        D
      1 |    
        |    1
        A ------ B
        |        |    ^
     10 |        | 5  | T
        |        |    |
        E--------C        
        |    1   
      1 |        
        S 
         
     Figure 2 - RSVPTE FRR case	
		

  1. C detects the failure, and updates the tunnel path using preprogrammed FRR path, traffic path from S to D is : S->E->C->E->A->B->A->D .
  2. In parallel, on router C, both IGP convergence and TE tunnel convergence (tunnel path recomputation) are occuring :

  3. On C, tail-end of the TE tunnel (router B) is no more on SPT to D, so C does not encapsulate anymore the traffic to D using the tunnel T and update forwarding entry to D using nexthop E.

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.

Route computation event time scale
Network condition Time Router C events Router E events
S->D Traffic OK
S->D Traffic lost t0 Link B-C fails Link B-C fails
t0+20msec C detects the failure
S->D Traffic OK t0+40msec C activates FRR
t0+50msec C updates its local LSP/LSA
t0+60msec C schedules SPF (100ms)
t0+70msec C floods its local updated LSP/LSA
t0+87msec E receives LSP/LSA from C and schedules SPF (100ms)
t0+117msec E floods LSP/LSA from C
t0+160msec C computes SPF
t0+165msec C starts updating its RIB/FIB
t0+193msec E computes SPF
t0+199msec E starts updating its RIB/FIB
S->D Traffic lost t0+255msec C updates its RIB/FIB for D
t0+340msec C convergence ends
S->D Traffic OK t0+443msec E updates its RIB/FIB for D
t0+470msec E convergence ends

The issue described here is completely independent of the fast-reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). Fast-reroute is working perfectly but ensures protection, by definition, only until the PLR has converged. When implementing FRR, a service provider wants to guarantee a very limited loss of connectivity time. The previous example shows that the benefit of FRR may be completely lost due to a transient forwarding loop appearing when PLR has converged. Delaying FIB updates after IGP convergence may permit to keep fast-reroute path until neighbor has converged and preserve customer traffic.

2.2. Network congestion

          1
     D ------ C
     |        |
   1 |        | 5
     |        |
A -- S ------ B        
   / |    1
  F  E	 
		

Section 1, when link S-D fails, a transient forwarding loop may appear between S and B for destination D. The traffic on S-B link will constantly increase due to the looping traffic to D. Depending on TTL of packets, traffic rate destinated to D and bandwidth of link, the S-B link may be congestioned in few hundreds of milliseconds and will stay overloaded until the loop is solved.

Congestion introduced by transient forwarding loops are problematic as they are impacting traffic that is not directly concerned by the failing network component. In our example, the congestion of S-B link will impact customer traffic that is not directly concerned by the failure : e.g. A to B, F to B, E to B. Class of services may be implemented to mitigate the congestion but some traffic not directly concerned by the failure would still be dropped as a router is not able to identify looped traffic from normal traffic.

3. Overview of the solution

This document defines a two-step convergence initiated by the router detecting the failure and advertising the topological changes in the IGP. This introduces a delay between the convergence of the local router and the network wide convergence.

The proposed solution is kept limited to local link down events.

This ordered convergence, is similar to the ordered FIB proposed defined in [RFC6976], but limited to only one hop distance. As a consequence, it is simpler and becomes a local only feature not requiring interoperability; at the cost of only covering the transient forwarding loops involving this local router. The proposed mechanism also reuses some concept described in [I-D.ietf-rtgwg-microloop-analysis] with some limitation.

4. Specification

4.1. Definitions

This document will refer to the following existing IGP timers:

This document introduces the following a new timer :

4.2. Current IGP reactions

Upon a change of status on an adjacency/link, the existing behavior of the router advertising the event is the following:

  1. UP/Down event is notified to IGP.
  2. IGP processes the notification and postpones the reaction in LSP_GEN_TIMER msec.
  3. Upon LSP_GEN_TIMER expiration, IGP updates its LSP/LSA and floods it.
  4. SPF is scheduled in SPF_TIMER msec.
  5. Upon SPF_TIMER expiration, SPF is computed and RIB/FIB are updated.

4.3. Local events

The mechanisms described in this document assume that there has been a single link failure as seen by the IGP area/level. If this assumption is violated (e.g. multiple links or nodes failed), then standard IP convergence MUST be applied (as described in Section 4.2). There are three types of single failures: local link, local node, and remote failure.

       +--- E ----+--------+
       |          |        |
A ---- B -------- C ------ D
		

Example :

Let 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 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 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 no other changes, B can determine that this is a local link failure.

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

Upon an adjacency/link down event, this document introduces a change in step 5 in order to delay the local convergence compared to the network wide convergence: the node SHOULD delay the forwarding entry updates by ULOOP_DELAY_DOWN_TIMER. Such delay SHOULD only be introduced if all the LSDB modifications processed are only reporting down local events . Note that determining that all topological change are only local down events requires analyzing all modified LSP/LSA as a local link or node failure will typically be notified by multiple nodes. If a subsequent LSP/LSA is received/updated and a 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 converge slower than remote routers. Hence it SHOULD only be done for non urgent convergence, such as for administrative de-activation (maintenance) or when the traffic is Fast ReRouted.

5. Applicability

As previously stated, the mechanism only avoids the forwarding loops on the links between the node local to the failure and its neighbor. Forwarding loops may still occur on other links.

5.1. Applicable case : local loops

     A ------ B ----- E
     |              / |
     |             /  |
 G---D------------C   F        All the links have a metric of 1 

     Figure 2	 
		

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 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 upstream routers are still forwarding the traffic to itself.

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 order to let some time for D to converge. FRR keeps protecting the traffic during this period. When the timer expires on C, forwarding entry to F is updated. There is no transient forwarding loop on the link CD.

5.2. Non applicable case : remote loops

     A ------ B ----- E --- H
     |                      |
     |                      |
 G---D--------C ------F --- J ---- K    
 
 All the links have a metric of 1 except BE=15    

     Figure 3	 
		

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 forwarding entry to K before D, a transient loop occurs between C and D.

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, letting time for D to converge. When the timer expires on C, forwarding entry to F is updated. There is no transient forwarding loop between C and D. However, a transient forwarding loop may still occur between D and A. In this scenario, this mechanism is not enough to address all the possible forwarding loops. However, it does not create additional traffic loss. Besides, in some cases -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- the mechanism may still avoid the forwarding loop that was occuring.

6. Simulations

Simulations have been run on multiple service provider topologies. So far, only link down event have been tested.

Number of Repair/Dst that may loop
Topology Gain
T1 71%
T2 81%
T3 62%
T4 50%
T5 70%
T6 70%
T7 59%
T8 77%

We evaluated the efficiency of the mechanism on eight different service provider topologies (different network size, design). The benefit is displayed in the table above. The benefit is evaluated as follows:

On topology 1, 71% of the transient forwarding loops created by the failure of any link are prevented by implementing the local delay. The analysis shows that all local loops are obviously solved and only remote loops are remaining.

7. Deployment considerations

Transient forwarding loops have the following drawbacks :

This local delay proposal is a transient forwarding loop avoidance mechanism (like OFIB). Even if it only address local transient loops, , the efficiency versus complexity comparison of the mechanism makes it a good solution. It is also incrementally deployable with incremental benefits, which makes it an attractive option for both vendors to implement and Service Providers to deploy. Delaying convergence time is not an issue if we consider that the traffic is protected during the convergence.

8. Examples

We will consider the following figure for the associated examples :

        D
      1 |        F----X
        |    1   |
        A ------ B
        |        |    ^
     10 |        | 5  | T
        |        |    |
        E--------C        
        |    1   
      1 |        
        S 
		

The network above is considered to have a convergence time about 1 second, so ULOOP_DELAY_UP_TIMER and ULOOP_DELAY_DOWN_TIMER will be adjusted to this value. We also consider FRR running on each node.

8.1. Local link down

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 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 microloop is formed.

Route computation event time scale
Network condition Time Router C events Router E events
S->D Traffic OK
S->D Traffic lost t0 Link B-C fails Link B-C fails
t0+20msec C detects the failure
S->D Traffic OK t0+40msec C activates FRR
t0+50msec C updates its local LSP/LSA
t0+60msec C schedules SPF (100ms)
t0+67msec C receives LSP/LSA from B
t0+70msec C floods its local updated LSP/LSA
t0+87msec E receives LSP/LSA from C and schedules SPF (100ms)
t0+117msec E floods LSP/LSA from C
t0+160msec C computes SPF
t0+165msec C delays its RIB/FIB update (1 sec)
t0+193msec E computes SPF
t0+199msec E starts updating its RIB/FIB
t0+443msec E updates its RIB/FIB for D
t0+470msec E convergence ends
t0+1165msec C starts updating its RIB/FIB
t0+1255msec C updates its RIB/FIB for D
t0+1340msec C convergence ends

Similarly, upon B-C link down event, if LSP/LSA from B is received before C detects the link failure, C will apply the route update delay if the local detection is part of the same SPF run.

Route computation event time scale
Network condition Time Router C events Router E events
S->D Traffic OK
S->D Traffic lost t0 Link B-C fails Link B-C fails
t0+32msec C receives LSP/LSA from B
t0+33msec C schedules SPF (100ms)
t0+50msec C detects the failure
S->D Traffic OK t0+55msec C activates FRR
t0+55msec C updates its local LSP/LSA
t0+70msec C floods its local updated LSP/LSA
t0+87msec E receives LSP/LSA from C and schedules SPF (100ms)
t0+117msec E floods LSP/LSA from C
t0+160msec C computes SPF
t0+165msec C delays its RIB/FIB update (1 sec)
t0+193msec E computes SPF
t0+199msec E starts updating its RIB/FIB
t0+443msec E updates its RIB/FIB for D
t0+470msec E convergence ends
t0+1165msec C starts updating its RIB/FIB
t0+1255msec C updates its RIB/FIB for D
t0+1340msec C convergence ends

8.2. Local and remote event

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 link will fail in the same time window. C will not apply the local delay because a non local topology change is also received.

Route computation event time scale
Network condition Time Router C events Router E events
S->D Traffic OK
S->D Traffic lost t0 Link B-C fails Link B-C fails
t0+20msec C detects the failure
t0+36msec Link F-X fails Link F-X fails
S->D Traffic OK t0+40msec C activates FRR
t0+50msec C updates its local LSP/LSA
t0+54msec C receives LSP/LSA from F and floods it
t0+60msec C schedules SPF (100ms)
t0+67msec C receives LSP/LSA from B
t0+69msec E receives LSP/LSA from F, floods it and schedules SPF (100ms)
t0+70msec C floods its local updated LSP/LSA
t0+87msec E receives LSP/LSA from C
t0+117msec E floods LSP/LSA from C
t0+160msec C computes SPF
t0+165msec C starts updating its RIB/FIB (NO DELAY)
t0+170msec E computes SPF
t0+173msec E starts updating its RIB/FIB
S->D Traffic lost t0+365msec C updates its RIB/FIB for D
S->D Traffic OK t0+443msec E updates its RIB/FIB for D
t0+450msec C convergence ends
t0+470msec E convergence ends

8.3. Aborting local delay

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 link will fail during local delay run. C will first apply local delay, but when the new event happens, it will fallback to the standard convergence mechanism without delaying route insertion anymore. In this example, we consider a ULOOP_DELAY_DOWN_TIMER configured to 2 seconds.

Route computation event time scale
Network condition Time Router C events Router E events
S->D Traffic OK
S->D Traffic lost t0 Link B-C fails Link B-C fails
t0+20msec C detects the failure
S->D Traffic OK t0+40msec C activates FRR
t0+50msec C updates its local LSP/LSA
t0+60msec C schedules SPF (100ms)
t0+67msec C receives LSP/LSA from B
t0+70msec C floods its local updated LSP/LSA
t0+87msec E receives LSP/LSA from C and schedules SPF (100ms)
t0+117msec E floods LSP/LSA from C
t0+160msec C computes SPF
t0+165msec C delays its RIB/FIB update (2 sec)
t0+193msec E computes SPF
t0+199msec E starts updating its RIB/FIB
t0+254msec Link F-X fails Link F-X fails
t0+300msec C receives LSP/LSA from F and floods it
t0+303msec C schedules SPF (200ms)
t0+312msec E receives LSP/LSA from F and floods it
t0+313msec E schedules SPF (200ms)
t0+502msec C computes SPF
t0+505msec C starts updating its RIB/FIB (NO DELAY)
t0+514msec E computes SPF
t0+519msec E starts updating its RIB/FIB
S->D Traffic lost t0+659msec C updates its RIB/FIB for D
S->D Traffic OK t0+778msec E updates its RIB/FIB for D
t0+781msec C convergence ends
t0+810msec E convergence ends

9. Comparison with other solutions

As stated in Section 3, our solution reuses some concepts already introduced by other IETF proposals but tries to find a tradeoff between efficiency and simplicity. This section tries to compare behaviors of the solutions.

9.1. PLSN

PLSN ([I-D.ietf-rtgwg-microloop-analysis]) describes a mechanism where each node in the network tries a avoid transient forwarding 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 locked path may be the new primary nexthop, another neighbor, or the old primary nexthop depending how the safety condition is satisified.

PLSN does not solve all transient forwarding loops (see [I-D.ietf-rtgwg-microloop-analysis] Section 4 for more details).

Our solution reuse some concept of PLSN but in a more simple fashion :

9.2. OFIB

OFIB ([RFC6976]) describes a mechanism where convergence of the network upon a topology change is made ordered to prevent transient forwarding loops. Each router in the network must deduce the failure type from the LSA/LSP received and compute/apply a specific FIB update timer based on the failure type and its rank in the network considering the failure point as root.

This mechanism permit to solve all the transient forwarding loop in a network at the price of introducing complexity in the convergence process that may require strong monitoring by the service provider.

Our solution reuses the OFIB concept but limits it to the first hop that experience the topology change. As demonstrated, our proposal permits to solve all the local transient forwarding loops that represents a high percentage of all the loops. Moreover limiting the mechanism to one hop permit to keep the network-wide convergence behavior.

10. Existing implementations

At this time, there is three different implementations of this mechanism : CISCO IOS-XR, CISCO IOS-XE and Juniper JUNOS. The three implementations have been tested in labs and demonstrated a good behavior in term of local micro-loop avoidance. No side effects have been found.

11. Security Considerations

This document does not introduce change in term of IGP security. The operation is internal to the router. The local delay does not increase the attack vector as an attacker could only trigger this mechanism if he already has be ability to disable or enable an IGP 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 can already harm the network by creating instability and harm the traffic by creating forwarding packet loss and forwarding loss for the traffic crossing that link.

12. Acknowledgements

We wish to thanks the authors of [RFC6976] for introducing the concept of ordered convergence: Mike Shand, Stewart Bryant, Stefano Previdi, and Olivier Bonaventure.

13. IANA Considerations

This document has no actions for IANA.

14. References

14.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2010.

14.2. Informative References

[I-D.ietf-rtgwg-lfa-manageability] Litkowski, S., Decraene, B., Filsfils, C., Raza, K., Horneffer, M. and P. Sarkar, "Operational management of Loop Free Alternates", Internet-Draft draft-ietf-rtgwg-lfa-manageability-11, June 2015.
[I-D.ietf-rtgwg-microloop-analysis] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Internet-Draft draft-ietf-rtgwg-microloop-analysis-01, October 2005.
[RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003.
[RFC6571] Filsfils, C., Francois, P., 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.
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P. and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2013.
[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.

Authors' Addresses

Stephane Litkowski Orange EMail: stephane.litkowski@orange.com
Bruno Decraene Orange EMail: bruno.decraene@orange.com
Clarence Filsfils Cisco Systems EMail: cfilsfil@cisco.com
Pierre Francois Cisco Systems EMail: pifranco@cisco.com