<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC3906 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3906.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
<!ENTITY REMOTE-LFA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-remote-lfa.xml">
<!ENTITY LFA-TE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.litkowski-rtgwg-lfa-rsvpte-cooperation.xml">
<!ENTITY LFA-APPLICABILITY SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6571.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?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="3"?>
<!-- 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 popular PIs -->
<rfc category="std" docName="draft-litkowski-rtgwg-node-protect-remote-lfa-00"
     ipr="trust200902">
  <front>
    <title abbrev="Node protecting remote LFA">Node protecting remote LFA</title>

    <author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
      <organization>Orange</organization>

      <address>
        <!-- postal><street/><city/><region/><code/><country/></postal -->

        <!-- <phone/> -->

        <!-- <facsimile/> -->

        <email>stephane.litkowski@orange.com</email>

        <!-- <uri/> -->
      </address>
    </author>

   
    <date year="2013"/>

    <area/>

    <workgroup>Routing Area Working Group</workgroup>

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <!-- <keyword/> -->

    <abstract>
      <t>This draft describes a simple extension to the remote LFA specification that computes a guaranteed node protection.</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"/>.</t>
  </note>
  
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
	  The current RLFA specification described in <xref target="I-D.ietf-rtgwg-remote-lfa"/> is based on a per link computation (for optimization) 
	  that prevents determination of guaranteed node protection. This does not mean that the current solution is not able to provide node protection for
	  a specific destination, but as computation is done from the link perspective, there is no guarantee to have node protection.
	  
      </t>
	  <figure>
	  <artwork>
             S---E
            /     \
           A       D
            \     /
             B---C
			
			Figure 1
	  </artwork>
	  </figure>
	  <t>In the figure above, considering all metrics equal, primary path from S to D is SED. S has no LFA to reach D. 
	  </t>
	  <t>Using RLFA specification, C is a PQ from E perspective and could be used as a remote LFA in case of SE failure.
	  In the diagram above, C is a considered as a link protecting alternate (as from E perspective, it is only link protecting), even if 
	  from a topological point of view, C would be a node protecting RLFA.
	  </t>
	  <t>There could be multiple reasons to ensure node protection in a network : 
	  <list style="symbols">
	  <t>Presence of nodes with no high availability mechanism.</t>
	  <t>Avoiding transient loops in case of node crash.</t>
	  </list>
	  </t>
	  <t>This draft describes a solution to compute a guaranteed node protection using remote LFA solution.</t>
    </section>

	<section anchor="spec" title="Specification">
	<section title="Reference topology">
	<figure>
	<artwork>

        3	
 N1 ---------- P1
 |             |
 |       2     |
 |  N3 --- P3  |
 |/       /    |
 S ---- E ---- R1 --- D1 --- D2
 |       \                   |
 |         R2 ----- D3-------+
 |         /               2
 N2 ---- P2
     3
	 
        Figure 2
		
	</artwork>
	</figure>
	</section>
	<section title="Current RLFA behavior">
	<t>
	The current remote LFA computation is based on computation of extended P-Space and Q-Space and then intersect both to determine PQ nodes that would be used for traffic tunneling.
	As Q-Space requires rSPF computation (one per Q-Space), it would not be scalable to compute Q-Space for each prefix. RLFA specification is proposing to compute Q Space on a per link basis, PQ will so be used by all prefixes using the link as primary nexthop.	
	</t>
	<t>
	Using figure 2 and considering protection of prefixes using E as primary nexthop on S, there would be three nodes in PQ space : P1,P2,P3. Using shortest path to PQ as tie breaker, P3 would be the best PQ.
	</t>
	<t>
	P3 is only providing link protection to D1, D2 and D3 while P1 was providing node protection for D1 and D2, and P2 was providing node protection for D3.
	</t>
	<t>In this scenario, RLFA is providing a suboptimal protection because of the approximation of using remote end of the link for computation.</t>
	</section>
	
	<section title="Guaranteed node protection computation">
	<t>
	To compute a guaranteed node protection using remote LFA, we just introduce a small modification in the current algorithm. Rather than computing link protecting PQs from nexthop perspective, we propose to compute node protecting PQs from nextnexthop perspective.
	</t>
	<t>
	Our proposal is working as follows :
	<list style="symbols">
	<t>Compute node protecting PQ space for each nextnexthop.</t>
	<t>Compute link protecting PQ space for each nexthop (as already done).</t>
	<t>Prefixes are inheriting protection type from nexthop or nextnexthop based on defined policies. Choosing a PQ in node protecting space provides guaranteed node protection.</t>
	</list>
	</t>
		<section title="Computing node protecting extended P-Space">
		<t>
		We define the notion of node protecting extended P-Space of a node S for a connected node E as the union of :
		<list style="symbols">
		<t>Node protecting P-Space : the set of routers reachable from S without traversing node E.</t>
		<t>The set of destinations using E as primary nexthop but having a node protecting LFA.</t>
		</list>
		</t>
		</section>
		<section title="Computing node protecting Q-Space">
		<t>
		The set of routers from which a node N can be reached, by normal
   forwarding, without traversing the node E is termed the node protecting Q-space of
   N with respect to the node E.  The Q-space can be obtained by
   computing a reverse shortest path tree (rSPT) rooted at N, with the
   sub-tree which traverses the failed node excised (including those
   which are members of an ECMP).  
		</t>
		</section>
		<section title="Computing node protecting PQ-Spaces">
		<t>
		Upon termination of regular SPT, node S has knowledge of nexthops and nextnexthops to reach every destinations.
		For each nextnexthop on the SPT, S will compute :
		<list style="symbols">
		<t>Node protecting extended P-Space considering nexthop will fail.</t>
		<t>Node protecting extended Q-Space from nextnexthop considering nexthop will fail.</t>
		</list>
		Intersection of both will result in node protecting PQ-Spaces and node S will have a node protecting PQ-Space for each nextnexthop.
		</t>
		<t>
		In figure 2, considering link SE, S has two nextnexthops (R1 and R2). S will compute node protecting PQ Space for R1 and for R2.
		</t>
		<t>Node protecting extended P-Space :
		<list style="symbols">
		<t>For R1 : P1,N1</t>
		<t>For R2 : P2,N2</t>
		</list>
		</t>
		<t>Node protecting Q-Space :
		<list style="symbols">
		<t>For R1 : P1,D1,D2</t>
		<t>For R2 : P2,D3,D2</t>
		</list>
		</t>
		<t>Node protecting PQ-Space :
		<list style="symbols">
		<t>For R1 : P1</t>
		<t>For R2 : P2</t>
		</list>
		</t>
		<t>
		As a result, P1 is able to provide node protection for all destinations using R1 as nextnexthop (D1,D2). P2 is able to provide node protection for all destinations using R2 as nextnexthop (D3).
		</t>
		</section>
	</section>
	</section>
	
	
	<section anchor="Scaling" title="Scaling">
      <t>Approximation introduced in remote LFA specification was done to optimize computation. Our proposal is introducing more computation but in a very acceptable degree. Computation time will be dependent on number of nextnexthops rather than nexthops.</t>
	  <texttable anchor="simu-result-topology" title="Number of nextnexthop">
	  	<ttcol align="center">Topology</ttcol>
		<ttcol align="center">Min</ttcol>
		<ttcol align="center">Average</ttcol>
		<ttcol align="center">Med</ttcol>
		<ttcol align="center">95th perc</ttcol>
		<ttcol align="center">Max</ttcol>
		<c>T1</c><c>1</c><c>20,4</c><c>19</c><c>39</c><c>107</c>
		<c>T2</c><c>1</c><c>9,5</c><c>6</c><c>27</c><c>35</c>
		<c>T3</c><c>2</c><c>15,7</c><c>11</c><c>41</c><c>53</c>
		<c>T4</c><c>1</c><c>13,9</c><c>15</c><c>26,5</c><c>30</c>
		<c>T5</c><c>1</c><c>12</c><c>8</c><c>36</c><c>72</c>
		<c>T6</c><c>2</c><c>4,3</c><c>4</c><c>7</c><c>8</c>
		<c>T7</c><c>1</c><c>9</c><c>6</c><c>19</c><c>22</c>
	  </texttable>
	  <t>The simulation results above (from real SP topologies) show that the number of rSPF to compute is really acceptable : SPF takes today only few msec to compute even on large topologies. Moreover installing protection is not an urgent task, and it would be better to take more time to compute a more optimal protection.</t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any change in security consideration
      compared to <xref target="RFC5286"/> or <xref target="I-D.ietf-rtgwg-remote-lfa"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements"/>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no action for IANA.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
	  &REMOTE-LFA;
      &RFC5286;  
    </references>

  </back>
</rfc>
