One document matched: draft-bryant-shand-lf-applicability-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-bryant-shand-lf-applicability-04"
     ipr="full3978">
  <front>
    <title abbrev="Applicability of Loop-free Convergence">Applicability of
    Loop-free Convergence</title>

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

      <address>
        <postal>
          <street>250, Longwater, Green Park,</street>

          <city>Reading</city>

          <code>RG2 6GB, UK</code>

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

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

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

      <address>
        <postal>
          <street>250, Longwater, Green Park,</street>

          <city>Reading</city>

          <code>RG2 6GB, UK</code>

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

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

    <date year="2007" />

    <area>Routing Area</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>Sample</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>This draft describes the applicability of loop free convergence
      technologies to a number of network applications.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>When there is a change to the network topology (due to the failure or
      restoration of a link or router, or as a result of management action)
      the routers need to converge on a common view of the new topology, and
      the paths to be used for forwarding traffic to each destination. During
      this process, referred to as a routing transition, packet delivery
      between certain source/destination pairs may be disrupted. This occurs
      due to the time it takes for the topology change to be propagated around
      the network together with the time it takes each individual router to
      determine and then update the forwarding information base (FIB) for the
      affected destinations. During this transition, packets may be lost due
      to the continuing attempts to use the failed component, and/or due to
      forwarding loops. Forwarding loops arise due to the inconsistent FIBs
      that occur as a result of the difference in time taken by routers to
      execute the transition process. This is a problem that occurs in both IP
      networks and MPLS networks that use LDP <xref target="RFC3036"></xref>
      as the label switched path (LSP) signaling protocol.</t>

      <t>The service failures caused by routing transitions are largely hidden
      by higher-level protocols that retransmit the lost data. However new
      Internet services are emerging which are more sensitive to the packet
      disruption that occurs during a transition. To make the transition
      transparent to their users, these services require a short routing
      transition. Ideally, routing transitions would be completed in zero time
      with no packet loss.</t>

      <t>Regardless of how optimally the mechanisms involved have been
      designed and implemented, it is inevitable that a routing transition
      will take some minimum interval that is greater than zero. This has led
      to the development of a TE fast-reroute mechanism for MPLS <xref
      target="RFC4090"></xref>. Alternative mechanisms that might be deployed
      in an MPLS network and mechanisms that may be used in an IP network are
      work in progress in the IETF <xref format="default"
      target="I-D.ietf-rtgwg-ipfrr-framework"></xref> . Any repair mechanism
      may however be disrupted by the formation of micro-loops during the
      period between the time when the failure is announced, and the time when
      all FIBs have been updated to reflect the new topology.</t>

      <t>This disruptive effect of micro-loops led the IP fast re-route
      designers to develop mechanisms to control the re-convergence of
      networks in order to prevent disruption of the repair and collateral
      damage to other traffic in the network <xref format="default"
      target="I-D.bryant-shand-lf-conv-frmwk"></xref>, <xref format="default"
      target="I-D.ietf-rtgwg-microloop-analysis"></xref>.</t>

      <t>The purpose of this note is to draw the attention of the IETF
      community to the more general nature of the micro-looping problem, and
      the wider applicability of loop-free convergence technology.</t>
    </section>

    <section title="Applicability">
      <t>Loop free convergence strategies are applicable to any problem in
      which inconsistency in the FIB causes the formation of micro-loops.</t>

      <t>For example, the convergence of a network following: <list counter="">
          <t>1) Component failure.</t>

          <t>2) Component repair.</t>

          <t>3) Managing withdrawal of a component.</t>

          <t>4) Managing insertion or a component.</t>

          <t>5) Management change of link cost (either positive or
          negative).</t>

          <t>6) External cost change, for example change of external gateway
          as a result of a BGP change.</t>

          <t>7) A shared risk link group (SRLG) failure.</t>
        </list>In each case, a component may be a link or a router.</t>

      <section title="Component Failure "></section>

      <t>When fast-reroute is used to provide the temporary repair of a failed
      component, the use of a loop-free convergence mechanism enables the
      re-convergence of the network to be performed without additional packet
      loss caused by starvation or micro-looping.</t>

      <t>The need for loop-free convergence was first appreciated during the
      design of IP fast reroute. However the mechanism is also applicable to
      the case where an MPLS-TE tunnel is used to provide a link or node
      repair within an MPLS network where LDP is used to distribute
      labels.</t>

      <t>Except in special circumstances, controlled convergence in the
      presence of component failure should only be used when a temporary
      repair is available. This is because controlled convergence is always
      slower than uncontrolled (traditional) convergence, and would result in
      an extended period of traffic lost as a result of the failure if there
      were no other means of delivering the traffic.</t>

      <section title="Component Repair"></section>

      <t>Micro-loops may form when a component is (re)introduced into a
      network. All of the known loop-free convergence methods are capable of
      avoiding such micro-loops. It is not necessary to employ any repair
      mechanism to take advantage of this facility, because the new component
      may be used to provide connectivity before its presence is made known to
      the rest of the network.</t>

      <section title="Managing withdrawal of a component "></section>

      <t>From the perspective of the routing protocol, management withdrawal
      of a component is indistinguishable from an unexpected component
      failure, and will be subject to the same micro-loops. The network will
      therefore benefit from the use of a micro-loop prevention mechanism.</t>

      <t>Unlike the failure case, the component being withdrawn may be used to
      forward packets during the transition, and therefore no repair mechanism
      is needed.</t>

      <t>Unlike the case of component failure or repair, management withdrawal
      of a component is normally not time critical. Consideration may
      therefore be given to the use of the incremental cost change loop-free
      convergence mechanism. This mechanism was discarded as a candidate in
      the case of fast re-route because of its slow time to converge, however
      it is a mechanism that is backwards compatible with existing routers and
      may therefore be of use in this application. Note that unlike any of the
      other mechanism described here, this technique can be used without
      modification to ANY router in the network.</t>

      <section title="Managing Insertion of a Component"></section>

      <t>From the perspective of the routing protocol, management insertion of
      a component is indistinguishable from component repair, and will be
      subject to the same micro-loops. The network will therefore benefit from
      the use of a micro-loop prevention mechanism. No repair mechanism is
      needed and it is not normally time critical.</t>

      <section title="Managing Change of a Link Cost"></section>

      <t>Component failure and component repair are extreme examples of cost
      change. Micro-loops may also form when a link cost is changed (in either
      direction) during the process of network re-configuration. The use of a
      loop-free convergence technique prevents the formation of micro-loops
      during this otherwise benign process. No repair mechanism is needed in
      this case, because the link is still available for use.</t>

      <section title=" External Cost Change "></section>

      <t>An external cost change can result in a change to the preferred
      external route to a destination. Micro-loops may form during the process
      of switching from the old border router to the new one. The loop-free
      control of this change will prevent the loss of packets during this
      network transition.</t>

      <section title="MPLS Applicability"></section>

      <t>Where the network is an MPLS enabled network using the LDP protocol
      to learn labels, and fast re-route is provided through the use of single
      hop MPLS-TE tunnels protected by MPLS-TE fast reroute, micro loops may
      form during convergence. Loop free convergence is therefore applicable
      to this network configuration.</t>

      <section title=" Routing Vector and Path Vector Convergence"></section>

      <t>The work to date on controlled convergence has focused on link state
      IGPs. The ability to control the convergence of routing vector and path
      vector routing protocols would also be useful tools in the management of
      the Internet.</t>

      <t>Routing vector convergence may be controlled by incrementally
      changing the link cost one unit at a time and waiting for the network to
      converge. In link state routing protocols employing wide metrics such a
      solution would normally be considered as too slow to deploy, although
      recent work on optimizing the number of increments has significantly
      improved the convergence time. In the case of distance vector routing
      protocols the much smaller maximum metric makes this more tractable,
      provided that is, the per metric change convergence time is considered
      acceptable.</t>

      <t>Similarly with path vector routing protocols the path length can be
      incrementally padded. Since practical path vector routing protocols
      which use path length as an input to the routing decision are equivalent
      to using the hop count as a metric (i.e. the maximum per hop metric is
      one ,or in special cases a very small number) the number of increments
      needed is limited to the length of the path around the failure. This
      property may make this a tractable approach. <xref format="default"
      target="I-D.bryant-shand-lf-conv-frmwk"></xref> (Section 5.1), although
      the per change convergence time may still be a significant concern.</t>
    </section>

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

    <section title="Security Considerations">
      <t>All micro-loop control mechanisms raise significant security issues
      which must be addressed in their detailed technical description.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.3036'?>

      <?rfc include='reference.RFC.4090'?>

      <?rfc include='reference.I-D.ietf-rtgwg-microloop-analysis'?>

      <?rfc include='reference.I-D.bryant-shand-lf-conv-frmwk'?>

      <?rfc include='reference.I-D.ietf-rtgwg-ipfrr-framework'?>
    </references>
  </back>
</rfc>