Routing Area Working Group
Internet Engineering Task Force (IETF)                      S. Litkowski
Internet-Draft
Request for Comments: 8333                                   B. Decraene
Intended status:
Category: Standards Track                                         Orange
Expires: May 16, 2018
ISSN: 2070-1721                                              C. Filsfils
                                                           Cisco Systems
                                                             P. Francois
                                                  Individual
                                                       November 12, 2017 Contributor
                                                              March 2018

     Micro-loop prevention Prevention by introducing Introducing a local convergence delay
                    draft-ietf-rtgwg-uloop-delay-09 Local Convergence Delay

Abstract

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

   As

   Because this mechanism delays the IGP convergence convergence, it may only be
   used for planned maintenance or when fast reroute Fast Reroute (FRR) protects the
   traffic during the time between the link failure time and the IGP
   convergence.

   The proposed mechanism is limited to the link down link-down event in order to keep the
   mechanism simple.

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

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 16, 2018.
   https://www.rfc-editor.org/info/rfc8333.

Copyright Notice

   Copyright (c) 2017 2018 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
   (https://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.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................3
   2. Terminology .....................................................4
      2.1. Acronyms ...................................................4
      2.2. Requirements Language ......................................4
   3. Side Effects of Transient forwarding loops side effects . . . . . . . . . . .   4 Forwarding Loops ......................4
      3.1.  Fast reroute inefficiency . . . . . . . . . . . . . . . .   4 FRR Inefficiency ...........................................5
      3.2. Network congestion  . . . . . . . . . . . . . . . . . . .   7 Congestion .........................................7
   4. Overview of the solution  . . . . . . . . . . . . . . . . . .   7 Solution ........................................8
   5. Specification . . . . . . . . . . . . . . . . . . . . . . . .   8 ...................................................8
      5.1. Definitions . . . . . . . . . . . . . . . . . . . . . . .   8 ................................................8
      5.2. Regular IGP reaction  . . . . . . . . . . . . . . . . . .   8 Reaction .......................................9
      5.3. Local events  . . . . . . . . . . . . . . . . . . . . . .   9 Events ...............................................9
      5.4. Local delay Delay for link down . . . . . . . . . . . . . . . .  10 Link-Down Events ..........................10
   6. Applicability . . . . . . . . . . . . . . . . . . . . . . . .  10 ..................................................11
      6.1. Applicable case: local loops  . . . . . . . . . . . . . .  10 Case: Local Loops ..............................11
      6.2.  Non applicable case: remote loops . . . . . . . . . . . .  11 Non-applicable Case: Remote Loops .........................11
   7. Simulations . . . . . . . . . . . . . . . . . . . . . . . . .  11 ....................................................12
   8. Deployment considerations . . . . . . . . . . . . . . . . . .  12 Considerations ......................................13
   9. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  13 .......................................................14
      9.1. Local link down . . . . . . . . . . . . . . . . . . . . .  14 Link-Down Event .....................................14
      9.2. Local and remote event  . . . . . . . . . . . . . . . . .  18 Remote Event ....................................18
      9.3. Aborting local delay  . . . . . . . . . . . . . . . . . .  19 Local Delay ......................................20
   10. Comparison with other solutions . . . . . . . . . . . . . . .  23 Other Solutions ...............................22
      10.1. PLSN . . . . . . . . . . . . . . . . . . . . . . . . . .  23 .....................................................22
      10.2.  OFIB . . . . . . . . . . . . . . . . . . . . . . . . . .  23 oFIB .....................................................23
   11. Implementation Status . . . . . . . . . . . . . . . . . . . .  24 IANA Considerations ...........................................23
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  25 .......................................23
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     15.1. ....................................................23
      13.1. Normative References . . . . . . . . . . . . . . . . . .  26
     15.2. .....................................23
      13.2. Informative References . . . . . . . . . . . . . . . . .  26 ...................................24
   Acknowledgements ..................................................25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

2. ................................................25

1.  Introduction

   Micro-forwarding loops

   Micro-loops and some potential solutions are well described in [RFC5715].
   This document describes a simple targeted mechanism that prevents
   micro-loops that are local to the failure.  Based on network
   analysis, local failures micro-loops make up a significant portion of the micro-forwarding loops.
   micro-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 an FRR alternate has been used (see Section 3.1).

   Consider the case in Figure 1 where S does not have an LFA (Loop Free (Loop-Free
   Alternate) to protect its traffic to D when the S-D link fails.  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) FRR technique used,
   when S converges to the new topology, it will send its traffic to a
   neighbor that was is not loop-free and will thus cause a local micro-loop. micro-
   loop.  The deployment of advanced fast-reroute FRR techniques motivates this
   simple router-local mechanism to solve this targeted problem.  This
   solution can work with the various techniques described in [RFC5715].

                                  D ------ C
                                  |        |
                                  |        | 5
                                  |        |
                                  S ------ B

                                 Figure 1

   In the Figure 1, all links have a metric of 1 except the B-C link, which
   has a metric of 5.  When the S-D link fails, a transient forwarding
   loop may appear between S and B if S updates its forwarding entry to
   D before B does.

1.

2.  Terminology

2.1.  Acronyms

   FIB: Forwarding Information Base

   FRR: Fast ReRoute Reroute

   IGP: Interior Gateway Protocol

   LFA: Loop Free Loop-Free Alternate

   LSA: Link State Advertisement

   LSP: Link State Packet

   MRT: Maximum Maximally Redundant Trees

      OFIB: Tree

   oFIB: Ordered FIB

   PLR: Point of Local Repair

   PLSN: Path Locking via Safe Neighbor Neighbors

   RIB: Routing Information Base

   RLFA: Remote Loop Free Loop-Free Alternate

   SPF: Shortest Path First

   TTL: Time To to Live

2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Side Effects of Transient forwarding loops side effects Forwarding Loops

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

3.1.  Fast reroute inefficiency  FRR Inefficiency

   In Figure 2, we consider an IP/LDP routed network.

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

                                 Figure 2 - RSVP-TE FRR case

   In the Figure 2, we consider an IP/LDP routed network.

   An RSVP-TE tunnel T, provisioned on C and terminating on B, is used
   to protect the traffic against C-B link failure (the IGP shortcut
   feature, defined in [RFC3906], is activated on C ). C).  The primary path
   of T is C->B and FRR is activated on T T, providing an FRR bypass or
   detour using path C->E->A->B.  On router C, the next hop to D is the
   tunnel
   T T, thanks to the IGP shortcut.  When the C-B link fails:

   1.  C detects the failure, failure and updates the tunnel path using a
       preprogrammed FRR path.  The traffic path from S to D becomes: becomes
       S->E->C->E->A->B->A->D.

   2.  In parallel, on router C, both the IGP convergence and the TE
       tunnel convergence (tunnel path recomputation) are occurring:

       *  The Tunnel tunnel T path is recomputed and now uses C->E->A->B.

       *  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 longer on
       the shortest-path tree (SPT) to D, so C does not continue to
       encapsulate the traffic to D using the tunnel T and updates its
       forwarding entry to D using the nexthop next-hop 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 table

   Table 1 below describes a theoretical sequence of events happening when the
   B-C link fails.  This theoretical sequence of events should only be
   read as an example.

   +-----------+------------+------------------+-----------------------+

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

                                  Table 1 - Route computation event time scale

   The issue described here is completely independent of the fast-
   reroute FRR
   mechanism involved (TE (e.g., TE FRR, LFA/rLFA, MRT ...) LFA/RLFA, MRT, etc.) when the
   primary path uses hop-by-hop routing.  The protection enabled by
   fast-reroute is working perfectly, FRR
   works perfectly but ensures a protection, by
   definition, only ensures protection until the PLR has
   converged (as soon as the PLR has converged, it replaces its FRR path by
   with a new primary path).  When implementing FRR, a service provider
   wants to guarantee a very limited loss of connectivity time.  The previous
   example described in this section 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 the IGP convergence
   (1) may allow to keep the fast-reroute FRR path to be kept until the neighbors have
   converged and (2) preserves the customer traffic.

