Micro-loop prevention by introducing a local convergence delay
draft-ietf-rtgwg-uloop-delay-03

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 time and the IGP convergence.

The proposed mechanism will be limited to the 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 June 2, 2017.

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
• 2. Transient forwarding loops side effects
• 2.1. Fast reroute inefficiency
• 2.2. Network congestion
• 3. Overview of the solution
• 4. Specification
• 4.1. Definitions
• 4.2. Current IGP reactions
• 4.3. Local events
• 4.4. Local delay for link down
• 5. Applicability
• 5.1. Applicable case: local loops
• 5.2. Non applicable case: remote loops
• 6. Simulations
• 7. Deployment considerations
• 8. Examples
• 8.1. Local link down
• 8.2. Local and remote event
• 8.3. Aborting local delay
• 9. Comparison with other solutions
• 9.1. PLSN
• 9.2. OFIB
• 10. Existing implementations
• 11. Security Considerations
• 12. Acknowledgements
• 13. IANA Considerations
• 14. References
• 14.1. Normative References
• 14.2. Informative References
• Authors' Addresses

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 that are local to the failure; based on network analysis, these are a significant portion of the micro-forwarding loops. A simple and easily deployable solution for these local micro-loops is critical because these local loops cause some traffic loss after a 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 (FRR) 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 inefficiency

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

1. C detects the failure, and updates the tunnel path using preprogrammed FRR path, the traffic path from S to D becomes: 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 occurring:
   • T path is recomputed and now uses C->E->A->B.
   • 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 shortest-path tree (SPT) to D, so C does not encapsulate anymore 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 be a transient forwarding loop between C and E until E has converged.

The issue described here is completely independent of the fast-reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...). The protection enabled by 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 allow to keep fast-reroute path until the neighbors have converged and preserves the customer traffic.

2.2. Network congestion

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

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

The congestion introduced by transient forwarding loops is problematic as it is impacting traffic that is not directly concerned by the failing network component. In our example, the congestion of the S-B link will impact some customer traffic that is not directly concerned by the failure: e.g. A to B, F to B, E to B. Some class 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 the looping traffic from the normally forwarded 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 for simplicity reason.

This ordered convergence, is similar to the ordered FIB proposed defined in [RFC6976], but limited to only a "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 limitations.

4. Specification

4.1. Definitions

This document will refer to the following existing IGP timers:

• LSP_GEN_TIMER: used to batch multiple local events in one single local LSP update. It is often associated with a damping mechanism to slow down reactions by incrementing the timer when multiple consecutive events are detected.
• SPF_TIMER: used to batch multiple events in one single computation. It is often associated with a damping mechanism to slow down reactions by incrementing the timer when the IGP becomes unstable.

This document introduces the following new timer:

• ULOOP_DELAY_DOWN_TIMER: used to slow down the local node convergence in case of link down events.

4.2. Current IGP reactions

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

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

4.3. Local events

The mechanism described in this document assumes 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).

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.

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

Example:

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 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 and may decide to activate the mechanism described in this document.

4.4. Local delay for link down

Upon an adjacency/link down event, this document introduces a change in step 5 (Section 4.2) 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 a single local link down event (Section 4.3). 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 a non-urgent convergence, such as for administrative de-activation (maintenance) or when the traffic is protected by fast-reroute.

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 C-E 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 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 traffic during this period. When the timer expires on C, its forwarding entry to F is updated. There is no transient forwarding loop on the link C-D.

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 C-F 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 C-F fails, C delays the update of its forwarding entry to K, letting time for D to converge. When the timer expires on C, its 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 occurring.

6. Simulations

Simulations have been run on multiple service provider topologies.

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