 1/draftietfrtgwgrlfanodeprotection02.txt 20151006 09:16:56.653691538 0700
+++ 2/draftietfrtgwgrlfanodeprotection03.txt 20151006 09:16:56.717693097 0700
@@ 1,31 +1,30 @@
Routing Area Working Group P. Sarkar, Ed.
InternetDraft H. Gredler
Intended status: Standards Track S. Hegde
Expires: December 17, 2015 C. Bowers
 Juniper Networks, Inc.
+InternetDraft S. Hegde
+Intended status: Standards Track C. Bowers
+Expires: April 8, 2016 Juniper Networks, Inc.
+ H. Gredler
+ Unaffiliated
S. Litkowski
Orange
 H. Raghuveer
 June 15, 2015
+ October 6, 2015
RemoteLFA Node Protection and Manageability
 draftietfrtgwgrlfanodeprotection02
+ draftietfrtgwgrlfanodeprotection03
Abstract
The loopfree alternates computed following the current RemoteLFA
 [ID.ietfrtgwgremotelfa] specification gaurantees only link
 protection. The resulting RemoteLFA nexthops (also called PQ
 nodes), may not gaurantee nodeprotection for all destinations being
 protected by it.
+ [RFC7490] specification guarantees only linkprotection. The
+ resulting RemoteLFA nexthops (also called PQnodes), may not
+ guarantee nodeprotection for all destinations being protected by it.
This document describes procedures for determining if a given PQnode
provides nodeprotection 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.
Requirements Language
@@ 42,21 +41,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on December 17, 2015.
+ This InternetDraft will expire on April 8, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 65,21 +64,21 @@
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Node Protection with RemoteLFA . . . . . . . . . . . . . . . 3
2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Few Additional Definitions . . . . . . . . . . . . . . . 5
 2.2.1. LinkProtecting Extended PSpace . . . . . . . . . . 5
+ 2.2.1. LinkProtecting Extended PSpace . . . . . . . . . . 6
2.2.2. NodeProtecting Extended PSpace . . . . . . . . . . 6
2.2.3. QSpace . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. LinkProtecting PQ Space . . . . . . . . . . . . . . 8
2.2.5. Candidate NodeProtecting PQ Space . . . . . . . . . 8
2.3. Computing Nodeprotecting RLFA Path . . . . . . . . . . 8
2.3.1. Computing Candidate Nodeprotecting PQNodes for
Primary nexthops . . . . . . . . . . . . . . . . . . 8
2.3.2. Computing nodeprotecting paths from PQnodes to
destinations . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Limiting extra computational overhead . . . . . . . . 12
@@ 89,89 +88,88 @@
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
 The RemoteLFA [ID.ietfrtgwgremotelfa] specification provides
 loopfree alternates that gaurantees only linkprotection. The
 resulting RemoteLFA alternate nexthops (also referred to as the PQ
 nodes) may not provide nodeprotection 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.
+ The RemoteLFA [RFC7490] specification provides loopfree alternates
+ that guarantees only linkprotection. The resulting RemoteLFA
+ alternate nexthops (also referred to as the PQnodes) may not provide
+ nodeprotection 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.
Also, the LFA Manageability [ID.ietfrtgwglfamanageability]
document, requires a computing router to find all possible (including
all possible RemoteLFA) 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 RemoteLFA implementation to
gather all the required path characteristics along each link on the
entire RemoteLFA alternate path.
With current LFA [RFC5286] and RemoteLFA implementations, the
forward SPF (and reverse SPF) is run on the computing router and its
immediate 1hop routers as the roots. While that enables computation
of path attributes (e.g. SRLG, Admingroups) for first alternate
path segment from the computing router to the PQnode, there is no
means for the computing router to gather any path attributes for the
 path segment from the PQnode to destination. Consecutively any
+ path segment from the PQnode to destination. Consequently any
policybased selection of alternate paths will consider only the path
attributes from the computing router up until the PQnode.
This document describes a procedure for determining nodeprotection
with RemoteLFA. The same procedure are also extended for collection
 of complete set of path attributes, enabling more accurate policy
