Routing Area Working Group P. Sarkar, Ed.
Internet-Draft H. Gredler
Intended status: Standards Track S. Hegde
Expires: January 9, 2014 H. Raghuveer
Juniper Networks, Inc.
July 8, 2013
Node Protecting R-LFA and Manageability
draft-psarkar-rtgwg-rlfa-node-protection-01
Abstract
The loop-free alternates computed following the current Remote-LFA
[I-D.ietf-rtgwg-remote-lfa] 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.
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.
Requirements Language
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 RFC2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts 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 Internet-Drafts as reference
material or to cite them other than as "work in progress."
Sarkar, et al. Expires January 9, 2014 [Page 1]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
This Internet-Draft will expire on January 9, 2014.
Copyright Notice
Copyright (c) 2013 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/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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.
Sarkar, et al. Expires January 9, 2014 [Page 2]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Node Protection with Remote-LFA . . . . . . . . . . . . . . . 4
2.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 5
3. Manageabilty of Remote-LFA Alternate Paths . . . . . . . . . . 8
3.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. The Solution . . . . . . . . . . . . . . . . . . . . . . . 8
4. Prior Solutions . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Advantage of this Proposal . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Sarkar, et al. Expires January 9, 2014 [Page 3]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
1. Introduction
The Remote-LFA [I-D.ietf-rtgwg-remote-lfa] 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.
Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability]
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.
With current LFA [RFC5286] and Remote-LFA implementations, the
forward SPF (and reverse SPF) is run on the computing router and its
immediate 1-hop routers as the roots. While that enables computation
of path attributes (e.g. SRLG, Admin-groups) first alternate path
segment from the computing router PQ-node, there is no means for the
computing router to gather any path attributes for the path segment
from the PQ-node to destination. Consecutively any policy-based
selection of alternate paths will consider only the path attributes
from the computing router up until the PQ-node.
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.
2. Node Protection with Remote-LFA
2.1. The Problem
To better illustrate the problem and the solution proposed in this
document the following topology diagram from the Remote-LFA
[I-D.ietf-rtgwg-remote-lfa], draft is being re-used with slight
modification.
Sarkar, et al. Expires January 9, 2014 [Page 4]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
F
/
S-x-E
/ \
A D--G
\ /
B---C
Figure 1: Sample Ring Topology
In the above topology, for all (non-ECMP) destinations reachable via
the S-E link there is no standard LFA alternate. As per the Remote-
LFA [I-D.ietf-rtgwg-remote-lfa] alternate specifications node C being
the PQ-node for the S-E link provides nexthop for all the above
destinations. Table 1 below, shows all possible primary and Remote-
LFA alternate paths for each destination.
+-------------+--------------+------------------------+
| Destination | Primary Path | Remote-LFA Backup Path |
+-------------+--------------+------------------------+
| D | S->E->D | S=>A=>B=>C->D |
| E | S->E | S=>A=>B=>C->D->E |
| F | S->E->F | S=>A=>B=>C->D->E->F |
| G | S->E->D->G | S=>A=>B=>C->D->G |
+-------------+--------------+------------------------+
Table 1: Backup paths with Remote-LFA
A closer look at Table 1 shows that, while the PQ-node C provides
link-protection for all the destinations, it does not provide node-
protection for destinations E and F. In the event of the node-failure
on primary nexthop E, the alternate path from Remote-LFA nexthop C to
E and F also becomes unavailable. So for a Remote-LFA nexthop to
provide node-protection for a given destination, it is mandatory
that, the shortest path from the given PQ-node to the given
destination must not traverse the primary nexthop.
2.2. The Solution
This document proposes an additional forward SPF computation for each
of the PQ-nodes, as a mechanism to provide node-protection with
remote LFA. In case, a alternate selection policy has been
configured, the mechanism proposed, shall also provide a means to
collect complete path attributes for the alternate path via a Remote-
LFA nexthop to a given destination.
The additional forward SPF computation for each PQ-node, shall help
determine, if a given primary nexthop node is on shortest paths from
Sarkar, et al. Expires January 9, 2014 [Page 5]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
a given PQ-node to any given destination or not. To determine if a
given PQ-node provides node-protecting alternate for a given
destination, the primary nexthop node should not be on any of the
shortest paths from the given PQ-node to the given destination.
Some SPF implementations may produce a list of links and nodes
traversed on the shortest path(s) from a given root to others. In
such implementations, running a forward SPF rooted at a given PQ-node
will produce a list of nodes (one per each destination), on one or
more shortest path(s) from the PQ-node to other destinations in the
network. To determine whether a PQ-node provides node-protection for
a given destination or not, the list of nodes computed from forward
SPF run on the PQ-node, for the given destination, should be
inspected. In case the list contains the primary nexthop node, the
PQ-node does not provide node-protection. Else, the PQ-node
guarantees node-protecting alternate for the given destination.
Below is an illustration of the mechanism with the topology in
Figure 1.
+-----------+--------+------------+----------------+----------------+
| Destinati | PQ-nod | Shortest | Link-Protectio | Node-Protectio |
| on | e | Path(PQ-no | n | n |
| | | de to | | |
| | | Dest) | | |
+-----------+--------+------------+----------------+----------------+
| D | C | C->D | Yes | Yes |
| E | C | C->D->E | Yes | No |
| F | C | C->D->E->F | Yes | No |
| G | C | C->D->G | Yes | Yes |
+-----------+--------+------------+----------------+----------------+
Table 2: Types of protection with Remote-LFA
As seen in the above example while C is node-protecting Remote-LFA
nexthop for D and G, it is not so for E and F, since the primary
nexthop E is in the shortest path from C to E and F.
Alternatively, an implementation may also run the node-protection
condition from the LFA [RFC5286] specification with slight
modification as shown in Figure 2 below. PQ-nodes that does not
qualify the condition for a given destination, does not gaurantee
node-protection for the same.
Sarkar, et al. Expires January 9, 2014 [Page 6]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
D_opt(Npq, Dst) < D_opt(Npq, Np) + Distance_opt(Np, Dst)
- D_opt(X, Y) : Distance on most optimum path from X to Y.
- Npq : The PQ-node being considered.
- Dst : The destination being protected.
- Np : The primary nexthop node on shortest path
from computing router to destination.
Figure 2: Node-Protection Condition for Remote-LFA
All of the above metric costs except D_opt(Npq, Dst), can be obtained
with forward and reverse SPFs with Np(the primary nexthop) as the
root, run as part of the regular LFA and Remote-LFA implementation.
The Distance_opt(Npq, Dst) metric can only be determined by the
additional forward SPF run with Npq(PQ-node) as the root. With
reference to the topology in Figure 1, Table 3 below shows how the
above condition can be used to determine node-protection with a PQ-
node.
+-----------+----------+--------+-------+-------+-------+-----------+
| Destinati | Primary- | PQ-nod | D_opt | D_opt | D_opt | Condition |
| on (Dst) | NH (Np) | e | (Npq, | (Npq, | (Np, | Met |
| | | (Npq) | Dst) | Np) | Dst) | |
+-----------+----------+--------+-------+-------+-------+-----------+
| D | E | C | 1 | 1 | 1 | Yes |
| E | E | C | 2 | 2 | 0 | No |
| F | E | C | 3 | 2 | 1 | No |
| G | E | C | 2 | 2 | 1 | Yes |
+-----------+----------+--------+-------+-------+-------+-----------+
Table 3: Using Node-protecting condition for Remote-LFA
As seen in the above example above, C does not meet the node-
protecting inequality for destination E, and F. And so, once again,
while C is a node-protecting Remote-LFA nexthop for D and G, it is
not so for E and F.
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.
Sarkar, et al. Expires January 9, 2014 [Page 7]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
3. Manageabilty of Remote-LFA Alternate Paths
3.1. The Problem
With the regular Remote-LFA functionality the computing router may
compute more than one PQ-node as usable Remote-LFA alternate
nexthops. Additionally a alternate selection policy may be
configured to enable the network operator to choose one of them as
the most appropriate Remote-LFA alternate. For such policy-based
alternate selection to run, all the relevant path characteristics for
each the alternate paths (one through each of the PQ-nodes), needs to
be collected. The Remote-LFA alternate path through a given PQ-node
to a given destination comprises of two path segments as follows.
1. Path segment from the computing router to the PQ-node (Remote-LFA
alternate nexthop), and
2. Path segment from the PQ-node to the destination being protected.
The first Path segment can be calculated from the regular forward SPF
done as part of standard and remote LFA computations. However
without the mechanism proposed in this document, there is no way to
determine the path characteristics for the second path segment. In
the absence of the path characteristics for the second path segment,
two Remote-LFA alternate path may be equally preferred based on the
first path segments characteristics only, although the second path
segment attributes may be different.
3.2. The Solution
The additional forward SPF computation being proposed in this
document shall also collect links, nodes and path characteristics
along the second path segment. This shall enable collection of
complete path characteristics for a given Remote-LFA alternate path
to a given destination. The complete alternate path characteristics
shall then facilitate more accurate alternate path selection while
running the alternate selection policy.
4. Prior Solutions
A recent Node Protecting Remote-LFA
[I-D.litkowski-rtgwg-node-protect-remote-lfa] draft proposes a
solution for providing node-protection with Remote-LFA. It requires
the computing router to additionally run reverse SPFs rooted at the
nextnexthop routers (i.e. all the 2-hop neighborhood) as well. A
simple study of standard IGP network topologies in real-life
deployments shall reveal that, the increase in the number of required
Sarkar, et al. Expires January 9, 2014 [Page 8]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
SPF computations is exponential, and can be a substantial computation
overhead.
4.1. Advantage of this Proposal
Following are the advantages of the mechanism proposed in this
document.
o The recent Remote-LFA node-protection document
[I-D.litkowski-rtgwg-node-protect-remote-lfa] proposes an extra
reverse SPF computation for each nextnexthop of the computing
router. The mechanism in this document proposes an extra forward
SPF for each of the PQ-nodes. Considering some of the standard
IGP network topologies in real-life service-provider deployments,
the number of nextnexthops will be substantially higher than the
number of PQ-nodes discovered in those topologies. Hence the
number of additional SPFs required in the proposed mechanism in
this document will be considerably less compared to the procedures
outlined in [I-D.litkowski-rtgwg-node-protect-remote-lfa], and
imply less computational overhead.
o Also the extra reverse SPF proposed per nextnexthop in Remote-LFA
node-protection [I-D.litkowski-rtgwg-node-protect-remote-lfa]
specification does not provide a means to collect the path
characteristics for the alternate path segment from the PQ-node to
the destination. The additional forward SPF for each PQ-node, as
proposed in this document facilitates the same.
5. Acknowledgements
Many thanks to Bruno Decraene and Stephane Litkowski for their useful
comments.
6. IANA Considerations
N/A. - No protocol changes are proposed in this document.
7. 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 PQ-node discovered in the whole network.
8. References
Sarkar, et al. Expires January 9, 2014 [Page 9]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., and K. Raza,
"Operational management of Loop Free Alternates",
draft-ietf-rtgwg-lfa-manageability-00 (work in progress),
May 2013.
[I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02
(work in progress), May 2013.
[I-D.litkowski-rtgwg-node-protect-remote-lfa]
Litkowski, S., "Node protecting remote LFA",
draft-litkowski-rtgwg-node-protect-remote-lfa-00 (work in
progress), April 2013.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
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
Sarkar, et al. Expires January 9, 2014 [Page 10]
Internet-Draft Node Protecting R-LFA and Manageability July 2013
Shraddha Hegde
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Harish Raghuveer
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA 560103
India
Email: hraghuveer@juniper.net
Sarkar, et al. Expires January 9, 2014 [Page 11]