3.2.  Network congestion

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

         Figure 3 Congestion

   In the figure above, as presented in Section 2, Figure 3, when the link S-D link 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 destined to D,
   and the bandwidth of the link, the S-B link may become congested in a
   few hundreds of milliseconds and will stay congested until the loop
   is eliminated.

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

                                 Figure 3
   The congestion introduced by transient forwarding loops is
   problematic as it can affect traffic that is not directly affected by
   the failing network component.  In the example, Figure 3, the congestion of the
   S-B link will impact some customer traffic that is not directly
   affected by the failure: e.g. failure, e.g., traffic from A to B, F to B, and E to
   B.  Class of service may mitigate the congestion for some traffic.
   However, some traffic not directly affected by the failure will still
   be dropped as a router is not able to distinguish the looping traffic
   from the normally forwarded traffic.

4.  Overview of the solution Solution

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

   The proposed solution described in this document is limited to local link down link-down
   events in order to keep the solution simple.

   This ordered convergence is similar to the ordered FIB proposed (oFIB)
   approach defined in [RFC6976], but it is limited to only a "one hop" "one-hop"
   distance.  As a consequence, it is more simple and becomes a local-only local-
   only feature that does not require interoperability.  This benefit
   comes with the limitation of eliminating transient forwarding loops
   involving the local router only.  The proposed mechanism also reuses some
   concepts described in [I-D.ietf-rtgwg-microloop-analysis]. [PLSN].