+ of a complete set of path attributes, enabling more accurate policy
based selection for alternate paths obtained with RemoteLFA.
2. Node Protection with RemoteLFA
Nodeprotection is required to provide protection of traffic on a
given forwarding node, against the failure of the firsthop node on
the primary forwarding path. Such protection becomes more critical
in the absence of mechanisms like nonstoprouting in the network.
 Certain operators refrains from deploying nonstoprouting in their
+ Certain operators refrain from deploying nonstoprouting in their
network, due to the significant additional performance complexities
 it comes along with. In such cases nodeprotection is a must to
 gaurantee uninterrupted flow of traffic, even in the case of an
+ it introduces. In such cases nodeprotection is a essential to
+ guarantee uninterrupted flow of traffic, even in the case of an
entire forwarding node going down.
 The following sections discusses the nodeprotection problem in the
 context of RemoteLFA and proposes a solution for solving the same.
+ The following sections discuss the nodeprotection problem in the
+ context of RemoteLFA and propose a solution.
2.1. The Problem
To better illustrate the problem and the solution proposed in this
 document the following topology diagram from the RemoteLFA
 [ID.ietfrtgwgremotelfa] draft is being reused with slight
 modification.
+ document the following topology diagram from the RemoteLFA [RFC7490]
+ draft is being reused with slight modification.
D1
/
SxE
/ \
N R3D2
\ /
R1R2
Figure 1: Topology 1
In the above topology, for all (nonECMP) destinations reachable via
the SE link there is no standard LFA alternate. As per the Remote
 LFA [ID.ietfrtgwgremotelfa] alternate specifications node R2
 being the only PQnode for the SE link provides nexthop for all the
 above destinations. Table 1 below, shows all possible primary and
 RemoteLFA alternate paths for each destination.
+ LFA [RFC7490] alternate specifications node R2 being the only PQnode
+ for the SE link provides nexthop for all the above destinations.
+ Table 1 below, shows all possible primary and RemoteLFA alternate
+ paths for each destination.
+++++
 Destination  Primary Path  PQnode  RemoteLFA Backup Path 
+++++
 R3  S>E>R3  R2  S=>N=>R1=>R2>R3 
 E  S>E  R2  S=>N=>R1=>R2>R3>E 
 D1  S>E>D1  R2  S=>N=>R1=>R2>R3>E>D1 
 D2  S>E>R3>D2  R2  S=>N=>R1=>R2>R3>D2 
+++++
@@ 180,75 +178,77 @@
A closer look at Table 1 shows that, while the PQnode R2 provides
linkprotection 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 RemoteLFA
nexthop R2 to E and D1 also becomes unavailable. So for a RemoteLFA
nexthop to provide nodeprotection for a given destination, it is
mandatory that, the shortest path from the given PQnode to the given
destination MUST not traverse the primary nexthop.
In another extension of the topology in Figure 1 let us consider an
 additional link between N and E.
+ additional link between N and E with the same cost as the other
+ links.
D1
/
SxE
/ / \
N+ R3D2
\ /
R1R2
Figure 2: Topology 2
In the above topology, the SE link is no more on any of the shortest
 paths from N to R3. Hence R3 is also included in both the ExtendedP
 space and PQ space of E (w.r.t SE link). Table 2 below, shows all
 possible primary and RLFA alternate paths via PQnode R3, for each
 destination reachable through the SE link in the above topology.
 The RLFA alternate paths via PQnode R2 remains same as in Table 1.
+ paths from N to R3, E and D1. Hence R3, E and D1 are also included
+ in both the ExtendedP space and Q space of E (w.r.t SE link).
+ Table 2 below, shows all possible primary and RLFA alternate paths
+ via PQnode R3, for each destination reachable through the SE link
+ in the above topology. The RLFA alternate paths via PQnode R2
+ remains same as in Table 1.
+++++
 Destination  Primary Path  PQnode  RemoteLFA Backup Path 
