One document matched: draft-psarkar-rtgwg-rlfa-node-protection-04.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-04" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Remote-LFA Node Protection 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>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<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>cbowers@juniper.net</email>
</address>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>stephane.litkowski@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<date day="08" month="April" year="2014"/>
<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) for first alternate path segment
from the computing router to the 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-1" title="Topology 1">
<artwork>
D1
/
S-x-E
/ \
N R3--D2
\ /
R1---R2
</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 R2 being the only 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="Remote-LFA backup paths via PQ-node R2">
<ttcol align="left">Destination</ttcol>
<ttcol align="left">Primary Path</ttcol>
<ttcol align="left">PQ-node</ttcol>
<ttcol align="left">Remote-LFA Backup Path</ttcol>
<c>R3</c>
<c>S->E->R3</c>
<c>R2</c>
<c>S=>N=>R1=>R2->R3</c>
<c>E</c>
<c>S->E</c>
<c>R2</c>
<c>S=>N=>R1=>R2->R3->E</c>
<c>D1</c>
<c>S->E->D1</c>
<c>R2</c>
<c>S=>N=>R1=>R2->R3->E->D1</c>
<c>D2</c>
<c>S->E->R3->D2</c>
<c>R2</c>
<c>S=>N=>R1=>R2->R3->D2</c>
</texttable>
<t>A closer look at <xref target="table1"/> shows that, while the
PQ-node R2 provides link-protection for all the destinations, it does
not provide node-protection for destinations E and D1. In the event of
the node-failure on primary nexthop E, the alternate path from Remote-LFA
nexthop R2 to E and D1 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>
<t> In another extension of the topology in <xref target="ring-topology-1"/>
let us consider an additional link between N and E.</t>
<figure anchor="ring-topology-2" title="Topology 2">
<artwork>
D1
/
S-x-E
/ / \
N---+ R3--D2
\ /
R1---R2
</artwork>
</figure>
<t> In the above topology, the S-E link is no more on any of the
shortest paths from N to R3. Hence R3 is also included in both the
Extended-P space and PQ space of E (w.r.t S-E link).
<xref target="table2"/> below, shows all possible primary and R-LFA
alternate paths via PQ-node R3, for each destination reachable
through the S-E link in the above topology. The R-LFA alternate
paths via PQ-node R2 remains same as in <xref target="table1"/>.</t>
<texttable anchor="table2" title="Remote-LFA backup paths via PQ-node R3">
<ttcol align="left">Destination</ttcol>
<ttcol align="left">Primary Path</ttcol>
<ttcol align="left">PQ-node</ttcol>
<ttcol align="left">Remote-LFA Backup Path</ttcol>
<c>R3</c>
<c>S->E->R3</c>
<c>R3</c>
<c>S=>N=>E=>R3</c>
<c>E</c>
<c>S->E</c>
<c>R3</c>
<c>S=>N=>E=>R3->E</c>
<c>D1</c>
<c>S->E->D1</c>
<c>R3</c>
<c>S=>N=>E=>R3->E->D1</c>
<c>D2</c>
<c>S->E->D1</c>
<c>R3</c>
<c>S=>N=>E=>R3->D2</c>
</texttable>
<t>Again a closer look at <xref target="table2"/> shows that, unlike
<xref target="table1"/>, where the single PQ-node R2 provided node-protection,
for destinations R3 and D1, if we choose R3 as the R-LFA nexthop, it does not
provide node-protection for R3 and D1 anymore. If S chooses R3 as the R-LFA
nexthop, in the event of the node-failure on primary nexthop E, the alternate
path from S to R-LFA nexthop R3 also becomes unavailable. So for a Remote-LFA
nexthop to provide node-protection for a given destination, it is also mandatory
that, the shortest path from S to the chosen PQ-node MUST not traverse the
primary nexthop node.</t>
</section>
<section title="Few Additional Definitions">
<t> This document adds and enhances the following definitions extending
the ones mentioned in <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA
</xref> draft.</t>
<section title="Link-Protecting Extended P-Space">
<t> The <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref> draft
already defines this. The link-protecting extended P-space for a link S-E
being protected is the set of routers that are reachable from one or more
direct neighbors of S, except primary node E, without traversing the S-E
link on any of the shortest path from the direct neighbor to the router.
This MUST exclude any direct neighbor for which there is atleast one ECMP
path from the direct neighbor traversing the link(S-E) being protected.</t>
<t> A node Y is in link-protecting extended P-space w.r.t to the link
(S-E) being protected, if and only if, there exists atleast one direct
neighbor of S, Ni, other than primary nexthop E, that satisfies the
following condition.</t>
<figure anchor="lp-extp-cond" title="Link-Protecting Ext-P-Space Condition">
<artwork>
D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)
Where,
D_opt(A,B) : Distance on most optimum path from A to B.
Ni : A direct neighbor of S other than primary
nexthop E.
Y : The node being evaluated for link-protecting
extended P-Space.
</artwork>
</figure>
</section>
<section anchor="np-extp-space" title="Node-Protecting Extended P-Space">
<t> The node-protecting extended P-space for a primary nexthop node E being
protected, is the set of routers that are reachable from one or more direct
neighbors of S, except primary node E, without traversing the node E. This
MUST exclude any direct neighbors for which there is atleast one ECMP path
from the direct neighbor traversing the node E being protected.</t>
<t> A node Y is in node-protecting extended P-space w.r.t to the node
E being protected, if and only if, there exists atleast one direct neighbor
of S, Ni, other than primary nexthop E, that satisfies the following
condition.</t>
<figure anchor="np-extp-cond" title="Node-Protecting Ext-P-Space Condition">
<artwork>
D_opt(Ni,Y) < D_opt(Ni,E) + D_opt(E,Y)
Where,
D_opt(A,B) : Distance on most optimum path from A to B.
E : The primary nexthop on shortest path from S
to destination.
Ni : A direct neighbor of S other than primary
nexthop E.
Y : The node being evaluated for node-protecting
extended P-Space.
</artwork>
</figure>
<t> It must be noted that a node Y satisfying the condition in
<xref target="np-extp-cond"/> above only guarantees that the R-LFA alternate
path segment from S via direct neighbor Ni to the node Y is not affected
in the event of a node failure of E. It does not yet guarantee that the path
segment from node Y to the destination is also unaffected by the same
failure event.</t>
</section>
<section title="Q-Space">
<t> The <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref> draft
already defines this. The Q-space for a link S-E being protected is the
set of routers that can reach primary node E, without traversing the S-E
link on any of the shortest path from the node Y to primary nexthop E.
This MUST exclude any destination for which there is atleast one ECMP
path from the node Y to the primary nexthop E traversing the link(S-E)
being protected.</t>
<t> A node Y is in Q-space w.r.t to the link (S-E) being protected,
if and only if, the following condition is satisfied.</t>
<figure anchor="q-cond" title="Q-Space Condition">
<artwork>
D_opt(Y,E) < D_opt(S,E) + D_opt(Y,S)
Where,
D_opt(A,B) : Distance on most optimum path from A to B.
E : The primary nexthop on shortest path from S
to destination.
Y : The node being evaluated for Q-Space.
</artwork>
</figure>
</section>
<section title="Link-Protecting PQ Space">
<t> A node Y is in link-protecting PQ space w.r.t to the link (S-E) being
protected, if and only if, Y is present in both link-protecting extended
P-space and the Q-space for the link being protected.</t>
</section>
<section title="Candidate Node-Protecting PQ Space">
<t> A node Y is in candidate node-protecting PQ space w.r.t to the node (E)
being protected, if and only if, Y is present in both node-protecting extended
P-space and the Q-space for the link being protected.</t>
<t> Again it must be noted that a node Y being in candidate node-protecting
PQ-space does not guarantee that the R-LFA alternate path via the same, in
entirety, is unaffected in the event of a node failure of primary nexthop node
E. It only guarantees that the path segment from S to PQ-node Y is unaffected
by the same failure event. The PQ-nodes in the candidate node-protecting
PQ space may provide node protection for only a subset of destinations
that are reachable through the corresponding primary link.</t>
</section>
</section>
<section anchor="node-protecting-rlfa"
title="Computing Node-protecting R-LFA Path">
<t> The R-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> So to ensure a R-LFA alternate path for a given destination provides
node-protection we need to ensure that none of the above path segments are
unaffected in the event of failure of the primary nexthop node. Sections
<xref target="plr-to-pq"/> and <xref target="pqnode-to-dest"/> shows
how this can be ensured.</t>
<section anchor="plr-to-pq"
title="Computing Candidate Node-protecting PQ-Nodes for Primary nexthops">
<t> To choose a node-protecting R-LFA nexthop for a destination R3, router S
needs to consider a PQ-node from the candidate node-protecting PQ-space for
the primary nexthop E on shortest path from S to R3. As mentioned in
<xref target="np-extp-space"/>, to consider a PQ-node as candidate node-protecting
PQ-node, there must be atleast one direct neighbor Ni of S, such that all
shortest paths from Ni to the PQ-node does not traverse primary nexthop
node E.</t>
<t> Implementations should run the inequality in <xref target="np-extp-space"/>
<xref target="np-extp-cond"/> for all direct neighbor, other than primary nexthop
node E, to determine whether a node Y is a candidate node-protecting PQ-node.
All of the metrics needed by this inequality would have been already collected
from the forward SPFs rooted at each of direct neighbor S, computed as part of
standard LFA <xref target="RFC5286"/> implementation. With reference to the
topology in <xref target="ring-topology-2"/>, <xref target="table3"/> below
shows how the above condition can be used to determine the candidate node-protecting
PQ-space for S-E link (primary nexthop E)</t>
<texttable anchor="table3"
title="Node-protection evaluation for R-LFA repair tunnel to PQ-node">
<ttcol align="center">Candidate PQ-node (Y)</ttcol>
<ttcol align="center">Direct Nbr (Ni)</ttcol>
<ttcol align="center">D_opt (Ni,Y)</ttcol>
<ttcol align="center">D_opt (Ni,E)</ttcol>
<ttcol align="center">D_opt (E,Y)</ttcol>
<ttcol align="center">Condition Met</ttcol>
<c>R2</c>
<c>N</c>
<c>2 (N,R2)</c>
<c>1 (N,E)</c>
<c>2 (E,R2)</c>
<c>Yes</c>
<c>R3</c>
<c>N</c>
<c>2 (N,R3)</c>
<c>1 (N,E)</c>
<c>1 (E,R3)</c>
<c>No</c>
</texttable>
<t>As seen in the above <xref target="table3"/> , R3 does not meet the
node-protecting extended-p-space inequality And so, while R2 is in candidate
node-protecting PQ space, R3 is not.</t>
<t>Some SPF implementations may also produce a list of links and nodes traversed
on the shortest path(s) from a given root to others. In such implementations,
router S may have executed a forward SPF with each of it's direct neighbors as
the SPF root, executed as part of the standard LFA <xref target="RFC5286"/>
computations. So S may re-use the list of links and nodes collected from the same
SPF computations, to decide whether a node Y is a candidate node-protecting PQ-node or
not. A node Y shall be considered as a node-protecting PQ-node, if and only if,
there is atleast one direct neighbor of S, other than the primary nexthop
E, for which, the primary nexthop node E does not exist on the list of nodes
traversed on any of the shortest path(s) from the direct neighbor to the
PQ-node. <xref target="table4"/> below is an illustration of the mechanism with
the topology in <xref target="ring-topology-2"/>.</t>
<texttable anchor="table4" title="Protection of Remote-LFA tunnel to the PQ-node">
<ttcol align="left">Candidate PQ-node</ttcol>
<ttcol align="left">Repair Tunnel Path(Repairing router to PQ-node)</ttcol>
<ttcol align="left">Link-Protection</ttcol>
<ttcol align="left">Node-Protection</ttcol>
<c>R2</c>
<c>S->N->R1->R2</c>
<c>Yes</c>
<c>Yes</c>
<c>R2</c>
<c>S->E->R3->R2</c>
<c>No</c>
<c>No</c>
<c>R3</c>
<c>S->N->E->R3</c>
<c>Yes</c>
<c>No</c>
</texttable>
<t>As seen in the above <xref target="table4"/> while R2 is candidate node-protecting
Remote-LFA nexthop for R3 and D2, it is not so for E and D1, since the
primary nexthop E is in the shortest path from R2 to E and F.</t>
</section>
<section anchor="pqnode-to-dest"
title="Computing node-protecting paths from PQ-nodes to destinations">
<t> Once a computing router finds all the candidate node-protecting PQ-nodes for a
given directly attached primary link, it shall follow the procedure in proposed
in this section, to choose one or more node-protecting R-LFA paths, for
destinations reachable through the same primary link in the primary SPF graph.</t>
<t> To find a node-protecting R-LFA path for a given destination, the computing
router needs to pick a subset of PQ-nodes from the candidate node-protecting PQ-space for
the corresponding primary nexthop, such that all the path(s) from the PQ-node(s)
to the given destination remain unaffected in the event of a node failure of
primary nexthop node. To ensure this, the computing router will need to ensure
that, the primary nexthop node should not be on any of the shortest paths
from the PQ-node to the given destination.</t>
<t> This document proposes an additional forward SPF computation for each of
the PQ-nodes, to discover all shortest paths from the PQ-nodes to the destination.
The additional forward SPF computation for each PQ-node, shall help determine,
if a given primary nexthop node is on the shortest paths from the PQ-node to
the given destination or not. To determine if a given candidate node-protecting 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 PQ-node to the given
destination. On running the forward SPF on a candidate node-protecting PQ-node
the computing router shall run the inequality in <xref target="node-prot-ineq-2"/>
below. PQ-nodes that does not qualify the condition for a given destination, does
not gaurantee node-protection for the path segment from the PQ-node to the
given destination.</t>
<figure anchor="node-prot-ineq-2"
title="Node-Protecting Condition for PQ-node to Destination">
<artwork>
D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D)
Where,
D_opt(A,B) : Distance on most optimum path from A to B.
D : The destination node.
E : The primary nexthop on shortest path from S
to destination.
Y : The node-protecting PQ-node being evaluated
</artwork>
</figure>
<t>All of the above metric costs except D_opt(Y, D), can be obtained with
forward and reverse SPFs with E(the primary nexthop) as the root, run as
part of the regular LFA and Remote-LFA implementation. The Distance_opt(Y, D)
metric can only be determined by the additional forward SPF run with PQ-node
Y as the root. With reference to the topology in <xref target="ring-topology-2"/>,
<xref target="table5"/> below shows how the above condition can be used
to determine node-protection with node-protecting PQ-node R2.</t>
<texttable anchor="table5"
title="Node-protection evaluation for R-LFA path segment between PQ-node
and destination">
<ttcol align="center">Destination (D)</ttcol>
<ttcol align="center">Primary-NH (E)</ttcol>
<ttcol align="center">D_opt (Y, D)</ttcol>
<ttcol align="center">D_opt (Y, E)</ttcol>
<ttcol align="center">D_opt (E, D)</ttcol>
<ttcol align="center">Condition Met</ttcol>
<c>R3</c>
<c>E</c>
<c>1 (R2,R3)</c>
<c>2 (R2,E)</c>
<c>1 (E,R3)</c>
<c>Yes</c>
<c>E</c>
<c>E</c>
<c>2 (R2,E)</c>
<c>2 (R2,E)</c>
<c>0 (E,E)</c>
<c>No</c>
<c>D1</c>
<c>E</c>
<c>3 (R2,D1)</c>
<c>2 (R2,E)</c>
<c>1 (E,D1)</c>
<c>No</c>
<c>D2</c>
<c>E</c>
<c>2 (R2,D2)</c>
<c>2 (R2,E)</c>
<c>1 (E,D2)</c>
<c>Yes</c>
</texttable>
<t>As seen in the above example above, R2 does not meet the node-
protecting inequality for destination E, and F. And so, once again,
while R2 is a node-protecting Remote-LFA nexthop for R3 and G,
it is not so for E and F.</t>
<t>In SPF implementations that also produce a list of links and nodes
traversed on the shortest path(s) from a given root to others,
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 candidate node-protecting PQ-node R2 in the topology in
<xref target="ring-topology-2"/>.</t>
<texttable anchor="table6"
title="Protection of Remote-LFA path between PQ-node and destination">
<ttcol align="left">Destination</ttcol>
<ttcol align="left">Shortest Path (Repairing router to PQ-node)</ttcol>
<ttcol align="left">Link-Protection</ttcol>
<ttcol align="left">Node-Protection</ttcol>
<c>R3</c>
<c>R2->R3</c>
<c>Yes</c>
<c>Yes</c>
<c>E</c>
<c>R2->R3->E</c>
<c>Yes</c>
<c>No</c>
<c>D1</c>
<c>R2->R3->E->D1</c>
<c>Yes</c>
<c>No</c>
<c>D2</c>
<c>R2->R3->D2</c>
<c>Yes</c>
<c>Yes</c>
</texttable>
<t>As seen in the above example while R2 is candidate node-protecting
R-LFA nexthop for R3 and G, it is not so for E and F, since the
primary nexthop E is in the shortest path from R2 to 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 title="Limiting extra computational overhead">
<t> In addition to the extra reverse SPF computation, one per directly
connected neighbor, suggested by the <xref target="I-D.ietf-rtgwg-remote-lfa">
Remote-LFA</xref> draft, this document proposes a forward SPF per PQ-node
discovered in the network. Since the average number of PQ-nodes found in
any network is considerably more than the number of direct neighbors of the
computing router, the proposal of running one forward SPF per PQ-node may
add considerably to the overall SPF computation time.</t>
<t> To limit the computational overhead of the approach proposed, this
document proposes that implementations MUST choose a subset from the entire
set of PQ-nodes computed in the network, with a finite limit on the number
of PQ-nodes in the subset. Implementations MUST choose a default value
for this limit and may provide user with a configuration knob to override
the default limit. Implementations MUST also evaluate some default
preference criteria while considering a PQ-node in this subset. Finally,
implementations MAY also allow user to override the default preference
criteria, by providing a policy configuration for the same.</t>
<t> A suggested default criteria for PQ-node selection will be to put a score
on each PQ-node, proportional to the number of primary interfaces and remote
destination routers being protected by it, and then pick PQ-nodes based on
this score. A more appropriate heuristsics can be devised, based on
in-depth study of coverage provided by R-LFA, in the networks where they
are mostly deployed. The same can then be used for PQ-node selection.</t>
<t> Once a subset of PQ-nodes is found, computing router shall run a forward
SPF on each of the PQ-nodes in the subset to continue with procedures proposed
in section <xref target="pqnode-to-dest"/>.</t>
</section>
</section>
</section>
<section title="Manageabilty of Remote-LFA Alternate Paths">
<section title="The Problem">
<t>With the regular <xref target="I-D.ietf-rtgwg-remote-lfa">Remote-LFA</xref>
functionality the computing router may compute more than one PQ-node
as usable Remote-LFA alternate nexthops. Additionally an 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. As mentioned befor in section <xref target="node-protecting-rlfa"/>
the R-LFA alternate path through a given PQ-node to a given destination
comprises of two path segments.</t>
<t>The first path segment (i.e. from the computing router to the PQ-node)
can be calculated from the regular forward SPF done as part of standard and
remote LFA computations. However without the mechanism proposed in section
<xref target="pqnode-to-dest"/> of this document, there is no way to
determine the path characteristics for the second path segment (i.e from the
PQ-node to the destination). 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 proposed in section
<xref target="pqnode-to-dest"/> 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 anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Bruno Decraene for his 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"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:47 |