5.  Specification

5.1.  Definitions

   This document will refer refers to the following existing IGP timers.  These
   timers may be standardized or implemented as a vendor specific vendor-specific local
   feature.

   o  LSP_GEN_TIMER: The delay between the consecutive generation of two consecutives
      local LSP/LSA
      generation. LSPs/LSAs.  From an operational point of view, this delay is
      usually tuned to batch multiple local events in one a single local
      LSP/LSA update.  In IS-IS, this timer is defined as
      minimumLSPGenerationInterval in [ISO10589].  In OSPF version 2, this
      timer is defined as MinLSInterval in [RFC2328].  It is often
      associated with a vendor specific vendor-specific damping mechanism to slow down
      reactions by incrementing the timer when multiple consecutive
      events are detected.

   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
      slow down reactions by incrementing the timer when the IGP becomes
      unstable.  As an example, [I-D.ietf-rtgwg-backoff-algo] [BACKOFF] defines a standard SPF (Shortest Path First) delay
      algorithm.

   This document introduces the following new timer:

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

5.2.  Regular IGP reaction

   Upon a change of Reaction

   When the status of an adjacency/link, adjacency or link changes, the regular IGP
   convergence behavior of the router advertising the event involves the
   following main steps:

   1.  IGP is notified of the Up/Down up/down event.

   2.  The IGP processes the notification and postpones the reaction for
       LSP_GEN_TIMER msec. ms.

   3.  Upon LSP_GEN_TIMER expiration, the IGP updates its LSP/LSA and
       floods it.

   4.  The SPF computation is scheduled in SPF_DELAY msec. ms.

   5.  Upon SPF_DELAY timer expiration, the SPF is computed, and then
       the RIB and FIB are updated.

5.3.  Local events 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. (e.g., multiple links or nodes failed), then
   regular IP convergence must be applied (as described in Section 5.2).

   To determine if the mechanism can be is applicable or not, an implementation
   SHOULD implement logic to correlate the protocol messages (LSP/LSA)
   received during the SPF scheduling period in order to determine the
   topology changes that occured. occurred.  This is necessary as multiple
   protocol messages may describe the same topology change 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 left to the implementation.

   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 document; otherwise, the regular
   IP convergence MUST be used.

   Example:

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

   In Figure 4

   Let 4, let router B be the computing router when the link B-C
   fails.  B updates its local LSP/LSA describing the link B->C B-C as down,
   C does the same, and both start flooding their updated LSP/LSAs. LSPs/LSAs.
   During the SPF_DELAY period, B and C learn all the LSPs/LSAs to
   consider.  B sees that C is flooding an advertisement that indicates
   that a link is down, and B is the other end of that link.  B
   determines 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.

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

                                 Figure 4