+++++
 R3  S>E>R3  R3  S=>N=>E=>R3 
 E  S>E  R3  S=>N=>E=>R3>E 
 D1  S>E>D1  R3  S=>N=>E=>R3>E>D1 
 D2  S>E>R3>D2  R3  S=>N=>E=>R3>D2 
+++++
Table 2: RemoteLFA backup paths via PQnode R3
Again a closer look at Table 2 shows that, unlike Table 1, where the
 single PQnode R2 provided nodeprotection, for destinations R3 and
 D1, if we choose R3 as the RLFA nexthop, it does not provide node
 protection for R3 and D1 anymore. If S chooses R3 as the RLFA
 nexthop, in the event of the nodefailure on primary nexthop E, the
 alternate path from S to RLFA nexthop R3 also becomes unavailable.
 So for a RemoteLFA nexthop to provide nodeprotection for a given
 destination, it is also mandatory that, the shortest path from S to
 the chosen PQnode MUST not traverse the primary nexthop node.
+ single PQnode R2 provided nodeprotection for destinations R3 and
+ D2, if we choose R3 as the RLFA nexthop, it does not provide node
+ protection for R3 and D2 anymore. If S chooses R3 as the RLFA
+ nexthop, in the event of the nodefailure on primary nexthop E, on
+ the alternate path from S to RLFA nexthop R3, one of parallel ECMP
+ path between N and R3 also becomes unavailable. So for a RemoteLFA
+ nexthop to provide nodeprotection for a given destination, it is
+ also mandatory that, the shortest path from S to the chosen PQnode
+ MUST not traverse the primary nexthop node.
2.2. Few Additional Definitions
This document adds and enhances the following definitions extending
 the ones mentioned in RemoteLFA [ID.ietfrtgwgremotelfa] draft.
+ the ones mentioned in RemoteLFA [RFC7490] draft.
2.2.1. LinkProtecting Extended PSpace
 The RemoteLFA [ID.ietfrtgwgremotelfa] draft already defines
 this. The linkprotecting extended Pspace for a link SE 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
 SE 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(SE) being protected.
+ The RemoteLFA [RFC7490] draft already defines this. The link
+ protecting extended Pspace for a link SE 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 SE link on any of the
+ shortest path from the direct neighbor to the router. This MUST
+ exclude any direct neighbor for which there is at least one ECMP path
+ from the direct neighbor traversing the link(SE) being protected.
A node Y is in linkprotecting extended Pspace w.r.t to the link
(SE) 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.
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.
@@ 258,22 +258,22 @@
extended PSpace.
Figure 3: LinkProtecting ExtPSpace Condition
2.2.2. NodeProtecting Extended PSpace
The nodeprotecting extended Pspace 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.
+ is at least one ECMP path from the direct neighbor traversing the
+ node E being protected.
A node Y is in nodeprotecting extended Pspace 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.
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.
@@ 288,27 +288,27 @@
It must be noted that a node Y satisfying the condition in Figure 4
above only guarantees that the RLFA 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.
2.2.3. QSpace
 The RemoteLFA [ID.ietfrtgwgremotelfa] draft already defines
 this. The Qspace for a link SE being protected is the set of
 routers that can reach primary node E, without traversing the SE
 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(SE) being protected.
+ The RemoteLFA [RFC7490] draft already defines this. The Qspace for
+ a link SE being protected is the set of routers that can reach
+ primary node E, without traversing the SE link on any of the
+ shortest path from the node Y to primary nexthop E. This MUST
+ exclude any destination for which there is at least one ECMP path
+ from the node Y to the primary nexthop E traversing the link(SE)
+ being protected.
A node Y is in Qspace w.r.t to the link (SE) being protected, if
and only if, the following condition is satisfied.
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.
@@ 334,32 +334,32 @@
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 PQnode Y is unaffected by the same failure event.
The PQnodes in the candidate nodeprotecting PQ space may provide
node protection for only a subset of destinations that are reachable
through the corresponding primary link.
2.3. Computing Nodeprotecting RLFA Path
The RLFA alternate path through a given PQnode to a given
 destination comprises of two path segments as follows.
