diff options
Diffstat (limited to 'doc/rfc/rfc7490.txt')
| -rw-r--r-- | doc/rfc/rfc7490.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc7490.txt b/doc/rfc/rfc7490.txt new file mode 100644 index 0000000..c2f889d --- /dev/null +++ b/doc/rfc/rfc7490.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Bryant +Request for Comments: 7490 C. Filsfils +Category: Standards Track S. Previdi +ISSN: 2070-1721 Cisco Systems + M. Shand + Independent Contributor + N. So + Vinci Systems + April 2015 + + + Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) + +Abstract + + This document describes an extension to the basic IP fast reroute + mechanism, described in RFC 5286, that provides additional backup + connectivity for point-to-point link failures when none can be + provided by the basic mechanisms. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7490. + +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/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. + + + +Bryant, et al. Standards Track [Page 1] + +RFC 7490 Remote LFA FRR April 2015 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4 + 4. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 + 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 7 + 5. Construction of Repair Paths . . . . . . . . . . . . . . . . 8 + 5.1. Identifying Required Tunneled Repair Paths . . . . . . . 8 + 5.2. Determining Tunnel Endpoints . . . . . . . . . . . . . . 8 + 5.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 9 + 5.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11 + 5.3. A Cost-Based RLFA Algorithm . . . . . . . . . . . . . . . 12 + 5.4. Interactions with IS-IS Overload, RFC 6987, and Costed + Out Links . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Example Application of Remote LFAs . . . . . . . . . . . . . 17 + 7. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Operation in an LDP Environment . . . . . . . . . . . . . . . 19 + 9. Analysis of Real World Topologies . . . . . . . . . . . . . . 21 + 9.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 + 9.2. LFA Only . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9.4. Comparison of LFA and RLFA results . . . . . . . . . . . 24 + 10. Management and Operational Considerations . . . . . . . . . . 25 + 11. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 13.2. Informative References . . . . . . . . . . . . . . . . . 26 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + + + + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 2] + +RFC 7490 Remote LFA FRR April 2015 + + +1. Introduction + + RFC 5714 [RFC5714] describes a framework for IP Fast Reroute (IPFRR) + and provides a summary of various proposed IPFRR solutions. A basic + mechanism using Loop-Free Alternates (LFAs) is described in [RFC5286] + that provides good repair coverage in many topologies [RFC6571], + especially those that are highly meshed. However, some topologies, + notably ring-based topologies, are not well protected by LFAs alone. + This is because there is no neighbor of the Point of Local Repair + (PLR) that has a cost to the destination via a path that does not + traverse the failure that is cheaper than the cost to the destination + via the failure. + + The method described in this document extends the LFA approach + described in [RFC5286] to cover many of these cases by tunneling the + packets that require IPFRR to a node that is both reachable from the + PLR and can reach the destination. + +2. Terminology + + This document uses the terms defined in [RFC5714]. This section + defines additional terms that are used in this document. + + Repair tunnel: + A tunnel established for the purpose of providing a virtual + neighbor that is a Loop-Free Alternate. + + P-space: + The P-space of a router with respect to a protected link is the + set of routers reachable from that specific router using the pre- + convergence shortest paths without any of those paths (including + equal-cost path splits) transiting that protected link. + + For example, the P-space of S with respect to link S-E is the set + of routers that S can reach without using the protected link S-E. + + Extended P-space: + Consider the set of neighbors of a router protecting a link. + Exclude from that set of routers the router reachable over the + protected link. The extended P-space of the protecting router + with respect to the protected link is the union of the P-spaces of + the neighbors in that set of neighbors with respect to the + protected link (see Section 5.2.1.2). + + + + + + + + +Bryant, et al. Standards Track [Page 3] + +RFC 7490 Remote LFA FRR April 2015 + + + Q-space: + The Q-space of a router with respect to a protected link is the + set of routers from which that specific router can be reached + without any path (including equal-cost path splits) transiting + that protected link. + + PQ node: + A PQ node of a node S with respect to a protected link S-E is a + node that is a member of both the P-space (or the extended + P-space) of S with respect to that protected link S-E and the + Q-space of E with respect to that protected link S-E. A repair + tunnel endpoint is chosen from the set of PQ-nodes. + + Remote LFA (RLFA): + The use of a PQ node rather than a neighbor of the repairing node + as the next hop in an LFA repair [RFC5286]. + + In this document, the notation X-Y is used to mean the path from X to + Y over the link directly connecting X and Y while the notation X->Y + refers to the shortest path from X to Y via some set of unspecified + nodes including the null set (i.e., including over a link directly + connecting X and Y). + +2.1. 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 RFC 2119 [RFC2119]. + +3. Overview of Solution + + The problem of LFA IPFRR reachability in some networks is illustrated + by the network fragment shown in Figure 1 below. + + S---E + / \ + A D + \ / + B---C + + Figure 1: A Simple Ring Topology + + If all link costs are equal, traffic that is transiting link S-E + cannot be fully protected by LFAs. The destination C is an Equal- + Cost Multipath (ECMP) from S, and so traffic to C can be protected + when S-E fails but traffic to D and E are not protectable using LFAs. + + + + + +Bryant, et al. Standards Track [Page 4] + +RFC 7490 Remote LFA FRR April 2015 + + + This document describes extensions to the basic repair mechanism in + which tunnels are used to provide additional logical links that can + then be used as loop-free alternates where none exist in the original + topology. In Figure 1, S can reach A, B, and C without going via + S-E; these form S's extended P-space with respect to S-E. The + routers that can reach E without going through S-E will be in E's + Q-space with respect to link S-E; these are D and C. B has equal- + cost paths to E via B-A-S-E and B-C-D-E, and so the forwarder at S + might choose to send a packet to E via link S-E. Hence, B is not in + the Q-space of E with respect to link S-E. The single node in both + S's extended P-space and E's Q-space is C; thus, node C is selected + as the repair tunnel's endpoint. Thus, if a tunnel is provided + between S and C as shown in Figure 2, then C, now being a direct + neighbor of S, would become an LFA for D and E. The definition of + (extended) P-space and Q-space are provided in Section 2, and details + of the calculation of the tunnel end points are provided in + Section 5.2. + + The non-failure traffic distribution is not disrupted by the + provision of such a tunnel since it is only used for repair traffic + and MUST NOT be used for normal traffic. Note that Operations, + Administration, and Maintenance (OAM) traffic used specifically to + verify the viability of the repair MAY traverse the tunnel prior to a + failure. + + S---E + / \ \ + A \ D + \ \ / + B---C + + Figure 2: The Addition of a Tunnel + + The use of this technique is not restricted to ring-based topologies + but it is a general mechanism that can be used to enhance the + protection provided by LFAs. A study of the protection achieved + using remote LFA in typical service provider core networks is + provided in Section 9, and a side-by-side comparison between LFA and + remote LFA is provided in Section 9.4. + + Remote LFA is suitable for incremental deployment within a network, + including a network that is already deploying LFA. Computation of + the repair path requires acceptable CPU resources and takes place + exclusively on the repairing node. In MPLS networks, the targeted + LDP protocol needed to learn the label binding at the repair tunnel + endpoint (Section 8) is a well understood and widely deployed + technology. + + + + +Bryant, et al. Standards Track [Page 5] + +RFC 7490 Remote LFA FRR April 2015 + + + The technique described in this document is directed at providing + repairs in the case of link failures. Considerations regarding node + failures are discussed in Section 7. This memo describes a solution + to the case where the failure occurs on a point-to-point link. It + covers the case where the repair first hop is reached via a broadcast + or non-broadcast multi-access (NBMA) link such as a LAN and the case + where the P or Q node is attached via such a link. It does not, + however, cover the more complicated case where the failed interface + is a broadcast or NBMA link. + + This document considers the case when the repair path is confined to + either a single area or to the level two routing domain. In all + other cases, the chosen PQ node should be regarded as a tunnel + adjacency of the repairing node, and the considerations described in + Section 6 of [RFC5286] should be taken into account. + +4. Repair Paths + + As with LFA FRR, when a router detects an adjacent link failure, it + uses one or more repair paths in place of the failed link. Repair + paths are precomputed in anticipation of later failures so they can + be promptly activated when a failure is detected. + + A tunneled repair path tunnels traffic to some staging point in the + network from which it is known that, in the absence of a worse-than- + anticipated failure, the traffic will travel to its destination using + normal forwarding without looping back. This is equivalent to + providing a virtual loop-free alternate to supplement the physical + loop-free alternates; hence the name "remote LFA FRR". In its + simplest form, when a link cannot be entirely protected with local + LFA neighbors, the protecting router seeks the help of a remote LFA + staging point. Network manageability considerations may lead to a + repair strategy that uses a remote LFA more frequently [LFA-MANAGE]. + + Examples of worse failures are node failures (see Section 7), the + failure of a Shared Risk Link Group (SRLG), the independent + concurrent failures of multiple links, or broadcast or NBMA links + (Section 3); protecting against such failures is out of scope for + this specification. + +4.1. Tunnels as Repair Paths + + Consider an arbitrary protected link S-E. In LFA FRR, if a path to + the destination from a neighbor N of S does not cause a packet to + loop back over the link S-E (i.e., N is a loop-free alternate), then + S can send the packet to N and the packet will be delivered to the + destination using the pre-failure forwarding information. If there + is no such LFA neighbor, then S may be able to create a virtual LFA + + + +Bryant, et al. Standards Track [Page 6] + +RFC 7490 Remote LFA FRR April 2015 + + + by using a tunnel to carry the packet to a point in the network that + is not a direct neighbor of S from which the packet will be delivered + to the destination without looping back to S. In this document, such + a tunnel is termed a repair tunnel. The tail end of this tunnel (the + repair tunnel endpoint) is a "PQ node", and the repair mechanism is a + "remote LFA". This tunnel MUST NOT traverse the link S-E. + + Note that the repair tunnel terminates at some intermediate router + between S and E, and not E itself. This is clearly the case, since + if it were possible to construct a tunnel from S to E, then a + conventional LFA would have been sufficient to effect the repair. + +4.2. Tunnel Requirements + + There are a number of IP-in-IP tunnel mechanisms that may be used to + fulfill the requirements of this design, such as IP-in-IP [RFC1853] + and Generic Routing Encapsulation (GRE) [RFC1701]. + + In an MPLS-enabled network using LDP [RFC5036], a simple label stack + [RFC3032] may be used to provide the required repair tunnel. In this + case, the outer label is S's neighbor's label for the repair tunnel + endpoint, and the inner label is the repair tunnel endpoint's label + for the packet destination. In order for S to obtain the correct + inner label, it is necessary to establish a targeted LDP session + [RFC5036] to the tunnel endpoint. + + The selection of the specific tunneling mechanism (and any necessary + enhancements) used to provide a repair path is outside the scope of + this document. The deployment in an MPLS/LDP environment is + relatively simple in the data plane, as an LDP Label Switched Path + (LSP) from S to the repair tunnel endpoint (the selected PQ node) is + readily available and hence does not require any new protocol + extension or design change. This LSP is automatically established as + a basic property of LDP behavior. The performance of the + encapsulation and decapsulation is efficient, as encapsulation is + just a push of one label (like conventional MPLS-TE FRR) and the + decapsulation is normally configured to occur at the penultimate hop + before the repair tunnel endpoint. In the control plane, a Targeted + LDP (TLDP) session is needed between the repairing node and the + repair tunnel endpoint, which will need to be established and the + labels processed before the tunnel can be used. The time to + establish the TLDP session and acquire labels will limit the speed at + which a new tunnel can be put into service. This is not anticipated + to be a problem in normal operation since the managed introduction + and removal of links is relatively rare, as is the incidence of + failure in a well-managed network. + + + + + +Bryant, et al. Standards Track [Page 7] + +RFC 7490 Remote LFA FRR April 2015 + + + When a failure is detected, it is necessary to immediately redirect + traffic to the repair path. Consequently, the repair tunnel used + MUST be provisioned beforehand in anticipation of the failure. Since + the location of the repair tunnels is dynamically determined, it is + necessary to automatically establish the repair tunnels. Multiple + repair tunnels may share a tunnel endpoint. + +5. Construction of Repair Paths + +5.1. Identifying Required Tunneled Repair Paths + + Not all links will require protection using a tunneled repair path. + Referring to Figure 1, if E can already be protected via an LFA, S-E + does not need to be protected using a repair tunnel since all + destinations normally reachable through E must therefore also be + protectable by an LFA; such an LFA is frequently termed a "link LFA". + Tunneled repair paths (which may be calculated per prefix) are only + required for links that do not have a link or per-prefix LFA. + + It should be noted that using the Q-space of E as a proxy for the + Q-space of each destination can result in failing to identify valid + remote LFAs. The extent to which this reduces the effective + protection coverage is topology dependent. + +5.2. Determining Tunnel Endpoints + + The repair tunnel endpoint needs to be a node in the network + reachable from S without traversing S-E. In addition, the repair + tunnel endpoint needs to be a node from which packets will normally + flow towards their destination without being attracted back to the + failed link S-E. + + Note that once released from the tunnel, the packet will be + forwarded, as normal, on the shortest path from the release point to + its destination. This may result in the packet traversing the router + E at the far end of the protected link S-E, but this is obviously not + required. + + The properties that are required of repair tunnel endpoints are as + follows: + + o The repair tunneled point MUST be reachable from the tunnel source + without traversing the failed link; and + + o when released from the tunnel, packets MUST proceed towards their + destination without being attracted back over the failed link. + + + + + +Bryant, et al. Standards Track [Page 8] + +RFC 7490 Remote LFA FRR April 2015 + + + Provided both these requirements are met, packets forwarded over the + repair tunnel will reach their destination and will not loop after a + single link failure. + + In some topologies it will not be possible to find a repair tunnel + endpoint that exhibits both the required properties. For example, if + the ring topology illustrated in Figure 1 had a cost of four for the + link B-C while the remaining links were the cost of one, then it + would not be possible to establish a tunnel from S to C (without + resorting to some form of source routing). + +5.2.1. Computing Repair Paths + + To compute the repair path for link S-E, it is necessary to determine + the set of routers that can be reached from S without traversing S-E + and match this with the set of routers from which the node E can be + reached by normal forwarding without traversing the link S-E. + + The approach used in this memo is as follows: + + o The method of computing the set of routers that can be reached + from S on the shortest path tree without traversing S-E is + described. This is called the S's P-space with respect to the + failure of link S-E. + + o The distance of the tunnel endpoint from the PLR is increased by + noting that S is able to use the P-space of its neighbors with + respect to the failure of link S-E since S can determine which + neighbor it will use as the next hop for the repair. This is + called the S's extended P-space with respect to the failure of + link S-E. The use of extended P-space allows greater repair + coverage and is the preferred approach. + + o Finally, two methods of computing the set of routers from which + the node E can be reached by normal forwarding without traversing + the link S-E. This is called the Q-space of E with respect to the + link S-E. + + The selection of the preferred node from the set of nodes that are in + both extended P-space and Q-space with respect to the S-E is + described in Section 5.2.2. + + A suitable cost-based algorithm to compute the set of nodes common to + both extended P-space and Q-space with respect to the S-E is provided + in Section 5.3. + + + + + + +Bryant, et al. Standards Track [Page 9] + +RFC 7490 Remote LFA FRR April 2015 + + +5.2.1.1. P-space + + The set of routers that can be reached from S on the shortest path + tree without traversing S-E is termed the P-space of S with respect + to the link S-E. This P-space can be obtained by computing a + Shortest Path Tree (SPT) rooted at S and excising the subtree reached + via the link S-E (including those routers that are members of an ECMP + that includes link S-E). The exclusion of routers reachable via an + ECMP that includes S-E prevents the forwarding subsystem from + attempting to execute a repair via the failed link S-E. Thus, for + example, if the Shortest Path First (SPF) computation stores at each + node the next hops to be used to reach that node from S, then the + node can be added to P-space if none of its next hops are link S-E. + In the case of Figure 1, this P-space comprises nodes A and B only. + Expressed in cost terms, the set of routers {P} are those for which + the shortest path cost S->P is strictly less than the shortest path + cost S->E->P. + +5.2.1.2. Extended P-space + + The description in Section 5.2.1.1 calculated router S's P-space + rooted at S itself. However, since router S will only use a repair + path when it has detected the failure of the link S-E, the initial + hop of the repair path need not be subject to S's normal forwarding + decision process. Thus, the concept of extended P-space is + introduced. Router S's extended P-space is the union of the P-spaces + of each of S's neighbors (N). This may be calculated by computing an + SPT at each of S's neighbors (excluding E) and excising the subtree + reached via the path N->S->E. Note this will excise those routers + that are reachable through all ECMPs that include link S-E. The use + of extended P-space may allow router S to reach potential repair + tunnel endpoints that were otherwise unreachable. In cost terms, a + router (P) is in extended P-space if the shortest path cost N->P is + strictly less than the shortest path cost N->S->E->P. In other + words, once the packet is forced to N by S, it is a lower cost for it + to continue on to P by any path except one that takes it back to S + and then across the S->E link. + + Since in the case of Figure 1 node A is a per-prefix LFA for the + destination node C, the set of extended P-space nodes with respect to + link S-E comprises nodes A, B, and C. Since node C is also in E's + Q-space with respect to link S-E, there is now a node common to both + extended P-space and Q-space that can be used as a repair tunnel + endpoint to protect the link S-E. + + + + + + + +Bryant, et al. Standards Track [Page 10] + +RFC 7490 Remote LFA FRR April 2015 + + +5.2.1.3. Q-space + + The set of routers from which the node E can be reached, by normal + forwarding without traversing the link S-E, is termed the Q-space of + E with respect to the link S-E. The Q-space can be obtained by + computing a reverse Shortest Path Tree (rSPT) rooted at E, with the + subtree that might traverse the protected link S-E excised (i.e., + those nodes that would send the packet via S-E plus those nodes that + have an ECMP set to E with one or more members of that ECMP set + traversing the protected link S-E). The rSPT uses the cost towards + the root rather than from it and yields the best paths towards the + root from other nodes in the network. In the case of Figure 1, the + Q-space of E with respect to S-E comprises nodes C and D only. + Expressed in cost terms, the set of routers {Q} are those for which + the shortest path cost Q<-E is strictly less than the shortest path + cost Q<-S<-E. In Figure 1, the intersection of the E's Q-space with + respect to S-E with S's P-space with respect to S-E defines the set + of viable repair tunnel endpoints, known as "PQ nodes". As can be + seen in the case of Figure 1, there is no common node and hence no + viable repair tunnel endpoint. However, when the extended P-space + (Section 5.2.1.2) at S with respect to S-E is considered, a suitable + intersection is found at C. + + Note that the Q-space calculation could be conducted for each + individual destination and a per-destination repair tunnel end point + determined. However, this would, in the worst case, require an SPF + computation per destination that is not currently considered to be + scalable. Therefore, the Q-space of E with respect to link S-E is + used as a proxy for the Q-space of each destination. This + approximation is obviously correct since the repair is only used for + the set of destinations which were, prior to the failure, routed + through node E. This is analogous to the use of link LFAs rather + than per-prefix LFAs. + +5.2.2. Selecting Repair Paths + + The mechanisms described above will identify all the possible repair + tunnel endpoints that can be used to protect a particular link. In a + well-connected network, there are likely to be multiple possible + release points for each protected link. All will deliver the packets + correctly, so arguably, it does not matter which is chosen. However, + one repair tunnel endpoint may be preferred over the others on the + basis of path cost or some other selection criteria. + + There is no technical requirement for the selection criteria to be + consistent across all routers, but such consistency may be desirable + from an operational point of view. In general, there are advantages + in choosing the repair tunnel endpoint closest (shortest metric) to + + + +Bryant, et al. Standards Track [Page 11] + +RFC 7490 Remote LFA FRR April 2015 + + + S. Choosing the closest maximizes the opportunity for the traffic to + be load balanced once it has been released from the tunnel. For + consistency in behavior, it is RECOMMENDED that the member of the set + of routers {PQ} with the lowest cost S->P be the default choice for + P. In the event of a tie, the router with the lowest node identifier + SHOULD be selected. + + It is a local matter whether the repair path selection policy used by + the router favors LFA repairs over RLFA repairs. An LFA repair has + the advantage of not requiring the use of a tunnel; however, network + manageability considerations may lead to a repair strategy that uses + a remote LFA more frequently [LFA-MANAGE]. + + As described in [RFC5286], always selecting a PQ node that is + downstream to the destination with respect to the repairing node + prevents the formation of loops when the failure is worse than + expected. The use of downstream nodes reduces the repair coverage, + and operators are advised to determine whether adequate coverage is + achieved before enabling this selection feature. + +5.3. A Cost-Based RLFA Algorithm + + The preceding text has described the computation of the remote LFA + repair target (PQ) in terms of the intersection of two reachability + graphs computed using an SPF algorithm. This section describes a + method of computing the remote LFA repair target for a specific + failed link using a cost-based algorithm. The pseudocode provided in + this section avoids unnecessary SPF computations; for the sake of + readability, it does not otherwise try to optimize the code. The + algorithm covers the case where the repair first hop is reached via a + broadcast or NBMA link such as a LAN. It also covers the case where + the P or Q node is attached via such a link. It does not cover the + case where the failed interface is a broadcast or NBMA link. To + address that case it is necessary to compute the Q-space of each + neighbor of the repairing router reachable through the LAN, i.e., to + treat the pseudonode [RFC1195] as a node failure; this is because the + Q-spaces of the neighbors of the pseudonode may be disjoint and + require use of a neighbor-specific PQ node. The reader is referred + to [NODE-PROTECTION] for further information on the use of RLFA for + node repairs. + + The following notation is used: + + o D_opt(a,b) is the shortest distance from node a to node b as + computed by the SPF. + + o dest is the packet destination. + + + + +Bryant, et al. Standards Track [Page 12] + +RFC 7490 Remote LFA FRR April 2015 + + + o fail_intf is the failed interface (S-E in the example). + + o fail_intf.remote_node is the node reachable over interface + fail_intf (node E in the example). + + o intf.remote_node is the set of nodes reachable over interface + intf. + + o root is the root of the SPF calculation. + + o self is the node carrying out the computation. + + o y is the node in the network under consideration. + + o y.pseudonode is true if y is a pseudonode. + + ////////////////////////////////////////////////////////////////// + // + // Main Function + + + + ////////////////////////////////////////////////////////////////// + // + // We have already computed the forward SPF from self to all nodes + // y in network and thus we know D_opt (self, y). This is needed + // for normal forwarding. + // However, for completeness: + + Compute_and_Store_Forward_SPF(self) + + // To extend P-space, we compute the SPF at each neighbor except + // the neighbor that is reached via the link being protected. + // We will also need D_opt(fail_intf.remote_node,y), so we + // compute that at the same time. + + Compute_Neighbor_SPFs() + + // Compute the set of nodes {P} reachable other than via the + // failed link. + + Compute_Extended_P_Space(fail_intf) + + // Compute the set of nodes that can reach the node on the far + // side of the failed link without traversing the failed link. + + Compute_Q_Space(fail_intf) + + + + +Bryant, et al. Standards Track [Page 13] + +RFC 7490 Remote LFA FRR April 2015 + + + // Compute the set of candidate RLFA tunnel endpoints. + + Intersect_Extended_P_and_Q_Space() + + // Make sure that we cannot get looping repairs when the + // failure is worse than expected. + + if (guarantee_no_looping_on_worse_than_protected_failure) + Apply_Downstream_Constraint() + + // + // End of Main Function + // + ////////////////////////////////////////////////////////////////// + + ////////////////////////////////////////////////////////////////// + // + // Procedures + // + + + ///////////////////////////////////////////////////////////////// + // + // This computes the SPF from root and stores the optimum + // distance from root to each node y. + + Compute_and_Store_Forward_SPF(root) + Compute_Forward_SPF(root) + foreach node y in network + store D_opt(root,y) + + + + ///////////////////////////////////////////////////////////////// + // + // This computes the optimum distance from each neighbor (other + // than the neighbor reachable through the failed link) and + // every other node in the network. + // + // Note that we compute this for all neighbors, including the + // neighbor on the far side the failure. This is done on the + // expectation that more than one link will be protected and + // that the results are stored for later use. + // + + Compute_Neighbor_SPFs() + foreach interface intf in self + Compute_and_Store_Forward_SPF(intf.remote_node) + + + +Bryant, et al. Standards Track [Page 14] + +RFC 7490 Remote LFA FRR April 2015 + + + ///////////////////////////////////////////////////////////////// + // + // The reverse SPF computes the cost from each remote node to + // root. This is achieved by running the normal SPF algorithm + // but using the link cost in the direction from the next hop + // back towards root in place of the link cost in the direction + // away from root towards the next hop. + + Compute_and_Store_Reverse_SPF(root) + Compute_Reverse_SPF(root) + foreach node y in network + store D_opt(y,root) + + + + ///////////////////////////////////////////////////////////////// + // + // Calculate Extended P-space + // + // Note that the "strictly less than" operator is needed to + // avoid ECMP issues. + + Compute_Extended_P_Space(fail_intf) + foreach node y in network + y.in_extended_P_space = false + // Extend P-space to the P-spaces of all reachable + // neighbors + foreach interface intf in self + // Exclude failed interface, noting that + // the node reachable via that interface may be + // reachable via another interface (parallel path) + if (intf != fail_intf) + foreach neighbor n in intf.remote_node + // Apply RFC 5286 Inequality 1 + if ( D_opt(n, y) < + D_opt(n,self) + D_opt(self, y)) + y.in_extended_P_space = true + + ///////////////////////////////////////////////////////////////// + // + // Compute the Nodes in Q-space + // + + Compute_Q_Space(fail_intf) + // Compute the cost from every node in the network to the + // node normally reachable across the failed link + Compute_and_Store_Reverse_SPF(fail_intf.remote_node) + + + + +Bryant, et al. Standards Track [Page 15] + +RFC 7490 Remote LFA FRR April 2015 + + + // Compute the cost from every node in the network to self + Compute_and_Store_Reverse_SPF(self) + + foreach node y in network + if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + + D_opt(self,fail_intf.remote_node) ) + y.in_Q_space = true + else + y.in_Q_space = false + + + + ///////////////////////////////////////////////////////////////// + // + // Compute Set of Nodes in Both Extended P-space and in Q-space + + Intersect_Extended_P_and_Q_Space() + foreach node y in network + if ( y.in_extended_P_space && y.in_Q_space && + y.pseudonode == False) + y.valid_tunnel_endpoint = true + else + y.valid_tunnel_endpoint = false + + + ///////////////////////////////////////////////////////////////// + // + // A downstream route is one where the next hop is strictly + // closer to the destination. By sending the packet to a + // PQ node that is downstream, we know that if the PQ node + // detects a failure it will not loop the packet back to self. + // This is useful when there are two failures or when a node has + // failed rather than a link. + + Apply_Downstream_Constraint() + foreach node y in network + if (y.valid_tunnel_endpoint) + Compute_and_Store_Forward_SPF(y) + if ((D_opt(y,dest) < D_opt(self,dest)) + y.valid_tunnel_endpoint = true + else + y.valid_tunnel_endpoint = false + + + // + ///////////////////////////////////////////////////////////////// + + + + + +Bryant, et al. Standards Track [Page 16] + +RFC 7490 Remote LFA FRR April 2015 + + +5.4. Interactions with IS-IS Overload, RFC 6987, and Costed Out Links + + Since normal link state routing takes into account the IS-IS overload + bit, OSPF stub router advertisement [RFC6987], and costed out links + (as described in Section 3.5 of [RFC5286]), the forward SPFs + performed by the PLR rooted at the neighbors of the PLR also need to + take this into account. A repair tunnel path from a neighbor of the + PLR to a repair tunnel endpoint will generally avoid the nodes and + links excluded by the IGP overload/costing-out rules. However, there + are two situations where this behavior may result in a repair path + traversing a link or router that should be excluded: + + 1. One situation is when the first hop on the repair tunnel path + (from the PLR to a direct neighbor) does not follow the IGP + shortest path. In this case, the PLR MUST NOT use a repair + tunnel path whose first hop is along a link that has a cost or + reverse cost equal to MaxLinkMetric (for OSPF) or the maximum + cost (for IS-IS) or whose first hop has the overload bit set (for + IS-IS). + + 2. The other situation is when the IS-IS overload bit and the + mechanism of [RFC6987] only prevent transit traffic from + traversing a node; they do not prevent traffic destined to a + node. The per-neighbor forward SPFs using the standard IGP + overload rules will not prevent a PLR from choosing a repair + tunnel endpoint that is advertising a desire to not carry transit + traffic. Therefore, the PLR MUST NOT use a repair tunnel + endpoint with the IS-IS overload bit set or where all outgoing + interfaces have the cost set to MaxLinkMetric for OSPF. + +6. Example Application of Remote LFAs + + An example of a commonly deployed topology that is not fully + protected by LFAs alone is shown in Figure 3. Provider Edge (PE)1 + and PE2 are connected in the same site. P1 and P2 may be + geographically separated (intersite). In order to guarantee the + lowest latency path from/to all other remote PEs, normally the + shortest path follows the geographical distance of the site + locations. Therefore, to ensure this, a lower IGP metric (5) is + assigned between PE1 and PE2. A high metric (1000) is set on the + P-PE links to prevent the PEs being used for transit traffic. The + PEs are not individually dual-homed in order to reduce costs. + + This is a common topology in Service Provider (SP) networks. + + + + + + + +Bryant, et al. Standards Track [Page 17] + +RFC 7490 Remote LFA FRR April 2015 + + + When a failure occurs on the link between PE1 and P1, PE1 does not + have an LFA for traffic reachable via P1. Similarly, by symmetry, if + the link between PE2 and P2 fails, PE2 does not have an LFA for + traffic reachable via P2. + + Increasing the metric between PE1 and PE2 to allow the LFA would + impact the normal traffic performance by potentially increasing the + latency. + + | 100 | + -P1---------P2- + \ / + 1000 \ / 1000 + PE1---PE2 + 5 + + Figure 3: Example SP Topology + + Clearly, full protection can be provided using the techniques + described in this document by PE1 choosing P2 as the remote LFA + repair target node and PE2 choosing P1 as the remote LFA repair + target. + +7. Node Failures + + When the failure is a node failure rather than a point-to-point link + failure, there is a danger that the RLFA repair will loop. This is + discussed in detail in [IP-FRR]. In summary, the problem is that two + or more of E's neighbors, each with E as the next hop to some + destination D, may attempt to repair a packet addressed to + destination D via the other neighbor and then E, thus causing a loop + to form. A similar problem exists in the case of a shared risk link + group failure where the PLR for each failure attempts to repair via + the other failure. As will be noted from [IP-FRR], this can rapidly + become a complex problem to address. + + There are a number of ways to minimize the probability of a loop + forming when a node failure occurs, and there exists the possibility + that two of E's neighbors may form a mutual repair. + + 1. Detect when a packet has arrived on some interface I that is also + the interface used to reach the first hop on the RLFA path to the + remote LFA repair target, and drop the packet. This is useful in + the case of a ring topology. + + + + + + + +Bryant, et al. Standards Track [Page 18] + +RFC 7490 Remote LFA FRR April 2015 + + + 2. Require that the path from the remote LFA repair target to + destination D never passes through E (including in the ECMP + case), i.e., only use node protecting paths in which the cost + from the remote LFA repair target to D is strictly less than the + cost from the remote LFA repair target to E plus the cost E to D. + + 3. Require that where the packet may pass through another neighbor + of E, that node is down stream (i.e., strictly closer to D than + the repairing node). This means that some neighbor of E (X) can + repair via some other neighbor of E (Y), but Y cannot repair via + X. + + Case 1 accepts that loops may form and suppresses them by dropping + packets. Dropping packets may be considered less detrimental than + looping packets. This approach may also lead to dropping some + legitimate packets. Cases 2 and 3 above prevent the formation of a + loop but at the expense of a reduced repair coverage and at the cost + of additional complexity in the algorithm to compute the repair path. + Alternatively, one might choose to assume that the probability of a + node failure is sufficiently rare that the issue of looping RLFA + repairs can be ignored. + + The probability of a node failure and the consequences of node + failure in any particular topology will depend on the node design, + the particular topology in use, and the strategy adopted under node + failure. It is recommended that a network operator perform an + analysis of the consequences and probability of node failure in their + network and determine whether the incidence and consequence of + occurrence are acceptable. + + This topic is further discussed in [NODE-PROTECTION]. + +8. Operation in an LDP Environment + + Where this technique is used in an MPLS network using LDP [RFC5036], + and S is a transit node, S will need to swap the top label in the + stack for the remote LFA repair target's (PQ's) label to the + destination and to then push its own label for the remote LFA repair + target. + + In the example, S in Figure 2 already has the first hop (A) label for + the remote LFA repair target (C) as a result of the ordinary + operation of LDP. To get the remote LFA repair target's label (C's + label) for the destination (D), S needs to establish a targeted LDP + session with C. The label stack for normal operation and RLFA + operation is shown below in Figure 4. + + + + + +Bryant, et al. Standards Track [Page 19] + +RFC 7490 Remote LFA FRR April 2015 + + + +-----------------+ +-----------------+ +-----------------+ + | datalink | | datalink | | datalink | + +-----------------+ +-----------------+ +-----------------+ + | S's label for D | | E's label for D | | A's label for C | + +-----------------+ +-----------------+ +-----------------+ + | Payload | | Payload | | C's label for D | + +-----------------+ +-----------------+ +-----------------+ + X Y | Payload | + +-----------------+ + Z + + X = Normal label stack packet arriving at S + Y = Normal label stack packet leaving S + Z = RLFA label stack to D via C as the remote LFA repair target + + Figure 4 + + To establish a targeted LDP session with a candidate remote LFA + repair target node, the repairing node (S) needs to know what IP + address the remote LFA repair target is willing to use for targeted + LDP sessions. Ideally, this is provided by the remote LFA repair + target advertising this address in the IGP in use. Which address is + used, how this is advertised in the IGP, and whether this is a + special IP address or an IP address also used for some other purpose + is out of scope for this document and must be specified in an + IGP-specific RFC. + + In the absence of a protocol to learn the preferred IP address for + targeted LDP, an LSR should attempt a targeted LDP session with the + Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] [OSPF-RI] unless it + is configured otherwise. + + No protection is available until the TLDP session has been + established and a label for the destination has been learned from the + remote LFA repair target. If for any reason the TLDP session cannot + be established, an implementation SHOULD advise the operator about + the protection setup issue through the network management system. + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 20] + +RFC 7490 Remote LFA FRR April 2015 + + +9. Analysis of Real World Topologies + + This section gives the results of analyzing a number of real world + service provider topologies collected between the end of 2012 and + early 2013. + +9.1. Topology Details + + The figure below characterizes each topology (topo) studied in terms + of: + + o the number of nodes (# nodes) excluding pseudonodes; + + o the number of bidirectional links (# links) including parallel + links and links to and from pseudonodes; + + o the number of node pairs that are connected by one or more links + (# pairs); + + o the number of node pairs that are connected by more than one + (i.e., parallel) link (# para); and + + o the number of links (excluding pseudonode links, which are by + definition asymmetric) that have asymmetric metrics (# asym). + + +------+---------+---------+---------+--------+--------+ + | topo | # nodes | # links | # pairs | # para | # asym | + +------+---------+---------+---------+--------+--------+ + | 1 | 315 | 570 | 560 | 10 | 3 | + | 2 | 158 | 373 | 312 | 33 | 0 | + | 3 | 655 | 1768 | 1314 | 275 | 1195 | + | 4 | 1281 | 2326 | 2248 | 70 | 10 | + | 5 | 364 | 811 | 659 | 80 | 86 | + | 6 | 114 | 318 | 197 | 101 | 4 | + | 7 | 55 | 237 | 159 | 67 | 2 | + | 8 | 779 | 1848 | 1441 | 199 | 437 | + | 9 | 263 | 482 | 413 | 41 | 12 | + | 10 | 86 | 375 | 145 | 64 | 22 | + | 11 | 162 | 1083 | 351 | 201 | 49 | + | 12 | 380 | 1174 | 763 | 231 | 0 | + | 13 | 1051 | 2087 | 2037 | 48 | 64 | + | 14 | 92 | 291 | 204 | 64 | 2 | + +------+---------+---------+---------+--------+--------+ + + + + + + + + +Bryant, et al. Standards Track [Page 21] + +RFC 7490 Remote LFA FRR April 2015 + + +9.2. LFA Only + + The figure below shows the percentage of protected destinations (% + prot) and the percentage of guaranteed node protected destinations (% + gtd N) for the set of topologies characterized in Section 9.1 + achieved using only LFA repairs. + + These statistics were generated by considering each node and then + considering each link to each next hop to each destination. The + percentage of such links across the entire network that are protected + against link failure was determined. This is the percentage of + protected destinations. If a link is protected against the failure + of the next hop node, this is considered Guaranteed Node Protecting + (GNP) and the percentage of guaranteed node protected destinations is + calculated using the same method used for calculating the link + protection coverage. + + GNP is identical to node-protecting as defined in [RFC6571] and does + not include the additional node protection coverage obtained by the + de facto node-protecting condition described in [RFC6571]. + + +------+--------+---------+ + | topo | % prot | % gtd N | + +------+--------+---------+ + | 1 | 78.5 | 36.9 | + | 2 | 97.3 | 52.4 | + | 3 | 99.3 | 58 | + | 4 | 83.1 | 63.1 | + | 5 | 99 | 59.1 | + | 6 | 86.4 | 21.4 | + | 7 | 93.9 | 35.4 | + | 8 | 95.3 | 48.1 | + | 9 | 82.2 | 49.5 | + | 10 | 98.5 | 14.9 | + | 11 | 99.6 | 24.8 | + | 12 | 99.5 | 62.4 | + | 13 | 92.4 | 51.6 | + | 14 | 99.3 | 48.6 | + +------+--------+---------+ + +9.3. RLFA + + The figure below shows the percentage of protected destinations (% + prot) and % guaranteed node protected destinations (% gtd N) for RLFA + protection in the topologies studies. In addition, it shows the + percentage of destinations using an RLFA repair (% PQ) together with + the total number of unidirectional RLFA targeted LDP sessions + established (# PQ), and the number of PQ sessions that would be + + + +Bryant, et al. Standards Track [Page 22] + +RFC 7490 Remote LFA FRR April 2015 + + + required for complete protection but that could not be established + because there was no PQ node, i.e., the number of cases whether + neither LFA or RLFA protection was possible (no PQ). It also shows + the 50 (p50), 90 (p90), and 100 (p100) percentiles for the number of + individual LDP sessions terminating at an individual node (whether + used for TX, RX, or both). + + For example, if there were LDP sessions that required A->B, A->C, + C->A, and C->D, these would be counted as 2, 1, 2, and 1 at nodes A, + B, C, and D respectively because: + + A has two sessions (to nodes B and C); + + B has one session (to node A); + + C has two sessions (to nodes A and D); and + + D has one session (to node D). + + In this study, remote LFA is only used when necessary, i.e., when + there is at least one destination that is not reparable by a per + destination LFA and a single remote LFA tunnel is used (if available) + to repair traffic to all such destinations. The remote LFA repair + target points are computed using extended P-space and choosing the PQ + node that has the lowest metric cost from the repairing node. + + +------+--------+--------+------+------+-------+-----+-----+------+ + | topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 | + +------+--------+--------+------+------+-------+-----+-----+------+ + | 1 | 99.7 | 53.3 | 21.2 | 295 | 3 | 1 | 5 | 14 | + | 2 | 97.5 | 52.4 | 0.2 | 7 | 40 | 0 | 0 | 2 | + | 3 | 99.999 | 58.4 | 0.7 | 63 | 5 | 0 | 1 | 5 | + | 4 | 99 | 74.8 | 16 | 1424 | 54 | 1 | 3 | 23 | + | 5 | 99.5 | 59.5 | 0.5 | 151 | 7 | 0 | 2 | 7 | + | 6 | 100 | 34.9 | 13.6 | 63 | 0 | 1 | 2 | 6 | + | 7 | 99.999 | 40.6 | 6.1 | 16 | 2 | 0 | 2 | 4 | + | 8 | 99.5 | 50.2 | 4.3 | 350 | 39 | 0 | 2 | 15 | + | 9 | 99.5 | 55 | 17.3 | 428 | 5 | 1 | 2 | 67 | + | 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 | + | 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 | + | 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 | + | 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 | + | 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 | + +------+--------+--------+------+------+-------+-----+-----+------+ + + Another study [ISOCORE2010] confirms the significant coverage + increase provided by remote LFAs. + + + + +Bryant, et al. Standards Track [Page 23] + +RFC 7490 Remote LFA FRR April 2015 + + +9.4. Comparison of LFA and RLFA results + + The table below provides a side-by-side comparison of the LFA and the + remote LFA results. This shows a significant improvement in the + percentage of protected destinations and normally a modest + improvement in the percentage of guaranteed node protected + destinations. + + +------+--------+--------+---------+---------+ + | topo | LFA | RLFA | LFA | RLFA | + | | % prot | %prot | % gtd N | % gtd N | + +------+--------+--------+---------+---------+ + | 1 | 78.5 | 99.7 | 36.9 | 53.3 | + | 2 | 97.3 | 97.5 | 52.4 | 52.4 | + | 3 | 99.3 | 99.999 | 58 | 58.4 | + | 4 | 83.1 | 99 | 63.1 | 74.8 | + | 5 | 99 | 99.5 | 59.1 | 59.5 | + | 6 | 86.4 |100 | 21.4 | 34.9 | + | 7 | 93.9 | 99.999 | 35.4 | 40.6 | + | 8 | 95.3 | 99.5 | 48.1 | 50.2 | + | 9 | 82.2 | 99.5 | 49.5 | 55 | + | 10 | 98.5 | 99.6 | 14.9 | 14.1 | + | 11 | 99.6 | 99.9 | 24.8 | 24.9 | + | 12 | 99.5 | 99.999 | 62.4 | 62.8 | + | 13 | 92.4 | 97.5 | 51.6 | 54.6 | + | 14 | 99.3 |100 | 48.6 | 48.6 | + +------+--------+--------+---------+---------+ + + As shown in the table, remote LFA provides close to 100% prefix + protection against link failure in 11 of the 14 topologies studied + and provides a significant improvement in two of the remaining three + cases. Note that in an MPLS network, the tunnels to the PQ nodes are + always present as a property of an LDP-based deployment. + + In the small number of cases where there is no intersection between + the (extended) P-space and the Q-space, a number of solutions to + providing a suitable path between such disjoint regions in the + network have been discussed in the working group. For example, an + explicitly routed LSP between P and Q might be set up using RSVP-TE + or using Segment Routing [SEGMENT-ROUTING]. Such extended repair + methods are outside the scope of this document. + + + + + + + + + + +Bryant, et al. Standards Track [Page 24] + +RFC 7490 Remote LFA FRR April 2015 + + +10. Management and Operational Considerations + + The management of LFA and remote LFA is the subject of ongoing work + within the IETF [LFA-MANAGE], to which the reader is referred. + Management considerations may lead to a preference for the use of a + remote LFA over an available LFA. This preference is a matter for + the network operator and not a matter of protocol correctness. + + When the network reconverges, micro-loops [RFC5715] can form due to + transient inconsistencies in the forwarding tables of different + routers. If it is determined that micro-loops are a significant + issue in the deployment, then a suitable loop-free convergence + method, such as one of those described in [RFC5715], [RFC6976], or + [ULOOP-DELAY], should be implemented. + +11. Historical Note + + The basic concepts behind remote LFA were invented in 2002 and were + later included in [IP-FRR], submitted in 2004. + + [IP-FRR] targeted a 100% protection coverage and hence included + additional mechanisms on top of the remote LFA concept. The addition + of these mechanisms made the proposal very complex and + computationally intensive, and it was therefore not pursued as a + working group item. + + As explained in [RFC6571], the purpose of the LFA FRR technology is + not to provide coverage at any cost. A solution for this already + exists with MPLS-TE FRR. MPLS-TE FRR is a mature technology that is + able to provide protection in any topology thanks to the explicit + routing capability of MPLS-TE. + + The purpose of LFA FRR technology is to provide for a simple FRR + solution when such a solution is possible. The first step along this + simplicity approach was "local" LFA [RFC5286]. This specification of + "remote LFA" is a natural second step. + +12. Security Considerations + + The security considerations of [RFC5286] also apply. + + Targeted LDP sessions and MPLS tunnels are normal features of an MPLS + network, and their use in this application raises no additional + security concerns. + + IP repair tunnel endpoints (where used) SHOULD be assigned from a set + of addresses that are not reachable from outside the routing domain; + this would prevent their use as an attack vector. + + + +Bryant, et al. Standards Track [Page 25] + +RFC 7490 Remote LFA FRR April 2015 + + + Other than OAM traffic used to verify the correct operation of a + repair tunnel, only traffic that is being protected as a result of a + link failure is placed in a repair tunnel. The repair tunnel MUST + NOT be advertised by the routing protocol as a link that may be used + to carry normal user traffic or routing protocol traffic. + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for + IP Fast Reroute: Loop-Free Alternates", RFC 5286, + September 2008, <http://www.rfc-editor.org/info/rfc5286>. + + [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC + 5714, January 2010, + <http://www.rfc-editor.org/info/rfc5714>. + +13.2. Informative References + + [IP-FRR] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP + Fast Reroute using tunnels", Work in Progress, + draft-bryant-ipfrr-tunnels-03, November 2007. + + [ISOCORE2010] + So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) + Case Studies in Verizon's LDP Network", 13th Annual MPLS + Conference, 2010. + + [LFA-MANAGE] + Litkowski, S., Decraene, B., Filsfils, C., Raza, K., + Horneffer, M., and P. Sarkar, "Operational management of + Loop Free Alternates", Work in Progress, draft-ietf-rtgwg- + lfa-manageability-08, March 2015. + + [NODE-PROTECTION] + Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, + S., and H. Raghuveer, "Remote-LFA Node Protection and + Manageability", Work in Progress, draft-ietf-rtgwg-rlfa- + node-protection-01, December 2014. + + [OSPF-RI] Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP + Addresses in OSPF RI LSA", Work in Progress, draft-ietf- + ospf-routable-ip-address-02, April 2015. + + + +Bryant, et al. Standards Track [Page 26] + +RFC 7490 Remote LFA FRR April 2015 + + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, December 1990, + <http://www.rfc-editor.org/info/rfc1195>. + + [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994, + <http://www.rfc-editor.org/info/rfc1701>. + + [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995, + <http://www.rfc-editor.org/info/rfc1853>. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, + <http://www.rfc-editor.org/info/rfc2328>. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001, + <http://www.rfc-editor.org/info/rfc3032>. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, October 2007, + <http://www.rfc-editor.org/info/rfc5036>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008, + <http://www.rfc-editor.org/info/rfc5305>. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008, + <http://www.rfc-editor.org/info/rfc5340>. + + [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free + Convergence", RFC 5715, January 2010, + <http://www.rfc-editor.org/info/rfc5715>. + + [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic + Engineering in IS-IS", RFC 6119, February 2011, + <http://www.rfc-editor.org/info/rfc6119>. + + [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, + B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free + Alternate (LFA) Applicability in Service Provider (SP) + Networks", RFC 6571, June 2012, + <http://www.rfc-editor.org/info/rfc6571>. + + + + + + + +Bryant, et al. Standards Track [Page 27] + +RFC 7490 Remote LFA FRR April 2015 + + + [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., + Francois, P., and O. Bonaventure, "Framework for Loop-Free + Convergence Using the Ordered Forwarding Information Base + (oFIB) Approach", RFC 6976, July 2013, + <http://www.rfc-editor.org/info/rfc6976>. + + [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. + McPherson, "OSPF Stub Router Advertisement", RFC 6987, + September 2013, <http://www.rfc-editor.org/info/rfc6987>. + + [SEGMENT-ROUTING] + Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., + Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., + and E. Crabbe, "Segment Routing Architecture", Work in + Progress, draft-ietf-spring-segment-routing-01, February + 2015. + + [ULOOP-DELAY] + Litkowski, S., Decraene, B., Filsfils, C., and P. + Francois, "Microloop prevention by introducing a local + convergence delay", Work in Progress, draft-litkowski- + rtgwg-uloop-delay-03, February 2014. + +Acknowledgements + + The authors wish to thank Levente Csikor and Chris Bowers for their + contribution to the cost-based algorithm text. The authors thank + Alia Atlas, Ross Callon, Stephane Litkowski, Bharath R, Pushpasis + Sarkar, and Adrian Farrel for their review of this document. + + + + + + + + + + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 28] + +RFC 7490 Remote LFA FRR April 2015 + + +Authors' Addresses + + Stewart Bryant + Cisco Systems + 9-11 New Square, + Bedfont Lakes, + Feltham, + Middlesex TW14 8HA + United Kingdom + + EMail: stbryant@cisco.com + + + Clarence Filsfils + Cisco Systems + De Kleetlaan 6a + 1831 Diegem + Belgium + + EMail: cfilsfil@cisco.com + + + Stefano Previdi + Cisco Systems + + EMail: sprevidi@cisco.com + + + Mike Shand + Independent Contributor + + EMail: imc.shand@gmail.com + + + Ning So + Vinci Systems + + EMail: ningso@vinci-systems.com + + + + + + + + + + + + + +Bryant, et al. Standards Track [Page 29] + |