5.4.  Local delay Delay for link down

   Upon an adjacency/link down event, this Link-Down Events

   This document introduces a change in step 5 (Section 5.2) (see list in order to delay Section 5.2)
   so that, upon an adjacency or link-down event, the local convergence
   is delayed compared to the network wide network-wide convergence.  The new step 5
   is described below:

   5.  Upon SPF_DELAY timer expiration, the SPF is computed.  If the
       condition of a single local link-down event has been met, then an
       update of the RIB and the FIB MUST be delayed for
       ULOOP_DELAY_DOWN_TIMER msecs. ms.  Otherwise, the RIB and FIB SHOULD be
       updated immediately.

   If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running,
   ULOOP_DELAY_DOWN_TIMER is stopped stopped, and the RIB/FIB SHOULD be updated
   as part of the new convergence event.

   As a result of this addition, routers local to the failure will
   converge slower than remote routers.  Hence  Hence, it SHOULD only be done
   for a non-urgent convergence, such as for administrative de-
   activation deactivation
   (maintenance) or when the traffic is protected by fast-
   reroute. FRR.

6.  Applicability

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

6.1.  Applicable case: local loops

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

   In Figure 5

   Let 5, let us consider the traffic from G to F.  The primary
   path is G->D->C->E->F.  When the 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 C's FRR forwarding while all even though upstream
   routers are still forwarding the traffic to itself. C.

                          A ------ B ----- E
                          |              / |
                          |             /  |
                      G---D------------C   F

                      All the links have a metric of 1

                                 Figure 5

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

6.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  Non-applicable Case: Remote Loops

   In Figure 6

   Let 6, 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.

                   A ------ B ----- E --- H
                   |                      |
                   |                      |
               G---D--------C ------F --- J ---- K

               All the links have a metric of 1 except B-E=15

                                 Figure 6
   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,
   allowing time for D to converge.  When the timer ULOOP_DELAY_DOWN_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 -- such as when the nodes update their FIB in the following order C,
   A,
   D, for example D because the router A is quicker than D to converge- converge -- the
   mechanism may still avoid the forwarding loop that would have
   otherwise occurred.

7.  Simulations

   Simulations have been run on multiple service provider service-provider topologies.
   We evaluated the efficiency of the mechanism on eight different
   service-provider topologies (different network size and design).
   Table 2 displays the gain for each topology.

                            +----------+------+
                            | Topology | Gain |
                            +----------+------+
                            |    T1    | 71%  |
                            |    T2    | 81%  |
                            |    T3    | 62%  |
                            |    T4    | 50%  |
                            |    T5    | 70%  |
                            |    T6    | 70%  |
                            |    T7    | 59%  |
                            |    T8    | 77%  |
                            +----------+------+

                                  Table 2 - Number of Repair/Dst that may loop

   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 gain as follows:

   o  We consider considered a tuple (link A-B, destination D, PLR S, backup
      nexthop
      next-hop N) as a loop if if, upon link A-B failure, the flow from a
      router S upstream from A (A could be considered as PLR also) to D
      may loop due to convergence time difference between S and one of
      his
      its neighbors N.

   o  We evaluate evaluated the number of potential loop tuples in normal
      conditions.

   o  We evaluate evaluated the number of potential loop tuples using the same
      topological input but taking into account that S converges after
      N.

   o  The gain is how many the relative number of loops (both remote and local)
      we succeed to
      suppress.

   On in suppressing.

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

8.  Deployment considerations Considerations

   Transient forwarding loops have the following drawbacks:

   o  They limit FRR efficiency: even efficiency.  Even if FRR is activated within 50msec, 50 ms,
      as soon as the PLR has converged, the traffic may be affected by a
      transient loop.

   o  They may impact traffic not directly affected by the failure (due
      to link congestion).

   This

   The local delay proposal mechanism is a transient forwarding loop avoidance
   mechanism (like OFIB). oFIB).  Even if it only addresses 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 both for both
   vendors to implement and service providers to deploy.  Delaying the
   convergence time is not an issue if we consider that the traffic is
   protected during the convergence.

   The ULOOP_DELAY_DOWN_TIMER value should be set according to the
   maximum IGP convergence time observed in the network (usually
   observed in the slowest node).

   The proposed

   This mechanism is limited to link down link-down events.  When a link goes
   down, it eventually goes back up.  As a consequence, with the
   proposed this
   mechanism deployed, only the link down link-down event will be protected
   against transient forwarding loops while the link up link-up event will not.
   If the operator wants to limit the impact of the transient forwarding
   loops during the link up link-up event, it should take care of
   using make sure to use specific
   procedures to bring the link back online.  As examples, the operator
   can decide to put back the link back online out outside of business hours hours, or
   it can use some incremental metric changes to prevent loops (as
   proposed in [RFC5715]).