+ destination is comprised of two path segments as follows.
1. Path segment from the computing router to the PQnode (RemoteLFA
alternate nexthop), and
2. Path segment from the PQnode to the destination being protected.
So to ensure a RLFA alternate path for a given destination provides
nodeprotection we need to ensure that none of the above path
 segments are unaffected in the event of failure of the primary
 nexthop node. Sections Section 2.3.1 and Section 2.3.2 shows how
 this can be ensured.
+ segments are affected in the event of failure of the primary nexthop
+ node. Sections Section 2.3.1 and Section 2.3.2 shows how this can be
+ ensured.
2.3.1. Computing Candidate Nodeprotecting PQNodes for Primary
nexthops
To choose a nodeprotecting RLFA nexthop for a destination R3,
router S needs to consider a PQnode from the candidate node
protecting PQspace for the primary nexthop E on shortest path from S
to R3. As mentioned in Section 2.2.2, to consider a PQnode as
candidate nodeprotecting PQnode, there must be atleast one direct
neighbor Ni of S, such that all shortest paths from Ni to the PQnode
@@ 383,83 +383,83 @@
 R2  N  2 (N,R2)  1 (N,E)  2  Yes 
     (E,R2)  
 R3  N  2 (N,R3)  1 (N,E)  1  No 
     (E,R3)  
+++++++
Table 3: Nodeprotection evaluation for RLFA repair tunnel to PQ
node
As seen in the above Table 3 , R3 does not meet the nodeprotecting
 extendedpspace inequality And so, while R2 is in candidate node
+ extendedpspace inequality and so, while R2 is in candidate node
protecting PQ space, R3 is not.
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 [RFC5286] computations. So S may reuse the list of
links and nodes collected from the same SPF computations, to decide
whether a node Y is a candidate nodeprotecting PQnode or not. A
node Y shall be considered as a nodeprotecting PQnode, 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 PQnode. Table 4 below is an illustration of
 the mechanism with the topology in Figure 2.
+ if, there is at least 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 PQnode. Table 4 below is an
+ illustration of the mechanism with the topology in Figure 2.
+++++
 Candidate  Repair Tunnel  LinkProtection  NodeProtection 
 PQnode  Path(Repairing   
  router to PQ   
  node)   
+++++
 R2  S>N>R1>R2  Yes  Yes 
 R2  S>E>R3>R2  No  No 
 R3  S>N>E>R3  Yes  No 
+++++
Table 4: Protection of RemoteLFA tunnel to the PQnode
As seen in the above Table 4 while R2 is candidate nodeprotecting
RemoteLFA 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.
+ the primary nexthop E is in the shortest path from R2 to E and D1.
2.3.2. Computing nodeprotecting paths from PQnodes to destinations
Once a computing router finds all the candidate nodeprotecting 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
+ procedure as proposed in this section, to choose one or more node
protecting RLFA paths, for destinations reachable through the same
primary link in the primary SPF graph.
To find a nodeprotecting RLFA path for a given destination, the
computing router needs to pick a subset of PQnodes from the
candidate nodeprotecting PQspace for the corresponding primary
nexthop, such that all the path(s) from the PQnode(s) to the given
 destination remain unaffected in the event of a node failure of
+ destination remain unaffected in the event of a node failure of the
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 PQnode to the given destination.
This document proposes an additional forward SPF computation for each
of the PQnodes, to discover all shortest paths from the PQnodes 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 PQnode to the given destination or not. To
determine if a given candidate nodeprotecting PQnode provides node
protecting alternate for a given destination, the primary nexthop
node should not be on any of the shortest paths from the PQnode to
the given destination. On running the forward SPF on a candidate
nodeprotecting PQnode the computing router shall run the inequality
 in Figure 6 below. PQnodes that does not qualify the condition for
 a given destination, does not gaurantee nodeprotection for the path
