< draft-ietf-rtgwg-rlfa-node-protection-07.txt   draft-ietf-rtgwg-rlfa-node-protection-08.txt >
Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed.
Internet-Draft Individual Contributor Internet-Draft Individual Contributor
Intended status: Standards Track S. Hegde Intended status: Standards Track S. Hegde
Expires: April 11, 2017 C. Bowers Expires: May 21, 2017 C. Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
H. Gredler H. Gredler
RtBrick Inc. RtBrick, Inc.
S. Litkowski S. Litkowski
Orange Orange
October 8, 2016 November 17, 2016
Remote-LFA Node Protection and Manageability Remote-LFA Node Protection and Manageability
draft-ietf-rtgwg-rlfa-node-protection-07 draft-ietf-rtgwg-rlfa-node-protection-08
Abstract Abstract
The loop-free alternates computed following the current Remote-LFA The loop-free alternates computed following the current Remote-LFA
specification guarantees only link-protection. The resulting Remote- specification guarantees only link-protection. The resulting Remote-
LFA nexthops (also called PQ-nodes), may not guarantee node- LFA nexthops (also called PQ-nodes), may not guarantee node-
protection for all destinations being protected by it. protection for all destinations being protected by it.
This document describes procedures for determining if a given PQ-node This document describes an extension to the Remote Loop-Free based IP
provides node-protection for a specific destination or not. The fast reroute mechanisms described in [RFC7490], that describes
document also shows how the same procedure can be utilised for procedures for determining if a given PQ-node provides node-
collection of complete characteristics for alternate paths. protection for a specific destination or not. The document also
Knowledge about the characteristics of all alternate path is shows how the same procedure can be utilised for collection of
precursory to apply operator defined policy for eliminating paths not complete characteristics for alternate paths. Knowledge about the
fitting constraints. characteristics of all alternate path is precursory to apply operator
defined policy for eliminating paths not fitting constraints.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 7 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2017. This Internet-Draft will expire on May 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 17 skipping to change at page 3, line 19
1. Introduction 1. Introduction
The Remote-LFA [RFC7490] specification provides loop-free alternates The Remote-LFA [RFC7490] specification provides loop-free alternates
that guarantee only link-protection. The resulting Remote-LFA that guarantee only link-protection. The resulting Remote-LFA
alternate nexthops (also referred to as the PQ-nodes) may not provide alternate nexthops (also referred to as the PQ-nodes) may not provide
node-protection for all destinations covered by the same, in case of node-protection for all destinations covered by the same, in case of
failure of the primary nexthop node. Neither does the specification failure of the primary nexthop node. Neither does the specification
provide a means to determine the same. provide a means to determine the same.
Also, the LFA Manageability [RFC7916] document, requires a computing Also, the LFA Manageability [RFC7916] document requires a computing
router to find all possible (including all possible Remote-LFA) router to find all possible (including all possible Remote-LFA)
alternate nexthops, collect the complete set of path characteristics alternate nexthops, collect the complete set of path characteristics
for each alternate path, run a alternate-selection policy (configured for each alternate path, run an alternate-selection policy
by the operator), and find the best alternate path. This will (configured by the operator) and find the best alternate path. This
require the Remote-LFA implementation to gather all the required path will require the Remote-LFA implementation to gather all the required
characteristics along each link on the entire Remote-LFA alternate path characteristics along each link on the entire Remote-LFA
path. alternate path.
With current LFA [RFC5286] and Remote-LFA implementations, the With current LFA [RFC5286] and Remote-LFA implementations, the
forward SPF (and reverse SPF) is run on the computing router and its forward SPF (and reverse SPF) is run with the computing router and
immediate 1-hop routers as the roots. While that enables computation its immediate 1-hop routers as the roots. While that enables
of path attributes (e.g. SRLG, Admin-groups) for first alternate computation of path attributes (e.g. SRLG, Admin-groups) for first
path segment from the computing router to the PQ-node, there is no alternate path segment from the computing router to the PQ-node,
means for the computing router to gather any path attributes for the there is no means for the computing router to gather any path
path segment from the PQ-node to destination. Consequently any attributes for the path segment from the PQ-node to destination.
policy-based selection of alternate paths will consider only the path Consequently any policy-based selection of alternate paths will
attributes from the computing router up until the PQ-node. consider only the path attributes from the computing router up until
the PQ-node.
This document describes a procedure for determining node-protection This document describes a procedure for determining node-protection
with Remote-LFA. The same procedure is also extended for collection with Remote-LFA. The same procedure is also extended for collection
of a 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 Remote-LFA. based selection for alternate paths obtained with Remote-LFA.
2. Node Protection with Remote-LFA 2. Node Protection with Remote-LFA
Node-protection is required to provide protection of traffic on a Node-protection is required to provide protection of traffic on a
given forwarding node, against the failure of the first-hop node on given forwarding node, against the failure of the first-hop node on
the primary forwarding path. Such protection becomes more critical the primary forwarding path. Such protection becomes more critical
in the absence of mechanisms like non-stop-routing in the network. in the absence of mechanisms like non-stop-routing in the network.
Certain operators refrain from deploying non-stop-routing in their Certain operators refrain from deploying non-stop-routing in their
network, due to the significant additional performance complexities network, due to the required complex state synchronization between
it introduces. In such cases node-protection is essential to redundant control plane hardwares it requires, and the significant
guarantee un-interrupted flow of traffic, even in the case of an additional performance complexities it hence introduces. In such
entire forwarding node going down. cases node-protection is essential to guarantee un-interrupted flow
of traffic, even in the case of an entire forwarding node going down.
The following sections discuss the node-protection problem in the The following sections discuss the node-protection problem in the
context of Remote-LFA and propose a solution. context of Remote-LFA and propose a solution.
2.1. The Problem 2.1. The Problem
To better illustrate the problem and the solution proposed in this To better illustrate the problem and the solution proposed in this
document the following topology diagram from the Remote-LFA [RFC7490] document the following topology diagram from the Remote-LFA [RFC7490]
draft is being re-used with slight modification. draft is being re-used with slight modification.
skipping to change at page 7, line 12 skipping to change at page 7, line 12
protected, if and only if, Y is present in both link-protecting protected, if and only if, Y is present in both link-protecting
extended P-space and the Q-space for the link being protected. extended P-space and the Q-space for the link being protected.
2.2.5. Candidate Node-Protecting PQ Space 2.2.5. Candidate Node-Protecting PQ Space
A node Y is in candidate node-protecting PQ space w.r.t to the node 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- (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 protecting extended P-space and the Q-space for the link being
protected. protected.
It must be noted, that a node Y being in candidate node-protecting Please note, that a node Y being in candidate node-protecting PQ-
PQ-space, does not guarantee that the R-LFA alternate path via the space, does not guarantee that the R-LFA alternate path via the same,
same, in entirety, is unaffected in the event of a node failure of in entirety, is unaffected in the event of a node failure of primary
primary nexthop node E. It only guarantees that the path segment nexthop node E. It only guarantees that the path segment from S to
from S to PQ-node Y is unaffected by the same failure event. The PQ- PQ-node Y is unaffected by the same failure event. The PQ-nodes in
nodes in the candidate node-protecting PQ space may provide node the candidate node-protecting PQ space may provide node protection
protection for only a subset of destinations that are reachable for only a subset of destinations that are reachable through the
through the corresponding primary link. corresponding primary link.
2.2.6. Cost-Based Definitions 2.2.6. Cost-Based Definitions
This section provides cost-based definitions for some of the terms This section provides cost-based definitions for some of the terms
introduced in Section 2.2 of this document. introduced in Section 2.2 of this document.
2.2.6.1. Link-Protecting Extended P-Space 2.2.6.1. Link-Protecting Extended P-Space
Please refer to Section 2.2.1 for a formal definition for Link- Please refer to Section 2.2.1 for a formal definition for Link-
protecting Extended P-Space. protecting Extended P-Space.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
D_opt(A,B) : Distance on most optimum path from A to B. D_opt(A,B) : Distance on most optimum path from A to B.
E : The primary nexthop on shortest path from S E : The primary nexthop on shortest path from S
to destination. to destination.
Ni : A direct neighbor of S other than primary Ni : A direct neighbor of S other than primary
nexthop E. nexthop E.
Y : The node being evaluated for node-protecting Y : The node being evaluated for node-protecting
extended P-Space. extended P-Space.
Figure 4: Node-Protecting Ext-P-Space Condition Figure 4: Node-Protecting Ext-P-Space Condition
It must be noted that a node Y satisfying the condition in Figure 4 Please note, that a node Y satisfying the condition in Figure 4 above
above only guarantees that the R-LFA alternate path segment from S only guarantees that the R-LFA alternate path segment from S via
via direct neighbor Ni to the node Y is not affected in the event of direct neighbor Ni to the node Y is not affected in the event of a
a node failure of E. It does not yet guarantee that the path segment 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 from node Y to the destination is also unaffected by the same failure
event. event.
2.2.6.3. Q-Space 2.2.6.3. Q-Space
Please refer to Section 2.2.3 for a formal definition for Q-Space. Please refer to Section 2.2.3 for a formal definition for Q-Space.
A node Y is in Q-space w.r.t to the link (S-E) being protected, if 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. and only if, the following condition is satisfied.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
nexthops nexthops
To choose a node-protecting R-LFA nexthop for a destination R3, To choose a node-protecting R-LFA nexthop for a destination R3,
router S needs to consider a PQ-node from the candidate node- 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 protecting PQ-space for the primary nexthop E on shortest path from S
to R3. As mentioned in Section 2.2.2, to consider a PQ-node as to R3. As mentioned in Section 2.2.2, to consider a PQ-node as
candidate node-protecting PQ-node, there must be at least one direct candidate node-protecting PQ-node, there must be at least one direct
neighbor Ni of S, such that all shortest paths from Ni to the PQ-node neighbor Ni of S, such that all shortest paths from Ni to the PQ-node
does not traverse primary nexthop node E. does not traverse primary nexthop node E.
Implementations should run the inequality in Section 2.2.2 Figure 4 Implementations SHOULD run the inequality in Section 2.2.2 Figure 4
for all direct neighbor, other than primary nexthop node E, to for all direct neighbors, other than primary nexthop node E, to
determine whether a node Y is a candidate node-protecting PQ-node. determine whether a node Y is a candidate node-protecting PQ-node.
All of the metrics needed by this inequality would have been already All of the metrics needed by this inequality would have been already
collected from the forward SPFs rooted at each of direct neighbor S, collected from the forward SPFs rooted at each of direct neighbor S,
computed as part of standard LFA [RFC5286] implementation. With computed as part of standard LFA [RFC5286] implementation. With
reference to the topology in Figure 2, Table 3 below shows how the reference to the topology in Figure 2, Table 3 below shows how the
above condition can be used to determine the candidate node- above condition can be used to determine the candidate node-
protecting PQ-space for S-E link (primary nexthop E) protecting PQ-space for S-E link (primary nexthop E).
+------------+----------+----------+----------+---------+-----------+ +------------+----------+----------+----------+---------+-----------+
| Candidate | Direct | D_opt | D_opt | D_opt | Condition | | Candidate | Direct | D_opt | D_opt | D_opt | Condition |
| PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met | | PQ-node | Nbr (Ni) | (Ni,Y) | (Ni,E) | (E,Y) | Met |
| (Y) | | | | | | | (Y) | | | | | |
+------------+----------+----------+----------+---------+-----------+ +------------+----------+----------+----------+---------+-----------+
| R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes | | R2 | N | 2 (N,R2) | 1 (N,E) | 2 | Yes |
| | | | | (E,R2) | | | | | | | (E,R2) | |
| R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No | | R3 | N | 2 (N,R3) | 1 (N,E) | 1 | No |
| | | | | (E,R3) | | | | | | | (E,R3) | |
+------------+----------+----------+----------+---------+-----------+ +------------+----------+----------+----------+---------+-----------+
Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ- Table 3: Node-protection evaluation for R-LFA repair tunnel to PQ-
node node
As seen in the above Table 3 , R3 does not meet the node-protecting As seen in the above Table 3, R3 does not meet the node-protecting
extended-p-space inequality and so, while R2 is in candidate node- extended-p-space inequality and so, while R2 is in candidate node-
protecting PQ space, R3 is not. protecting PQ space, R3 is not.
Some SPF implementations may also produce a list of links and nodes 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 traversed on the shortest path(s) from a given root to others. In
such implementations, router S may have executed a forward SPF with such implementations, router S may have executed a forward SPF with
each of its direct neighbors as the SPF root, executed as part of the each of its direct neighbors as the SPF root, executed as part of the
standard LFA [RFC5286] computations. So S may re-use the list of standard LFA [RFC5286] computations. So S may re-use the list of
links and nodes collected from the same SPF computations, to decide 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 whether a node Y is a candidate node-protecting PQ-node or not. A
skipping to change at page 11, line 18 skipping to change at page 11, line 18
nodes for a given directly attached primary link, it shall follow the nodes for a given directly attached primary link, it shall follow the
procedure as proposed in this section, to choose one or more node- procedure as proposed in this section, to choose one or more node-
protecting R-LFA paths, for destinations reachable through the same protecting R-LFA paths, for destinations reachable through the same
primary link in the primary SPF graph. primary link in the primary SPF graph.
To find a node-protecting R-LFA path for a given destination, the 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 computing router needs to pick a subset of PQ-nodes from the
candidate node-protecting PQ-space for the corresponding primary candidate node-protecting PQ-space for the corresponding primary
nexthop, such that all the path(s) from the PQ-node(s) to the given 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 the destination remain unaffected in the event of a node failure of the
primary nexthop node. To ensure this, the computing router will need primary nexthop node. To determine wether a given PQ-node belongs to
to ensure that, the primary nexthop node should not be on any of the such a subset of PQ-nodes, the computing router MUST ensure that none
shortest paths from the PQ-node to the given destination. of the primary nexthop node are found on any of the shortest paths
from the PQ-node to the given destination.
This document proposes an additional forward SPF computation for each This document proposes an additional forward SPF computation for each
of the PQ-nodes, to discover all shortest paths from the PQ-nodes to of the PQ-nodes, to discover all shortest paths from the PQ-nodes to
the destination. The additional forward SPF computation for each PQ- the destination. This will help determine, if a given primary
node, shall help determine, if a given primary nexthop node is on the nexthop node is on the shortest paths from the PQ-node to the given
shortest paths from the PQ-node to the given destination or not. To destination or not. To determine if a given candidate node-
determine if a given candidate node-protecting PQ-node provides node- protecting PQ-node provides node-protecting alternate for a given
protecting alternate for a given destination, the primary nexthop destination, or not, all the shortest paths from the PQ-node to the
node should not be on any of the shortest paths from the PQ-node to given destination has to be inspected, to check if the primary
the given destination. On running the forward SPF on a candidate nexthop node is found on any of these shortest paths. To compute all
node-protecting PQ-node the computing router shall run the inequality the shortest paths from a candidate node-protecting PQ-node to one
in Figure 6 below. A PQ-node that does not qualify the condition for (or more) destination, the computing router MUST run the forward SPF
a given destination, does not guarantee node-protection for the path on the candidate node-protecting PQ-node. Soon after running the
segment from the PQ-node to the given destination. forward SPF, the computer router SHOULD run the inequality in
Figure 6 below, once for each destination. A PQ-node that does not
qualify the condition for a given destination, does not guarantee
node-protection for the path segment from the PQ-node to the specific
destination.
D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D) D_opt(Y,D) < D_opt(Y,E) + Distance_opt(E,D)
Where, Where,
D_opt(A,B) : Distance on most optimum path from A to B. D_opt(A,B) : Distance on most optimum path from A to B.
D : The destination node. D : The destination node.
E : The primary nexthop on shortest path from S E : The primary nexthop on shortest path from S
to destination. to destination.
Y : The node-protecting PQ-node being evaluated Y : The node-protecting PQ-node being evaluated
skipping to change at page 12, line 30 skipping to change at page 12, line 37
Table 5: Node-protection evaluation for R-LFA path segment between Table 5: Node-protection evaluation for R-LFA path segment between
PQ-node and destination PQ-node and destination
As seen in the above example above, R2 does not meet the node- As seen in the above example above, R2 does not meet the node-
protecting inequality for destination E, and D1. And so, once again, protecting inequality for destination E, and D1. And so, once again,
while R2 is a node-protecting Remote-LFA nexthop for R3 and D2, it is while R2 is a node-protecting Remote-LFA nexthop for R3 and D2, it is
not so for E and D1. not so for E and D1.
In SPF implementations that also produce a list of links and nodes 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 traversed on the shortest path(s) from a given root to others, the
inequality in Figure 6 above need not be evaluated. Instead, to
determine whether a PQ-node provides node-protection for a given determine whether a PQ-node provides node-protection for a given
destination or not, the list of nodes computed from forward SPF run destination or not, the list of nodes computed from forward SPF run
on the PQ-node, for the given destination, should be inspected. In 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 case the list contains the primary nexthop node, the PQ-node does not
provide node-protection. Else, the PQ-node guarantees node- provide node-protection. Else, the PQ-node guarantees node-
protecting alternate for the given destination. Below is an protecting alternate for the given destination. Below is an
illustration of the mechanism with candidate node-protecting PQ-node illustration of the mechanism with candidate node-protecting PQ-node
R2 in the topology in Figure 2. R2 in the topology in Figure 2.
+-------------+-----------------+-----------------+-----------------+ +-------------+-----------------+-----------------+-----------------+
| Destination | Shortest Path | Link-Protection | Node-Protection | | Destination | Shortest Path | Link-Protection | Node-Protection |
| | (Repairing | | | | | (Repairing | | |
| | router to PQ- | | | | | router to PQ- | | |
skipping to change at page 13, line 36 skipping to change at page 13, line 36
protection for a given destination or not. It does not find out any protection for a given destination or not. It does not find out any
new Remote-LFA alternate nexthops, outside the ones already computed new Remote-LFA alternate nexthops, outside the ones already computed
by standard Remote-LFA procedure. However, in case of availability by standard Remote-LFA procedure. However, in case of availability
of more than one PQ-node (Remote-LFA alternates) for a destination, of more than one PQ-node (Remote-LFA alternates) for a destination,
and node-protection is required for the given primary nexthop, this and node-protection is required for the given primary nexthop, this
procedure will eliminate the PQ-nodes that do not provide node- procedure will eliminate the PQ-nodes that do not provide node-
protection and choose only the ones that does. protection and choose only the ones that does.
2.3.3. Limiting extra computational overhead 2.3.3. Limiting extra computational overhead
In addition to the extra reverse SPF computation, one per directly In addition to the extra reverse SPF computations suggested by the
connected neighbor, suggested by the Remote-LFA [RFC7490] draft, this Remote-LFA [RFC7490] draft (one reverse SPF for each of the directly
document proposes a forward SPF per PQ-node discovered in the connected neighbors), this document proposes a forward SPF
network. Since the average number of PQ-nodes found in any network computations for each PQ-node discovered in the network. Since the
is considerably more than the number of direct neighbors of the average number of PQ-nodes found in any network is considerably more
computing router, the proposal of running one forward SPF per PQ-node than the number of direct neighbors of the computing router, the
may add considerably to the overall SPF computation time. proposal of running one forward SPF per PQ-node may add considerably
to the overall SPF computation time.
To limit the computational overhead of the approach proposed, this To limit the computational overhead of the approach proposed, this
document proposes that implementations MUST choose a subset from the document proposes that implementations MUST choose a subset from the
entire set of PQ-nodes computed in the network, with a finite limit 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 on the number of PQ-nodes in the subset. Implementations MUST choose
a default value for this limit and may provide user with a a default value for this limit and may provide user with a
configuration knob to override the default limit. Implementations configuration knob to override the default limit. Implementations
MUST also evaluate some default preference criteria while considering MUST also evaluate some default preference criteria while considering
a PQ-node in this subset. Finally, implementations MAY also allow a PQ-node in this subset. Finally, implementations MAY also allow
user to override the default preference criteria, by providing a user to override the default preference criteria, by providing a
skipping to change at page 15, line 7 skipping to change at page 15, line 7
proposed in section Section 2.3.2 of this document, there is no way proposed in section Section 2.3.2 of this document, there is no way
to determine the path characteristics for the second path segment to determine the path characteristics for the second path segment
(i.e from the PQ-node to the destination). In the absence of the (i.e from the PQ-node to the destination). In the absence of the
path characteristics for the second path segment, two Remote-LFA path characteristics for the second path segment, two Remote-LFA
alternate path may be equally preferred based on the first path alternate path may be equally preferred based on the first path
segments characteristics only, although the second path segment segments characteristics only, although the second path segment
attributes may be different. attributes may be different.
3.2. The Solution 3.2. The Solution
The additional forward SPF computation proposed in section The additional forward SPF computation proposed in Section 2.3.2
Section 2.3.2 document shall also collect links, nodes and path document shall also collect links, nodes and path characteristics
characteristics along the second path segment. This shall enable along the second path segment. This shall enable collection of
collection of complete path characteristics for a given Remote-LFA complete path characteristics for a given Remote-LFA alternate path
alternate path to a given destination. The complete alternate path to a given destination. The complete alternate path characteristics
characteristics shall then facilitate more accurate alternate path shall then facilitate more accurate alternate path selection while
selection while running the alternate selection policy. running the alternate selection policy.
Like specified in Section 2.3.3 to limit the computational overhead As already specified in Section 2.3.3 to limit the computational
of the approach proposed, forward SPF computations MUST be run on a overhead of the approach proposed, forward SPF computations MUST be
selected subset from the entire set of PQ-nodes computed in the run on a selected subset from the entire set of PQ-nodes computed in
network, with a finite limit on the number of PQ-nodes in the subset. the network, with a finite limit on the number of PQ-nodes in the
The detailed suggestion on how to select this subset is specified in subset. The detailed suggestion on how to select this subset is
the same section. While this limits the number of possible alternate specified in the same section. While this limits the number of
paths provided to the alternate-selection policy, this is needed keep possible alternate paths provided to the alternate-selection policy,
the computational complexity within affordable limits. However if this is needed keep the computational complexity within affordable
the alternate-selection policy is very restrictive this may leave few limits. However if the alternate-selection policy is very
destinations in the entire toplogy without protection. Yet this restrictive this may leave few destinations in the entire toplogy
limitation provides a necessary tradeoff between extensive coverage without protection. Yet this limitation provides a necessary
and immense computational overhead. tradeoff between extensive coverage and immense computational
overhead.
4. Acknowledgements 4. Acknowledgements
Many thanks to Bruno Decraene for providing his useful comments. We Many thanks to Bruno Decraene for providing his useful comments. We
would also like to thank Uma Chunduri for reviewing this document and would also like to thank Uma Chunduri for reviewing this document and
providing valuable feedback. Also, many thanks to Harish Raghuveer providing valuable feedback. Also, many thanks to Harish Raghuveer
for his review and comments on the initial versions of this document. for his review and comments on the initial versions of this document.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 16, line 5 skipping to change at page 16, line 10
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>. <http://www.rfc-editor.org/info/rfc5286>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>. <http://www.rfc-editor.org/info/rfc7490>.
7.2. Informative References
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <http://www.rfc-editor.org/info/rfc7916>. July 2016, <http://www.rfc-editor.org/info/rfc7916>.
Authors' Addresses Authors' Addresses
Pushpasis Sarkar (editor) Pushpasis Sarkar (editor)
Individual Contributor Individual Contributor
skipping to change at page 16, line 44 skipping to change at page 17, line 4
Email: shraddha@juniper.net Email: shraddha@juniper.net
Chris Bowers Chris Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: cbowers@juniper.net Email: cbowers@juniper.net
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick, Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Stephane Litkowski Stephane Litkowski
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
 End of changes. 27 change blocks. 
92 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/