9.  Examples

   We will consider the following figure for the associated examples : in this section:

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

                                 Figure 7

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

9.1.  Local link down

   The table Link-Down Event

   Table 3 describes the events and associated their timing that happen on
   router routers C and E when
   the link B-C goes down.  It is based on a theoretical sequence of event
   events that should only been read as an example.  As C detects a
   single local event corresponding to a link down link-down event (its LSP + LSP
   from B received), it applies the local delay down behavior behavior, and no
   microloop
   micro-loop is formed.

   +-----------+-------------+------------------+----------------------+

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

                                  Table 3 - Route computation event time scale

   Similarly, upon B-C link down 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.  The table  Table 4
   describes the associated theoretical sequence of events.  It should
   only been read as an example.

   +-----------+-------------+------------------+----------------------+

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

                                  Table 4 - Route computation event time scale

9.2.  Local and remote event

   The table Remote Event

   Table 5 describes the events and associated their timing that happen on router C and E when
   the link B-C goes down, in addition F-X down and when the link will
   fail F-X fails in the same time
   window.  C will not apply the local delay because a non local non-local
   topology change is also received.  The table  Table 5 is based on a theoretical
   sequence of event events that should only been read as an example.

   +-----------+------------+-----------------+------------------------+

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

                                  Table 5 - Route computation event time scale

9.3.  Aborting local delay

   The table Local Delay

   Table 6 describes the events and associated their timing that happen on
   router routers C and E when
   the link B-C goes down.  In addition, we consider what happens when
   the F-X link fails during local delay of the FIB update.  C will
   first apply the local delay, but when the new event happens, it will
   fall back to the standard convergence mechanism without further
   delaying route insertion.  In this example, we consider a
   ULOOP_DELAY_DOWN_TIMER configured to 2 seconds.  The table  Table 6 is based on
   a theoretical sequence of event events that should only been read as an
   example.

   +-----------+------------+-------------------+----------------------+

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

                                  Table 6 - Route computation event time scale

10.  Comparison with other solutions Other Solutions

   As stated in Section 4, the proposed local delay solution reuses some concepts
   already introduced by other IETF proposals but tries to find a
   tradeoff trade-
   off between efficiency and simplicity.  This section tries to compare
   behaviors of the solutions.

