One document matched: draft-psarkar-rtgwg-rlfa-node-protection-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-psarkar-rtgwg-rlfa-node-protection-01" ipr="trust200902">

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

  <front>
    <title>Node Protecting R-LFA and Manageability</title>

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

    <author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>Electra, Exora Business Park</street>
      <city>Bangalore</city>
      <region>KA</region>
      <code>560103</code>
      <country>India</country>
      </postal>
      <email>psarkar@juniper.net</email>
      </address>
    </author>

    <author fullname="Hannes Gredler" initials="H." surname="Gredler">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>1194 N. Mathilda Ave.</street>
      <city>Sunnyvale</city>
      <region>CA</region>
      <code>94089</code>
      <country>US</country>
      </postal>
      <email>hannes@juniper.net</email>
      </address>
    </author>

    <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>Electra, Exora Business Park</street>
      <city>Bangalore</city>
      <region>KA</region>
      <code>560103</code>
      <country>India</country>
      </postal>
      <email>shraddha@juniper.net</email>
      </address>
    </author>
    <author initials="H." surname="Raghuveer" fullname="Harish Raghuveer">
      <organization>Juniper Networks, Inc.</organization>
      <address>
      <postal>
      <street>Electra, Exora Business Park</street>
      <city>Bangalore</city>
      <region>KA</region>
      <code>560103</code>
      <country>India</country>
      </postal>
      <email>hraghuveer@juniper.net</email>
      </address>
    </author>

    <date day="8" month="July" year="2013"/>

    <area>Routing</area>

    <workgroup>Routing Area Working Group</workgroup>

    <keyword>LFA</keyword>
    <keyword>Remote-LFA</keyword>
    <keyword>IGP</keyword>
    <keyword>Node Protection</keyword>

    <abstract>
      <t>The loop-free alternates computed following the current 
      <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>
      specification gaurantees only link-protection. The resulting 
      Remote-LFA nexthops (also called PQ-nodes), may not gaurantee 
      node-protection for all destinations being protected by it.</t>

      <t>This document describes procedures for determining if a given 
      PQ-node provides node-protection for a specific destination or 
      not. The document also shows how the same procedure can be utilised 
      for collection of complete characteristics for alternate paths. 
      Knowledge about the characteristics of all alternate path is precursory  
      to apply operator defined policy for eliminating paths not fitting 
      constraints.</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>The <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>
    specification provides loop-free alternates that gaurantees only 
    link-protection. The resulting Remote-LFA alternate nexthops (also
    referred to as the PQ-nodes) may not provide node-protection for
    all destinations covered by the same, in case of failure of the 
    primary nexthop node. Neither does the specification provide a means 
    to determine the same.</t>

    <t>Also, the <xref target="I-D.ietf-rtgwg-lfa-manageability">
    LFA Manageability</xref> document, requires a computing router to 
    find all possible (including all possible Remote-LFA) alternate nexthops, 
    collect the complete set of path characteristics for each alternate path,  
    run a alternate-selection policy (configured by the operator), and find 
    the best alternate path. This will require the Remote-LFA implementation 
    to gather all the required path characteristics along each link on the 
    entire Remote-LFA alternate path.</t>

    <t>With current LFA <xref target="RFC5286"/> and Remote-LFA
    implementations, the forward SPF (and reverse SPF) is run on the 
    computing router and its immediate 1-hop routers as the roots. 
    While that enables computation of path attributes (e.g. SRLG, 
    Admin-groups) first alternate path segment from the computing router  
    PQ-node, there is no means for the computing router to gather 
    any path attributes for the path segment from the PQ-node to 
    destination. Consecutively any policy-based selection of alternate 
    paths will consider only the path attributes from the computing 
    router up until the PQ-node.</t>

    <t> This document describes a procedure for determining node-protection 
    with Remote-LFA. The same procedure are also extended for collection 
    of complete set of path attributes, enabling more accurate policy-based 
    selection for alternate paths obtained with Remote-LFA.</t>
  </section>

  <section title="Node Protection with Remote-LFA">
    <section title="The Problem">
      <t>To better illustrate the problem and the solution proposed in
      this document the following topology diagram from the
      <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>,
      draft is being re-used with slight modification.</t>

        <figure anchor="ring-topology" title="Sample Ring Topology">
	  <artwork>
                                          F
                                         /
                                    S-x-E
                                   /     \
                                  A       D--G
                                   \     /
                                    B---C
	  </artwork>
        </figure>

      <t>In the above topology, for all (non-ECMP) destinations reachable via 
      the S-E link there is no standard LFA alternate. As per the 
      <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref> alternate 
      specifications node C being the PQ-node for the S-E link provides
      nexthop for all the above destinations. <xref target="table1"/> 
      below, shows all possible primary and Remote-LFA alternate paths for each
      destination.</t>

      <texttable anchor="table1" title="Backup paths with Remote-LFA">
        <ttcol align="left">Destination</ttcol>
        <ttcol align="left">Primary Path</ttcol>
        <ttcol align="left">Remote-LFA Backup Path</ttcol>
        <c>D</c>
        <c>S->E->D</c>
        <c>S=>A=>B=>C->D</c>
        <c>E</c>
        <c>S->E</c>
        <c>S=>A=>B=>C->D->E</c>
        <c>F</c>
        <c>S->E->F</c>
        <c>S=>A=>B=>C->D->E->F</c>
        <c>G</c>
        <c>S->E->D->G</c>
        <c>S=>A=>B=>C->D->G</c>
      </texttable>

      <t>A closer look at <xref target="table1"/> shows that, while the 
      PQ-node C provides link-protection for all the destinations, it does
      not provide node-protection for destinations E and F. In the event of
      the node-failure on primary nexthop E, the alternate path from Remote-LFA
      nexthop C to E and F also becomes unavailable. So for a Remote-LFA
      nexthop to provide node-protection for a given destination, it is
      mandatory that, the shortest path from the given PQ-node to the given
      destination must not traverse the primary nexthop. </t>
    </section>

    <section title="The Solution">
      <t>This document proposes an additional forward SPF
      computation for each of the PQ-nodes,
      as a mechanism to provide node-protection with remote
      LFA. In case, a alternate selection policy has been configured, the
      mechanism proposed, shall also provide a means to collect complete
      path attributes for the alternate path via a Remote-LFA nexthop to a
      given destination.</t>

      <t>The additional forward SPF computation for each PQ-node, shall 
      help determine, if a given primary nexthop node is on shortest paths 
      from a given PQ-node to any given destination or not. To determine 
      if a given PQ-node provides node-protecting alternate for a given 
      destination, the primary nexthop node should not be on any of the 
      shortest paths from the given PQ-node to the given destination.</t>

      <t>Some SPF implementations may produce a list of links and nodes 
      traversed on the shortest path(s) from a given root to others. In such 
      implementations, running a forward SPF rooted at a given PQ-node will 
      produce a list of nodes (one per each destination), on one or more  
      shortest path(s) from the PQ-node to other destinations in the network. 
      To determine whether a PQ-node provides node-protection for a given 
      destination or not, the list of nodes computed from forward SPF run 
      on the PQ-node, for the given destination, should be inspected. In case 
      the list contains the primary nexthop node, the PQ-node does not 
      provide node-protection. Else, the PQ-node guarantees node-protecting 
      alternate for the given destination. Below is an illustration of the 
      mechanism with the topology in <xref target="ring-topology"/>.</t>

      <texttable anchor="table2" title="Types of protection with Remote-LFA">
        <ttcol align="left">Destination</ttcol>
        <ttcol align="left">PQ-node</ttcol>
        <ttcol align="left">Shortest Path(PQ-node to Dest)</ttcol>
        <ttcol align="left">Link-Protection</ttcol>
        <ttcol align="left">Node-Protection</ttcol>
        <c>D</c>
        <c>C</c>
        <c>C->D</c>
        <c>Yes</c>
        <c>Yes</c>
        <c>E</c>
        <c>C</c>
        <c>C->D->E</c>
        <c>Yes</c>
        <c>No</c>
        <c>F</c>
        <c>C</c>
        <c>C->D->E->F</c>
        <c>Yes</c>
        <c>No</c>
        <c>G</c>
        <c>C</c>
        <c>C->D->G</c>
        <c>Yes</c>
        <c>Yes</c>
      </texttable>

      <t>As seen in the above example while C is node-protecting
      Remote-LFA nexthop for D and G, it is not so for E and F, since the
      primary nexthop E is in the shortest path from C to E and F.</t>

      <t>Alternatively, an implementation may also run the node-protection 
      condition from the LFA <xref target="RFC5286"/> specification with 
      slight modification as shown in <xref target="node-prot-ineq"/> 
      below. PQ-nodes that does not qualify the condition for a given 
      destination, does not gaurantee node-protection for the same.</t>

      <figure anchor="node-prot-ineq" 
       title="Node-Protection Condition for Remote-LFA">
        <artwork>
      D_opt(Npq, Dst) < D_opt(Npq, Np) + Distance_opt(Np, Dst)

      - D_opt(X, Y) : Distance on most optimum path from X to Y.
      - Npq         : The PQ-node being considered.
      - Dst         : The destination being protected.
      - Np          : The primary nexthop node on shortest path 
                      from computing router to destination.
        </artwork>
      </figure>

      <t>All of the above metric costs except D_opt(Npq, Dst), can be obtained 
      with forward and reverse SPFs with Np(the primary nexthop) as the root, run as 
      part of the regular LFA and Remote-LFA implementation. The Distance_opt(Npq, Dst) 
      metric can only be determined by the additional forward SPF run with Npq(PQ-node) 
      as the root. With reference to the topology in <xref target="ring-topology"/>, 
      <xref target="table3"/> below shows how the above condition can be used 
      to determine node-protection with a PQ-node.</t>

      <texttable anchor="table3" 
       title="Using Node-protecting condition for Remote-LFA">
        <ttcol align="center">Destination (Dst)</ttcol>
        <ttcol align="center">Primary-NH (Np)</ttcol>
        <ttcol align="center">PQ-node (Npq)</ttcol>
        <ttcol align="center">D_opt (Npq, Dst)</ttcol>
        <ttcol align="center">D_opt (Npq, Np)</ttcol>
        <ttcol align="center">D_opt (Np, Dst)</ttcol>
        <ttcol align="center">Condition Met</ttcol>
        <c>D</c>
        <c>E</c>
        <c>C</c>
        <c>1</c>
        <c>1</c>
        <c>1</c>
        <c>Yes</c>
        <c>E</c>
        <c>E</c>
        <c>C</c>
        <c>2</c>
        <c>2</c>
        <c>0</c>
        <c>No</c>
        <c>F</c>
        <c>E</c>
        <c>C</c>
        <c>3</c>
        <c>2</c>
        <c>1</c>
        <c>No</c>
        <c>G</c>
        <c>E</c>
        <c>C</c>
        <c>2</c>
        <c>2</c>
        <c>1</c>
        <c>Yes</c>
      </texttable>

      <t>As seen in the above example above, C does not meet the node-
      protecting inequality for destination E, and F. And so, once again, 
      while C is a node-protecting Remote-LFA nexthop for D and G, 
      it is not so for E and F.</t>

      <t>The procedure described in this document helps no more than to  
      determine whether a given Remote-LFA alternate provides node-protection 
      for a given destination or not. It does not find out any new Remote-LFA 
      alternate nexthops, outside the ones already computed by standard 
      Remote-LFA procedure. However, in case of availability of more than one 
      PQ-node (Remote-LFA alternates) for a destination, and node-protection 
      is required for the given primary nexthop, this procedure will eliminate 
      the PQ-nodes that do not provide node-protection and choose only the ones  
      that does.</t> 

    </section>
  </section>

  <section title="Manageabilty of Remote-LFA Alternate Paths">
    <section title="The Problem">
      <t>With the regular Remote-LFA
      functionality the computing router may compute more than one PQ-node
      as usable Remote-LFA alternate nexthops. Additionally a alternate selection
      policy may be configured to enable the network operator to choose one
      of them as the most appropriate Remote-LFA alternate. For such policy-based 
      alternate selection to run, all the relevant path characteristics for each 
      the alternate paths (one through each of the PQ-nodes), needs to be
      collected. The Remote-LFA alternate path through a given PQ-node to a given
      destination comprises of two path segments as follows.</t>
      <t><list style="numbers">
	<t>Path segment from the computing router to the
	PQ-node (Remote-LFA alternate nexthop), and</t>
	<t>Path segment from the PQ-node to the destination
	being protected. </t>
      </list></t>

      <t>The first Path segment can be calculated from the regular
      forward SPF done as part of standard and remote LFA computations. 
      However without the mechanism proposed in this document, there is 
      no way to determine the path characteristics for the second path 
      segment. In the absence of the path characteristics for the second 
      path segment, two Remote-LFA alternate path may be equally preferred 
      based on the first path segments characteristics only, although the 
      second path segment attributes may be different.</t>
    </section>

    <section title="The Solution">
      <t>The additional forward SPF computation being proposed in this 
      document shall also collect links, nodes and path characteristics 
      along the second path segment. This shall enable collection of 
      complete path characteristics for a given Remote-LFA alternate 
      path to a given destination. The complete alternate path characteristics 
      shall then facilitate more accurate alternate path selection while 
      running the alternate selection policy.</t>
    </section>
  </section>

  <section title="Prior Solutions">
    <t>A recent <xref
    target="I-D.litkowski-rtgwg-node-protect-remote-lfa">
    Node Protecting Remote-LFA</xref> draft proposes a solution for
    providing node-protection with Remote-LFA. It requires the
    computing router to additionally run reverse SPFs rooted at the
    nextnexthop routers (i.e. all the 2-hop neighborhood) as well.
    A simple study of standard IGP network topologies in real-life
    deployments shall reveal that, the increase in the number of required
    SPF computations is exponential, and can be a substantial computation
    overhead.</t>

    <section title="Advantage of this Proposal">
      <t>Following are the advantages of the mechanism proposed in this
      document.</t>
      <t><list style="symbols"> <t>The recent Remote-LFA
      node-protection document
      <xref target="I-D.litkowski-rtgwg-node-protect-remote-lfa"/>
      proposes an extra reverse SPF computation for each nextnexthop of the 
      computing router. The mechanism in this document proposes an extra 
      forward SPF for each of the PQ-nodes. Considering some of the standard 
      IGP network topologies in real-life service-provider deployments, the 
      number of nextnexthops will be substantially higher than the number of 
      PQ-nodes discovered in those topologies. Hence the number of additional 
      SPFs required in the proposed mechanism in this document will be 
      considerably less compared to the procedures outlined in
      <xref target="I-D.litkowski-rtgwg-node-protect-remote-lfa"/>,
      and imply less computational overhead.</t>
      
      <t>Also the extra reverse SPF proposed per nextnexthop in 
      <xref target="I-D.litkowski-rtgwg-node-protect-remote-lfa"> 
      Remote-LFA node-protection</xref>  specification does not provide a means 
      to collect the path characteristics for the alternate path segment from 
      the PQ-node to the destination. The additional forward SPF for each 
      PQ-node, as proposed in this document facilitates the same.</t>
      </list></t>
    </section>
  </section>

  <section anchor="Acknowledgements" title="Acknowledgements">
    <t>Many thanks to Bruno Decraene and Stephane Litkowski for their useful comments.</t>
  </section>

  <section anchor="IANA" title="IANA Considerations">
    <t>N/A. - No protocol changes are proposed in this document.</t>
  </section>

  <section anchor="Security" title="Security Considerations">
    <t>This document does not introduce any change in any of the
    protocol specifications. It simply proposes to run an extra SPF rooted
    on each PQ-node discovered in the whole network.</t>
  </section>
  </middle>

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

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-remote-lfa-02.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-lfa-manageability-00.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-litkowski-rtgwg-node-protect-remote-lfa-00.xml"?>
    </references>
  </back>
</rfc>