+ in Figure 6 below. A PQnode that does not qualify the condition for
+ a given destination, does not guarantee nodeprotection for the path
segment from the PQnode to the given destination.
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 nodeprotecting PQnode being evaluated
@@ 486,23 +486,23 @@
 D1  E  3  2  1  No 
   (R2,D1)  (R2,E)  (E,D1)  
 D2  E  2  2  1  Yes 
   (R2,D2)  (R2,E)  (E,D2)  
+++++++
Table 5: Nodeprotection evaluation for RLFA path segment between
PQnode and destination
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 nodeprotecting RemoteLFA nexthop for R3 and G, it is
 not so for E and F.
+ protecting inequality for destination E, and D1. And so, once again,
+ while R2 is a nodeprotecting RemoteLFA nexthop for R3 and D2, it is
+ not so for E and D1.
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 PQnode provides nodeprotection for a given
destination or not, the list of nodes computed from forward SPF run
on the PQnode, for the given destination, should be inspected. In
case the list contains the primary nexthop node, the PQnode does not
provide nodeprotection. Else, the PQnode guarantees node
protecting alternate for the given destination. Below is an
illustration of the mechanism with candidate nodeprotecting PQnode
@@ 517,87 +517,86 @@
 R3  R2>R3  Yes  Yes 
 E  R2>R3>E  Yes  No 
 D1  R2>R3>E>D1  Yes  No 
 D2  R2>R3>D2  Yes  Yes 
+++++
Table 6: Protection of RemoteLFA path between PQnode and
destination
As seen in the above example while R2 is candidate nodeprotecting
 RLFA 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.
+ RLFA 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 D1.
The procedure described in this document helps no more than to
determine whether a given RemoteLFA alternate provides node
protection for a given destination or not. It does not find out any
new RemoteLFA alternate nexthops, outside the ones already computed
by standard RemoteLFA procedure. However, in case of availability
of more than one PQnode (RemoteLFA alternates) for a destination,
and nodeprotection is required for the given primary nexthop, this
procedure will eliminate the PQnodes that do not provide node
protection and choose only the ones that does.
2.3.3. Limiting extra computational overhead
In addition to the extra reverse SPF computation, one per directly
 connected neighbor, suggested by the RemoteLFA
 [ID.ietfrtgwgremotelfa] draft, this document proposes a forward
 SPF per PQnode discovered in the network. Since the average number
 of PQnodes 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 PQnode may add considerably to the overall SPF
 computation time.
+ connected neighbor, suggested by the RemoteLFA [RFC7490] draft, this
+ document proposes a forward SPF per PQnode discovered in the
+ network. Since the average number of PQnodes 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 PQnode
+ may add considerably to the overall SPF computation time.
To limit the computational overhead of the approach proposed, this
document proposes that implementations MUST choose a subset from the
entire set of PQnodes computed in the network, with a finite limit
on the number of PQnodes 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 PQnode in this subset. Finally, implementations MAY also allow
user to override the default preference criteria, by providing a
policy configuration for the same.
This document proposes that implementations SHOULD use a default
preference criteria for PQnode selection which will put a score on
each PQnode, proportional to the number of primary interfaces for
 which it provides coverage, its distance from the computing router,
+ which it provides coverage, it's distance from the computing router,
and its routerid (or systemid in case of ISIS). PQnodes that
cover more primary interfaces SHOULD be preferred over PQnodes that
cover fewer primary interfaces. When two or more PQnodes cover the
same number of primary interfaces, PQnodes which are closer (based
on metric) to the computing router SHOULD be preferred over PQnodes
farther away from it. For PQnodes that cover the same number of
primary interfaces and are the same distance from the the computing
router, the PQnode with smaller routerid (or systemid in case of
ISIS) SHOULD be preferred.
Once a subset of PQnodes is found, computing router shall run a
forward SPF on each of the PQnodes in the subset to continue with
procedures proposed in section Section 2.3.2.
3. Manageabilty of RemoteLFA Alternate Paths
3.1. The Problem
 With the regular RemoteLFA [ID.ietfrtgwgremotelfa] functionality
 the computing router may compute more than one PQnode as usable
 RemoteLFA alternate nexthops. Additionally an alternate selection
 policy may be configured to enable the network operator to choose one
 of them as the most appropriate RemoteLFA alternate. For such
 policybased alternate selection to run, all the relevant path
 characteristics for each the alternate paths (one through each of the
 PQnodes), needs to be collected. As mentioned befor in section
 Section 2.3 the RLFA alternate path through a given PQnode to a
 given destination comprises of two path segments.
