<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY BASE SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY ALT-SP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tian-frr-alt-shortest-path.xml">
<!ENTITY BFD SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-base.xml">
<!ENTITY MPLSFRR SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY MICROLOOP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-lf-conv-frmwk.xml">
<!ENTITY NOTVIA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-notvia-addresses.xml">
<!ENTITY TUNNELS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryant-ipfrr-tunnels.xml">
<!ENTITY U-TURNS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-ip-local-protect-uturn.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-rtgwg-ipfrr-framework-13"
     ipr="trust200902" updates="">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>IP Fast Reroute Framework</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Mike Shand" initials="M." surname="Shand">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>250, Longwater Avenue.</street>

          <!-- Reorder these if your country does things differently -->

          <city>Reading</city>

          <region>Berks</region>

          <code>RG2 6GB</code>

          <country>UK</country>
        </postal>

        <email>mshand@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Stewart Bryant" initials="S." surname="Bryant">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>250, Longwater Avenue.</street>

          <city>Reading</city>

          <region>Berks</region>

          <code>RG2 6GB</code>

          <country>UK</country>
        </postal>

        <email>stbryant@cisco.com</email>
      </address>
    </author>

    <date year="2009" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document provides a framework for the development of IP
      fast-reroute mechanisms which provide protection against link or router
      failure by invoking locally determined repair paths. Unlike MPLS
      fast-reroute, the mechanisms are applicable to a network employing
      conventional IP routing and forwarding.</t>
    </abstract>
  </front>

  <middle>
    <section title="Terminology">
      <t>This section defines words and acronyms used in this draft and other
      drafts discussing IP fast-reroute.</t>

      <t><list hangIndent="20" style="hanging">
          <t hangText="D">Used to denote the destination router under
          discussion.</t>

          <t hangText="Distance_opt(A,B)">The metric sum of the shortest path
          from A to B.</t>

          <t hangText="Downstream Path">This is a subset of the loop-free
          alternates where the neighbor N meets the following condition:-
          <vspace blankLines="1" />Distance_opt(N, D) &lt;
          Distance_opt(S,D)</t>

          <t hangText="E">Used to denote the router which is the primary
          neighbor to get from S to the destination D. Where there is an ECMP
          set for the shortest path from S to D, these are referred to as E_1,
          E_2, etc.</t>

          <t hangText="ECMP">Equal cost multi-path: Where, for a particular
          destination D, multiple primary next-hops are used to forward
          traffic because there exist multiple shortest paths from S via
          different output layer-3 interfaces.</t>

          <t hangText="FIB">Forwarding Information Base. The database used by
          the packet forwarder to determine what actions to perform on a
          packet.</t>

          <t hangText="IPFRR">IP fast-reroute.</t>

          <t hangText="Link(A-&gt;B)">A link connecting router A to router
          B.</t>

          <t hangText="LFA">Loop Free Alternate. A neighbor N, that is not a
          primary neighbor E, whose shortest path to the destination D does
          not go back through the router S. The neighbor N must meet the
          following condition:- <vspace blankLines="1" />Distance_opt(N, D)
          &lt; Distance_opt(N, S) + Distance_opt(S, D)</t>

          <t hangText="Loop Free Neighbor">A neighbor N_i, which is not the
          particular primary neighbor E_k under discussion, and whose shortest
          path to D does not traverse S. For example, if there are two primary
          neighbors E_1 and E_2, E_1 is a loop-free neighbor with regard to
          E_2 and vice versa.</t>

          <t hangText="Loop Free Link Protecting Alternate"><vspace
          blankLines="0" />A path via a Loop-Free Neighbor N_i that reaches
          destination D without going through the particular link of S that is
          being protected. In some cases the path to D may go through the
          primary neighbor E.</t>

          <t hangText="Loop Free Node-protecting Alternate"><vspace
          blankLines="0" />A path via a Loop-Free Neighbor N_i that reaches
          destination D without going through the particular primary neighbor
          (E) of S which is being protected.</t>

          <t hangText="N_i">The ith neighbor of S.</t>

          <t hangText="Primary Neighbor">A neighbor N_i of S which is one of
          the next hops for destination D in S's FIB prior to any failure.</t>

          <t hangText="R_i_j">The jth neighbor of N_i.</t>

          <t hangText="Repair Path">The path used by a repairing node to send
          traffic that it is unable to send via the normal path owing to a
          failure.</t>

          <t hangText="Routing Transition">The process whereby routers
          converge on a new topology. In conventional networks this process
          frequently causes some disruption to packet delivery.</t>

          <t hangText="RPF">Reverse Path Forwarding. I.e. checking that a
          packet is received over the interface which would be used to send
          packets addressed to the source address of the packet.</t>

          <t hangText="S">Used to denote a router that is the source of a
          repair that is computed in anticipation of the failure of a
          neighboring router denoted as E, or of the link between S and E. It
          is the viewpoint from which IP fast-reroute is described.</t>

          <t hangText="SPF">Shortest Path First, e.g. Dijkstra's
          algorithm.</t>

          <t hangText="SPT">Shortest path tree</t>

          <t hangText="Upstream Forwarding Loop"><vspace blankLines="0" />A
          forwarding loop that involves a set of routers, none of which is
          directly connected to the link that has caused the topology change
          that triggered a new SPF in any of the routers.</t>
        </list></t>
    </section>

    <section title="Introduction">
      <t>When a link or node failure occurs in a routed network, there is
      inevitably a period of disruption to the delivery of traffic until the
      network re-converges on the new topology. Packets for destinations which
      were previously reached by traversing the failed component may be
      dropped or may suffer looping. Traditionally such disruptions have
      lasted for periods of at least several seconds, and most applications
      have been constructed to tolerate such a quality of service.</t>

      <t>Recent advances in routers have reduced this interval to under a
      second for carefully configured networks using link state IGPs. However,
      new Internet services are emerging which may be sensitive to periods of
      traffic loss which are orders of magnitude shorter than this.</t>

      <t>Addressing these issues is difficult because the distributed nature
      of the network imposes an intrinsic limit on the minimum convergence
      time which can be achieved.</t>

      <t>However, there is an alternative approach, which is to compute backup
      routes that allow the failure to be repaired locally by the router(s)
      detecting the failure without the immediate need to inform other routers
      of the failure. In this case, the disruption time can be limited to the
      small time taken to detect the adjacent failure and invoke the backup
      routes. This is analogous to the technique employed by MPLS fast-reroute
      <xref target="RFC4090"></xref>, but the mechanisms employed for the
      backup routes in pure IP networks are necessarily very different.</t>

      <t>This document provides a framework for the development of this
      approach.</t>

      <t>Note that in order to further minimise the impact on user
      applications, it may be necessary to design the network such that backup
      paths with suitable characteristics, for example capacity and/or delay,
      are available for the algorithms to select. Such considerations are
      outside the scope of this document.</t>
    </section>

    <section title="Scope and applicability ">
      <t>The initial scope of this work is in the context of link state IGPs.
      Link state protocols provide ubiquitous topology information, which
      facilitates the computation of repairs paths.</t>

      <t>Provision of similar facilities in non-link state IGPs and BGP is a
      matter for further study, but the correct operation of the repair
      mechanisms for traffic with a destination outside the IGP domain is an
      important consideration for solutions based on this framework.</t>

      <t>Complete protection against multiple unrelated failures is out of
      scope of this work.</t>
    </section>

    <section title="Problem Analysis">
      <t>The duration of the packet delivery disruption caused by a
      conventional routing transition is determined by a number of factors:
      <list style="numbers">
          <t>The time taken to detect the failure. This may be of the order of
          a few milliseconds when it can be detected at the physical layer, up
          to several tens of seconds when a routing protocol Hello is
          employed. During this period packets will be unavoidably lost.</t>

          <t>The time taken for the local router to react to the failure. This
          will typically involve generating and flooding new routing updates,
          perhaps after some hold-down delay, and re-computing the router's
          FIB.</t>

          <t>The time taken to pass the information about the failure to other
          routers in the network. In the absence of routing protocol packet
          loss, this is typically between 10 milliseconds and 100 milliseconds
          per hop.</t>

          <t>The time taken to re-compute the forwarding tables. This is
          typically a few milliseconds for a link state protocol using
          Dijkstra's algorithm.</t>

          <t>The time taken to load the revised forwarding tables into the
          forwarding hardware. This time is very implementation dependant and
          also depends on the number of prefixes affected by the failure, but
          may be several hundred milliseconds.</t>
        </list>The disruption will last until the routers adjacent to the
      failure have completed steps 1 and 2, and then all the routers in the
      network whose paths are affected by the failure have completed the
      remaining steps.</t>

      <t>The initial packet loss is caused by the router(s) adjacent to the
      failure continuing to attempt to transmit packets across the failure
      until it is detected. This loss is unavoidable, but the detection time
      can be reduced to a few tens of milliseconds as described in <xref
      target="fast-failure-detect"></xref>.</t>

      <t>In some topologies subsequent packet loss may be caused by the
      "micro-loops" which may form as a result of temporary inconsistencies
      between routers' forwarding tables<xref
      target="I-D.ietf-rtgwg-lf-conv-frmwk"></xref>. These inconsistencies are
      caused by steps 3, 4 and 5 above and in many routers it is step 5 which
      is both the largest factor and which has the greatest variance between
      routers. The large variance arises from implementation differences and
      from the differing impact that a failure has on each individual router.
      For example, the number of prefixes affected by the failure may vary
      dramatically from one router to another.</t>

      <t>In order to reduce packet disruption times to a duration commensurate
      with the failure detection times, two mechanisms may be required:-</t>

      <t><list style="letters">
          <t>A mechanism for the router(s) adjacent to the failure to rapidly
          invoke a repair path, which is unaffected by any subsequent
          re-convergence.</t>

          <t>In topologies that are susceptible to micro-loops, a micro-loop
          control mechanism may be required<xref
          target="I-D.ietf-rtgwg-lf-conv-frmwk"></xref>.</t>
        </list></t>

      <t>Performing the first task without the second may result in the repair
      path being starved of traffic and hence being redundant. Performing the
      second without the first will result in traffic being discarded by the
      router(s) adjacent to the failure.</t>

      <t>Repair paths may always be used in isolation where the failure is
      short-lived. In this case, the repair paths can be kept in place until
      the failure is repaired in which case there is no need to advertise the
      failure to other routers.</t>

      <t>Similarly, micro-loop avoidance may be used in isolation to prevent
      loops arising from pre-planned management action. In which case the link
      or node being shut down can remain in service for a short time after its
      removal has been announced into the network, and hence it can function
      as its own "repair path".</t>

      <t>Note that micro-loops may also occur when a link or node is restored
      to service and thus a micro-loop avoidance mechanism may be required for
      both link up and link down cases.</t>
    </section>

    <section title="Mechanisms for IP Fast-reroute ">
      <t>The set of mechanisms required for an effective solution to the
      problem can be broken down into the sub-problems described in this
      section.</t>

      <section anchor="fast-failure-detect"
               title="Mechanisms for fast failure detection ">
        <t>It is critical that the failure detection time is minimized. A
        number of well documented approaches are possible, such as: <list
            style="numbers">
            <t>Physical detection; for example, loss of light.</t>

            <t>Routing protocol independent protocol detection; for example,
            The Bidirectional Failure Detection protocol <xref
            target="I-D.ietf-bfd-base"></xref>.</t>

            <t>Routing protocol detection; for example, use of "fast
            Hellos".</t>
          </list>When configuring packet based failure detection mechanisms it
        is important that consideration be given to the likelihood and
        consequences of false indications of failure. The incidence of false
        indication of failure may be minimised by appropriately prioritizing
        of the transmission, reception and processing of the packets used to
        detect link or node failure. Note that this is not an issue that is
        specific to IPFRR.</t>
      </section>

      <section title="Mechanisms for repair paths">
        <t>Once a failure has been detected by one of the above mechanisms,
        traffic which previously traversed the failure is transmitted over one
        or more repair paths. The design of the repair paths should be such
        that they can be pre-calculated in anticipation of each local failure
        and made available for invocation with minimal delay. There are three
        basic categories of repair paths:</t>

        <t><list style="numbers">
            <t>Equal cost multi-paths (ECMP). Where such paths exist, and one
            or more of the alternate paths do not traverse the failure, they
            may trivially be used as repair paths.</t>

            <t>Loop free alternate paths. Such a path exists when a direct
            neighbor of the router adjacent to the failure has a path to the
            destination which can be guaranteed not to traverse the
            failure.</t>

            <t>Multi-hop repair paths. When there is no feasible loop free
            alternate path it may still be possible to locate a router, which
            is more than one hop away from the router adjacent to the failure,
            from which traffic will be forwarded to the destination without
            traversing the failure.</t>
          </list></t>

        <t>ECMP and loop free alternate paths (as described in <xref
        target="RFC5286"></xref>) offer the simplest repair paths and would
        normally be used when they are available. It is anticipated that
        around 80% of failures (see <xref target="coverage"></xref>) can be
        repaired using these basic methods alone.</t>

        <t>Multi-hop repair paths are more complex, both in the computations
        required to determine their existence, and in the mechanisms required
        to invoke them. They can be further classified as:<list
            style="letters">
            <t>Mechanisms where one or more alternate FIBs are pre-computed in
            all routers and the repaired packet is instructed to be forwarded
            using a "repair FIB" by some method of per packet signaling such
            as detecting a "U-turn" <xref
            target="I-D.atlas-ip-local-protect-uturn"></xref> , <xref
            target="FIFR"></xref> or by marking the packet <xref
            target="SIMULA"></xref>.</t>

            <t>Mechanisms functionally equivalent to a loose source route
            which is invoked using the normal FIB. These include tunnels <xref
            target="I-D.bryant-ipfrr-tunnels"></xref>, alternative shortest
            paths <xref target="I-D.tian-frr-alt-shortest-path"></xref> and
            label based mechanisms.</t>

            <t>Mechanisms employing special addresses or labels which are
            installed in the FIBs of all routers with routes pre-computed to
            avoid certain components of the network. For example <xref
            target="I-D.ietf-rtgwg-ipfrr-notvia-addresses"></xref>.</t>
          </list>In many cases a repair path which reaches two hops away from
        the router detecting the failure will suffice, and it is anticipated
        that around 98% of failures (see <xref target="coverage"></xref>) can
        be repaired by this method. However, to provide complete repair
        coverage some use of longer multi-hop repair paths is generally
        necessary.</t>

        <section title="Scope of repair paths ">
          <t>A particular repair path may be valid for all destinations which
          require repair or may only be valid for a subset of destinations. If
          a repair path is valid for a node immediately downstream of the
          failure, then it will be valid for all destinations previously
          reachable by traversing the failure. However, in cases where such a
          repair path is difficult to achieve because it requires a high order
          multi-hop repair path, it may still be possible to identify lower
          order repair paths (possibly even loop free alternate paths) which
          allow the majority of destinations to be repaired. When IPFRR is
          unable to provide complete repair, it is desirable that the extent
          of the repair coverage can be determined and reported via network
          management.</t>

          <t>There is a trade-off to be achieved between minimizing the number
          of repair paths to be computed, and minimizing the overheads
          incurred in using higher order multi-hop repair paths for
          destinations for which they are not strictly necessary. However, the
          computational cost of determining repair paths on an individual
          destination basis can be very high.</t>

          <t>It will frequently be the case that the majority of destinations
          may be repaired using only the "basic" repair mechanism, leaving a
          smaller subset of the destinations to be repaired using one of the
          more complex multi-hop methods. Such a hybrid approach may go some
          way to resolving the conflict between completeness and
          complexity.</t>

          <t>The use of repair paths may result in excessive traffic passing
          over a link, resulting in congestion discard. This reduces the
          effectiveness of IPFRR. Mechanisms to influence the distribution of
          repaired traffic to minimize this effect are therefore
          desirable.</t>
        </section>

        <section anchor="coverage" title="Analysis of repair coverage ">
          <t>The repair coverage obtained is dependent on the repair strategy
          and highly dependent on the detailed topology and metrics. Estimates
          of the repair coverage quoted in this document are for illustrative
          purposes only and may not be always be achievable.</t>

          <t>In some cases the repair strategy will permit the repair of all
          single link or node failures in the network for all possible
          destinations. This can be defined as 100% coverage. However, where
          the coverage is less than 100% it is important for the purposes of
          comparisons between different proposed repair strategies to define
          what is meant by such a percentage. There are four possibilities:
          <list style="numbers">
              <t>The percentage of links (or nodes) which can be fully
              protected (i.e. for all destinations). This is appropriate where
              the requirement is to protect all traffic, but some percentage
              of the possible failures may be identified as being
              un-protectable.</t>

              <t>The percentage of destinations which can be protected for all
              link (or node) failures. This is appropriate where the
              requirement is to protect against all possible failures, but
              some percentage of destinations may be identified as being
              un-protectable.</t>

              <t>For all destinations (d) and for all failures (f), the
              percentage of the total potential failure cases (d*f) which are
              protected. This is appropriate where the requirement is an
              overall "best effort" protection.</t>

              <t>The percentage of packets normally passing though the network
              that will continue to reach their destination. This requires a
              traffic matrix for the network as part of the analysis.</t>
            </list></t>
        </section>

        <section title="Link or node repair ">
          <t>A repair path may be computed to protect against failure of an
          adjacent link, or failure of an adjacent node. In general, link
          protection is simpler to achieve. A repair which protects against
          node failure will also protect against link failure for all
          destinations except those for which the adjacent node is a single
          point of failure.</t>

          <t>In some cases it may be necessary to distinguish between a link
          or node failure in order that the optimal repair strategy is
          invoked. Methods for link/node failure determination may be based on
          techniques such as BFD<xref target="I-D.ietf-bfd-base"></xref>. This
          determination may be made prior to invoking any repairs, but this
          will increase the period of packet loss following a failure unless
          the determination can be performed as part of the failure detection
          mechanism itself. Alternatively, a subsequent determination can be
          used to optimise an already invoked default strategy.</t>
        </section>

        <section title="Maintenance of Repair paths  ">
          <t></t>

          <t>In order to meet the response time goals, it is expected (though
          not required) that repair paths, and their associated FIB entries,
          will be pre-computed and installed ready for invocation when a
          failure is detected. Following invocation the repair paths remain in
          effect until they are no longer required. This will normally be when
          the routing protocol has re-converged on the new topology taking
          into account the failure, and traffic will no longer be using the
          repair paths.</t>

          <t>The repair paths have the property that they are unaffected by
          any topology changes resulting from the failure which caused their
          instantiation. Therefore there is no need to re-compute them during
          the convergence period. They may be affected by an unrelated
          simultaneous topology change, but such events are out of scope of
          this work (see <xref target="SRLG"></xref>).</t>

          <t>Once the routing protocol has re-converged it is necessary for
          all repair paths to take account of the new topology. Various
          optimizations may permit the efficient identification of repair
          paths which are unaffected by the change, and hence do not require
          full re-computation. Since the new repair paths will not be required
          until the next failure occurs, the re-computation may be performed
          as a background task and be subject to a hold-down, but excessive
          delay in completing this operation will increase the risk of a new
          failure occurring before the repair paths are in place.</t>
        </section>

        <section title="Local Area Networks  ">
          <t>Protection against partial or complete failure of LANs is more
          complex than the point to point case. In general there is a
          trade-off between the simplicity of the repair and the ability to
          provide complete and optimal repair coverage.</t>
        </section>

        <section anchor="SRLG"
                 title="Multiple failures and Shared Risk Link Groups  ">
          <t>Complete protection against multiple unrelated failures is out of
          scope of this work. However, it is important that the occurrence of
          a second failure while one failure is undergoing repair should not
          result in a level of service which is significantly worse than that
          which would have been achieved in the absence of any repair
          strategy.</t>

          <t>Shared Risk Link Groups (SRLGs) are an example of multiple
          related failures, and the more complex aspects of their protection
          is a matter for further study.</t>

          <t>One specific example of an SRLG which is clearly within the scope
          of this work is a node failure. This causes the simultaneous failure
          of multiple links, but their closely defined topological
          relationship makes the problem more tractable.</t>
        </section>
      </section>

      <section title="Mechanisms for micro-loop prevention  ">
        <t>Ensuring the absence of micro-loops is important not only because
        they can cause packet loss in traffic which is affected by the
        failure, but because by saturating a link with looping packets they
        can also cause congestion loss of traffic flowing over that link which
        would otherwise be unaffected by the failure.</t>

        <t>A number of solutions to the problem of micro-loop formation have
        been proposed and are summarized in <xref
        target="I-D.ietf-rtgwg-lf-conv-frmwk"></xref>. The following factors
        are significant in their classification:<list style="numbers">
            <t>Partial or complete protection against micro-loops.</t>

            <t>Delay imposed upon convergence.</t>

            <t>Tolerance of multiple failures (from node failures, and in
            general).</t>

            <t>Computational complexity (pre-computed or real time).</t>

            <t>Applicability to scheduled events.</t>

            <t>Applicability to link/node reinstatement.</t>

            <t>Topological constraints.</t>
          </list></t>
      </section>
    </section>

    <section title="Management Considerations ">
      <t>While many of the management requirements will be specific to
      particular IPFRR solutions, the following general aspects need to be
      addressed: <list style="numbers">
          <t>Configuration <list style="letters">
              <t>Enabling/disabling IPFRR support.</t>

              <t>Enabling/disabling protection on a per link/node basis.</t>

              <t>Expressing preferences regarding the links/nodes used for
              repair paths.</t>

              <t>Configuration of failure detection mechanisms.</t>

              <t>Configuration of loop avoidance strategies</t>
            </list></t>

          <t>Monitoring and operational support<list style="letters">
              <t>Notification of links/nodes/destinations which cannot be
              protected.</t>

              <t>Notification of pre-computed repair paths, and anticipated
              traffic patterns.</t>

              <t>Counts of failure detections, protection invocations and
              packets forwarded over repair paths.</t>

              <t>Testing repairs.</t>
            </list></t>
        </list></t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations that arise from this framework
      document.</t>
    </section>

    <section title="Security Considerations">
      <t>This framework document does not itself introduce any security
      issues, but attention must be paid to the security implications of any
      proposed solutions to the problem.</t>

      <t>Where the chosen solution uses tunnels it is necessary to ensure that
      the tunnel is not used as an attack vector. One method of addressing
      this is to use a set of tunnel endpoint addresses that are excluded from
      use by user traffic.</t>

      <t>There is a compatibility issue between IPFRR and reverse path
      forwarding (RPF) checking. Many of the solutions described in this
      document result in traffic arriving from a direction inconsistent with a
      standard RPF check. When a network relies on RPF checking for security
      purposes, an alternative security mechanism will need to be deployed in
      order to permit IPFRR to used.</t>

      <t>Because the repair path will often be of a different length to the
      pre-failure path, security mechanisms which rely on specific TTL values
      will be adversely affected.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to acknowledge contributions made by Alia
      Atlas, Clarence Filsfils, Pierre Francois, Joel Halpern, Stefano Previdi
      and Alex Zinin.</t>
    </section>

    <!-- -->
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Informative References">
      &BASE;

      &ALT-SP;

      &BFD;

      &MPLSFRR;

      &MICROLOOP;

      &NOTVIA;

      &TUNNELS;

      &U-TURNS;

      <reference anchor="FIFR">
        <front>
          <title>Fast local rerouting for handling transient link
          failures."</title>

          <author initials="S." surname="Nelakuditi">
            <organization abbrev="USC">University of South
            Carolina</organization>
          </author>

          <author initials="S." surname="Lee">
            <organization abbrev="USC">University of South
            Carolina</organization>
          </author>

          <author initials="Y." surname="Lu">
            <organization abbrev="USC">University of South
            Carolina</organization>
          </author>

          <author initials="Z. L." surname="Zhang">
            <organization abbrev="USC">University of South
            Carolina</organization>
          </author>

          <author initials="C. N." surname="Chuah">
            <organization abbrev="USC">University of South
            Carolina</organization>
          </author>

          <date year="2004" />
        </front>

        <seriesInfo name="Tech. Rep." value="TR-2004-004" />
      </reference>

      <reference anchor="SIMULA"
                 target="http://folk.uio.no/amundk/infocom06.pdf">
        <front>
          <title>Fast IP Network Recovery using Multiple Routing
          Configurations."</title>

          <author initials="O." surname="Lysne">
            <organization abbrev="SIMULA">SIMULA Research
            Laboratory</organization>
          </author>

          <author initials="A." surname="Kvalbein">
            <organization abbrev="SIMULA">SIMULA Research
            Laboratory</organization>
          </author>

          <author initials="T." surname="Cicic">
            <organization abbrev="SIMULA">SIMULA Research
            Laboratory</organization>
          </author>

          <author initials="S." surname="Gjessing">
            <organization abbrev="SIMULA">SIMULA Research
            Laboratory</organization>
          </author>

          <author initials="A." surname="Hansen">
            <organization abbrev="SIMULA">SIMULA Research
            Laboratory</organization>
          </author>

          <date year="2006" />
        </front>

        <seriesInfo name="Infocom" value="10.1109/INFOCOM.2006.227" />
      </reference>
    </references>
  </back>
</rfc>