10.1.  PLSN

   PLSN ([I-D.ietf-rtgwg-microloop-analysis]) [PLSN] describes a mechanism where each node in the network
   tries to 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, next hop, another neighbor, or the old primary nexthop next hop
   depending on how the safety condition is satisfied.

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

   Our

   The solution defined in this document reuses some concept concepts of PLSN
   but in a more simple fashion:

   o  PLSN has three different behaviors: (1) keep using the old nexthop, next
      hop, (2) use the new primary nexthop next hop if it is safe, or (3) use
      another safe nexthop,
      while the proposed solution next hop.  The local delay solution, however, only
      has one: keep using the current
      nexthop (old primary, next hop (i.e., the old primary
      next hop or already activated an already-activated FRR path).

   o  PLSN may cause some damage while using a safe nexthop which next hop that is not
      the new primary nexthop in case next hop if the new safe nexthop next hop does not provide
      enough bandwidth (see [RFC7916]).  This  The solution defined in this
      document may not experience this issue as the service provider may
      have control on the FRR path being used used, preventing network
      congestion.

   o  PLSN applies to all nodes in a network (remote or local changes),
      while the proposed mechanism defined in this document applies only on to the
      nodes connected to the topology change.

10.2.  OFIB

   OFIB ([RFC6976])  oFIB

   oFIB [RFC6976] describes a mechanism where the convergence of the
   network upon a topology change is ordered in order to prevent
   transient forwarding loops.  Each router in the network must deduce deduces the
   failure 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 network, considering the failure point as root.

   This

   The oFIB mechanism allows to solve solves all the transient forwarding loop loops in a
   network at the price of introducing complexity in the convergence
   process that may require a strong careful monitoring by the service provider.

   Our

   The solution defined in this document reuses the OFIB oFIB concept but
   limits it to the first hop that experiences the topology change.  As
   demonstrated, the mechanism
   proposed defined in this document allows to solve all the
   local transient forwarding loops that represents an to be solved; these represent a high
   percentage of all the loops.
   Moreover  Moreover, limiting the mechanism to one hop allows to keep the
   network-wide convergence behavior.

11.  Implementation Status

   At this time, there are three different implementations of this
   mechanism.

   o  Implementation 1:

      *  Organization: Cisco

      *  Implementation name: Local Microloop Protection

      *  Operating system: IOS-XE

      *  Level of maturity: production release

      *  Coverage: all the specification is implemented

      *  Protocols supported: ISIS and OSPF

      *  Implementation experience: tested in lab and works as expected

      *  Comment: the feature gives the ability to choose to apply the
         delay to FRR protected entry only

      *  Report last update: 10-11-2017

   o  Implementation 2:

      *  Organization: Cisco

      *  Implementation name: Local Microloop Protection

      *  Operating system: IOS-XR

      *  Level of maturity: deployed

      *  Coverage: all the specification is implemented
      *  Protocols supported: ISIS and OSPF

      *  Implementation experience: deployed and works as expected

      *  Comment: the feature gives the ability to choose to apply the
         delay to FRR protected entry only

      *  Report last update: 10-11-2017

   o  Implementation 3:

      *  Organization: Juniper Networks

      *  Implementation name: Microloop avoidance when IS-IS link fails

      *  Operating system: JUNOS

      *  Level of maturity: deployed (hidden command)

      *  Coverage: all the specification is implemented

      *  Protocols supported: ISIS only

      *  Implementation experience: deployed and works as expected

      *  Comment: the feature applies behavior to all the ISIS routes

      *  Report last update: 10-11-2017 be kept.

11.  IANA Considerations

   This document has no IANA actions.

12.  Security Considerations

   This document does not introduce any change in term terms of IGP security.
   The operation is internal to the router.  The local delay does not
   increase the number of attack vectors as an attacker could only
   trigger this mechanism if he it already has be the ability to disable or
   enable an IGP link.  The local delay does not increase the negative
   consequences.  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.

14.  IANA Considerations

   This document has no actions for IANA.

15.

13.  References

15.1.

13.1.  Normative References

   [ISO10589]
              "Intermediate International Organization for Standardization,
              "Information technology -- Telecommunications and
              information exchange between systems -- Intermediate
              System to Intermediate System intra-domain routeing
              information exchange protocol for use in conjunction with
              the protocol for providing the connectionless-mode network
              service (ISO 8473)",
              ISO 10589, ISO/IEC 10589:2002, Second Edition,
              November 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

15.2.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.  Informative References

   [I-D.ietf-rtgwg-backoff-algo]

   [BACKOFF]  Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
              Francois, P., and C. Bowers, "SPF Back-off Delay algorithm
              for link state IGPs", draft-ietf-rtgwg-backoff-algo-06 (work Work in progress), October 2017.

   [I-D.ietf-rtgwg-microloop-analysis] Progress, draft-ietf-rtgwg-
              backoff-algo-10, March 2018.

   [PLSN]     Zinin, A., "Analysis and Minimization of Microloops in
              Link-state Routing Protocols", draft-ietf-rtgwg-microloop-
              analysis-01 (work Work in progress), Progress,
              draft-ietf-rtgwg-microloop-analysis-01, October 2005.

   [RFC3906]  Shen, N. and H. Smit, "Calculating Interior Gateway
              Protocol (IGP) Routes Over Traffic Engineering Tunnels",
              RFC 3906, DOI 10.17487/RFC3906, October 2004,
              <https://www.rfc-editor.org/info/rfc3906>.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, DOI 10.17487/RFC5715, January
              2010, <https://www.rfc-editor.org/info/rfc5715>.

   [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, <https://www.rfc-editor.org/info/rfc6976>.

   [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, <https://www.rfc-editor.org/info/rfc7916>.

13.

Acknowledgements

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

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
   Individual Contributor

   Email: pfrpfr@gmail.com