+ With the regular RemoteLFA [RFC7490] functionality the computing
+ router may compute more than one PQnode as usable RemoteLFA
+ alternate nexthops. Additionally an alternate selection policy may
+ be configured to enable the network operator to choose one of them as
+ the most appropriate RemoteLFA alternate. For such policybased
+ alternate selection to run, all the relevant path characteristics for
+ each the alternate paths (one through each of the PQnodes), needs to
+ be collected. As mentioned before in section Section 2.3 the RLFA
+ alternate path through a given PQnode to a given destination is
+ comprised of two path segments.
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 Section 2.3.2 of this document, there is no way
to determine the path characteristics for the second path segment
(i.e from the PQnode to the destination). In the absence of the
path characteristics for the second path segment, two RemoteLFA
alternate path may be equally preferred based on the first path
segments characteristics only, although the second path segment
@@ 623,85 +622,83 @@
the computational complexity within affordable limits. However if
the alternateselection policy is very restrictive this may leave few
destinations in the entire toplogy without protection. Yet this
limitation provides a necessary tradeoff between extensive coverage
and immense computational overhead.
4. Acknowledgements
Many thanks to Bruno Decraene for providing his useful comments. We
would also like to thank Uma Chunduri for reviewing this document and
 providing valuable feedback.
+ providing valuable feedback. Also, many thanks to Harish Raghuveer
+ for his review and comments on the initial versions of this document.
5. IANA Considerations
N/A.  No protocol changes are proposed in this document.
6. Security Considerations
This document does not introduce any change in any of the protocol
specifications. It simply proposes to run an extra SPF rooted on
each PQnode discovered in the whole network.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 Requirement Levels", BCP 14, RFC 2119, March 1997.
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ .
7.2. Informative References
[ID.ietfrtgwglfamanageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
 Horneffer, M., and p. psarkar@juniper.net, "Operational
 management of Loop Free Alternates", draftietfrtgwglfa
 manageability03 (work in progress), February 2014.
+ Horneffer, M., and P. Sarkar, "Operational management of
+ Loop Free Alternates", draftietfrtgwglfa
+ manageability11 (work in progress), June 2015.
 [ID.ietfrtgwgremotelfa]
 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
 Ning, "Remote LFA FRR", draftietfrtgwgremotelfa06
 (work in progress), May 2014.
+ [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
+ IP Fast Reroute: LoopFree Alternates", RFC 5286,
+ DOI 10.17487/RFC5286, September 2008,
+ .
 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
 Reroute: LoopFree Alternates", RFC 5286, September 2008.
+ [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
+ So, "Remote LoopFree Alternate (LFA) Fast Reroute (FRR)",
+ RFC 7490, DOI 10.17487/RFC7490, April 2015,
+ .
Authors' Addresses
Pushpasis Sarkar (editor)
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA 560103
India
 Email: psarkar@juniper.net

 Hannes Gredler
 Juniper Networks, Inc.
 1194 N. Mathilda Ave.
 Sunnyvale, CA 94089
 US

 Email: hannes@juniper.net
+ Email: pushpasis.ietf@gmail.com; psarkar@juniper.net
Shraddha Hegde
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Chris Bowers
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: cbowers@juniper.net
+ Hannes Gredler
+ Unaffiliated
+
+ Email: hannes@gredler.at
+
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com

 Harish Raghuveer

 Email: harish.r.prabhu@gmail.com