| < draft-ietf-rtgwg-remote-lfa-10.txt | draft-ietf-rtgwg-remote-lfa-11.txt > | |||
|---|---|---|---|---|
| Network Working Group S. Bryant | Network Working Group S. Bryant | |||
| Internet-Draft C. Filsfils | Internet-Draft C. Filsfils | |||
| Intended status: Standards Track S. Previdi | Intended status: Standards Track S. Previdi | |||
| Expires: July 10, 2015 Cisco Systems | Expires: August 3, 2015 Cisco Systems | |||
| M. Shand | M. Shand | |||
| Independent Contributor | Independent Contributor | |||
| N. So | N. So | |||
| Vinci Systems | Vinci Systems | |||
| January 6, 2015 | January 30, 2015 | |||
| Remote Loop-Free Alternate Fast Re-Route | Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR) | |||
| draft-ietf-rtgwg-remote-lfa-10 | draft-ietf-rtgwg-remote-lfa-11 | |||
| Abstract | Abstract | |||
| This document describes an extension to the basic IP fast re-route | This document describes an extension to the basic IP fast re-route | |||
| mechanism described in RFC5286, that provides additional backup | mechanism described in RFC5286, that provides additional backup | |||
| connectivity for point to point link failures when none can be | connectivity for point to point link failures when none can be | |||
| provided by the basic mechanisms. | provided by the basic mechanisms. | |||
| Requirements Language | Requirements Language | |||
| skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
| 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 July 10, 2015. | This Internet-Draft will expire on August 3, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 | 4. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6 | 4.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 | |||
| 4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7 | 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7 | 5. Construction of Repair Paths . . . . . . . . . . . . . . . . 8 | |||
| 4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8 | 5.1. Identifying Required Tunneled Repair Paths . . . . . . . 8 | |||
| 4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8 | 5.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8 | |||
| 4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11 | 5.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 9 | |||
| 4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11 | 5.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11 | |||
| 4.4. Interactions with IS-IS Overload, RFC6987, and Costed | 5.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 12 | |||
| Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.4. Interactions with IS-IS Overload, RFC6987, and Costed | |||
| 5. Example Application of Remote LFAs . . . . . . . . . . . . . 17 | Out Links . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 | 6. Example Application of Remote LFAs . . . . . . . . . . . . . 18 | |||
| 7. Operation in an LDP environment . . . . . . . . . . . . . . . 19 | 7. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20 | 8. Operation in an LDP environment . . . . . . . . . . . . . . . 20 | |||
| 8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 | 9. Analysis of Real World Topologies . . . . . . . . . . . . . . 21 | |||
| 8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 21 | 9.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 9.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23 | 9.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 9. Management and Operational Considerations . . . . . . . . . . 24 | 9.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 24 | |||
| 10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. Management and Operational Considerations . . . . . . . . . . 25 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 11. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | |||
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 14.2. Informative References . . . . . . . . . . . . . . . . . 26 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 | 15.2. Informative References . . . . . . . . . . . . . . . . . 27 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 1. Terminology | 1. Introduction | |||
| RFC 5714 [RFC5714] describes a framework for IP Fast Re-route (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 | ||||
| because there is no neighbor of the point of local repair (PLR) that | ||||
| has a cost to the destination without traversing the failure that is | ||||
| cheaper than the cost to the destination via the failure. | ||||
| The method described in this document extends 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 | This document uses the terms defined in [RFC5714]. This section | |||
| defines additional terms that are used in this document. | defines additional terms that are used in this document. | |||
| FIB Forwarding Information (data)Base. The database used | ||||
| by a packet forwarder to determine the actions it | ||||
| should take on a packet it is processing. | ||||
| Repair tunnel A tunnel established for the purpose of providing a | Repair tunnel A tunnel established for the purpose of providing a | |||
| virtual neighbor which is a Loop Free Alternate. | virtual neighbor which is a Loop Free Alternate. | |||
| P-space P-space of a router with respect to a protected link | P-space The P-space of a router with respect to a protected | |||
| is the set of routers reachable from that specific | link is the set of routers reachable from that | |||
| router using the pre-convergence FIB, without any path | specific router using the pre-convergence shortest | |||
| (including equal cost path splits) transiting that | paths, without any of those paths (including equal | |||
| protected link. | cost path splits) transiting that protected link. | |||
| For example, the P-space of S with respect to link | For example, the P-space of S with respect to link | |||
| S-E, is the set of routers that S can reach without | S-E, is the set of routers that S can reach without | |||
| using the protected link S-E. | using the protected link S-E. | |||
| Extended P-space | Extended P-space | |||
| Consider the set of neighbours of a router protecting | Consider the set of neighbours of a router protecting | |||
| a link. Exclude from that set of routers the router | a link. Exclude from that set of routers the router | |||
| reachable over the protected link. The extended | reachable over the protected link. The extended | |||
| P-space of the protecting router with respect to the | P-space of the protecting router with respect to the | |||
| protected link is the union of the P-spaces of the | protected link is the union of the P-spaces of the | |||
| neighbours in that set of neighbours with respect to | neighbours in that set of neighbours with respect to | |||
| the protected link (see Section 4.2.1.2). | the protected link (see Section 5.2.1.2). | |||
| Q-space Q-space of a router with respect to a protected link | Q-space Q-space of a router with respect to a protected link | |||
| is the set of routers from which that specific router | is the set of routers from which that specific router | |||
| can be reached without any path (including equal cost | can be reached without any path (including equal cost | |||
| path splits) transiting that protected link. | path splits) transiting that protected link. | |||
| PQ node A PQ node of a node S with respect to a protected link | PQ node A PQ node of a node S with respect to a protected link | |||
| S-E is a node which is a member of both the P-space | S-E is a node which is a member of both the P-space | |||
| (or the extended P-space) of S with respect to that | (or the extended P-space) of S with respect to that | |||
| protected link S-E and the Q-space of E with respect | protected link S-E and the Q-space of E with respect | |||
| to that protected link S-E. A repair tunnel endpoint | to that protected link S-E. A repair tunnel endpoint | |||
| is chosen from the set of PQ-nodes. | is chosen from the set of PQ-nodes. | |||
| Remote LFA (RLFA) The use of a PQ node rather than a neighbour of | Remote LFA (RLFA) The use of a PQ node rather than a neighbour of | |||
| the repairing node as the next hop in an LFA repair | the repairing node as the next hop in an LFA repair | |||
| [RFC5286]. | [RFC5286]. | |||
| In this document we use the notation X-Y to mean the path from X to Y | In this document the notation X-Y is used to mean the path from X to | |||
| over the link directly connecting X and Y, whilst the notation X->Y | Y over the link directly connecting X and Y, whilst the notation X->Y | |||
| refers to the shortest path from X to Y via some set of unspecified | 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 | nodes including the null set (i.e. Including over a link directly | |||
| connecting X and Y). | connecting X and Y). | |||
| 2. Introduction | 3. Overview of Solution | |||
| RFC 5714 [RFC5714] describes a framework for IP Fast Re-route (IPFRR) | The problem of LFA IPFRR reachability in some networks is illustrated | |||
| and provides a summary of various proposed IPFRR solutions. A basic | by the network fragment shown in Figure 1 below. | |||
| 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 illustrated in Figure 1 below. | ||||
| S---E | S---E | |||
| / \ | / \ | |||
| A D | A D | |||
| \ / | \ / | |||
| B---C | B---C | |||
| Figure 1: A simple ring topology | Figure 1: A simple ring topology | |||
| If all link costs are equal, traffic transiting link S-E cannot be | If all link costs are equal, traffic transiting link S-E cannot be | |||
| fully protected by LFAs. The destination C is an ECMP from S, and so | fully protected by LFAs. The destination C is an ECMP from S, and so | |||
| traffic to C can be protected when S-E fails, but traffic to D and E | traffic to C can be protected when S-E fails, but traffic to D and E | |||
| are not protectable using LFAs. | are not protectable using LFAs. | |||
| This document describes extensions to the basic repair mechanism in | This document describes extensions to the basic repair mechanism in | |||
| which tunnels are used to provide additional logical links which can | which tunnels are used to provide additional logical links which can | |||
| then be used as loop free alternates where none exist in the original | 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; | 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 | 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 E's Q-space; these | that can reach E without going through S-E will be in E's Q-space | |||
| are D and C. B has equal-cost paths via B-A-S-E and B-C-D-E and so | with respect to link S-E; these are D and C. B has equal-cost paths | |||
| may go through S-E. The single node in both S's extended P-space and | to E via B-A-S-E and B-C-D-E and so the forwarder at S might choose | |||
| E's Q-space is C; thus node C is selected as the repair tunnel's end- | to send a packet to E via link S-E. Hence B is not in the Q-space of | |||
| point. Thus, if a tunnel is provided between S and C as shown in | E with respect to link S-E. The single node in both S's extended | |||
| Figure 2 then C, now being a direct neighbor of S would become an LFA | P-space and E's Q-space is C; thus node C is selected as the repair | |||
| for D and E. The definition of (extended-)P space and Q space are | tunnel's end-point. Thus, if a tunnel is provided between S and C as | |||
| provided in Section 1 and details of the calculation of the tunnel | shown in Figure 2 then C, now being a direct neighbor of S would | |||
| end points is provided in Section 4.2. | 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 is provided in Section 5.2. | ||||
| The non-failure traffic distribution is not disrupted by the | The non-failure traffic distribution is not disrupted by the | |||
| provision of such a tunnel since it is only used for repair traffic | provision of such a tunnel since it is only used for repair traffic | |||
| and MUST NOT be used for normal traffic. Note that OAM traffic | and MUST NOT be used for normal traffic. Note that Operations and | |||
| specifically to verify the viability of the repair MAY traverse the | Maintenance (OAM) traffic specifically to verify the viability of the | |||
| tunnel prior to a failure. | repair MAY traverse the tunnel prior to a failure. | |||
| S---E | S---E | |||
| / \ \ | / \ \ | |||
| A \ D | A \ D | |||
| \ \ / | \ \ / | |||
| B---C | B---C | |||
| Figure 2: The addition of a tunnel | Figure 2: The addition of a tunnel | |||
| The use of this technique is not restricted to ring based topologies, | The use of this technique is not restricted to ring based topologies, | |||
| but is a general mechanism which can be used to enhance the | but is a general mechanism which can be used to enhance the | |||
| protection provided by LFAs. A study of the protection achieved | protection provided by LFAs. A study of the protection achieved | |||
| using remote LFA in typical service provider core networks is | using remote LFA in typical service provider core networks is | |||
| provided in Section 8, and a side by side comparison between LFA and | provided in Section 9, and a side by side comparison between LFA and | |||
| remote LFA is provided in Section 8.4. | remote LFA is provided in Section 9.4. | |||
| Remote LFA is suitable for incremental deployment within a network, | Remote LFA is suitable for incremental deployment within a network, | |||
| including a network that is already deploying LFA. Computation of | including a network that is already deploying LFA. Computation of | |||
| the repair path requires acceptable CPU resources, and takes place | the repair path requires acceptable CPU resources, and takes place | |||
| exclusively on the repairing node. In MPLS networks the targeted LDP | exclusively on the repairing node. In MPLS networks the targeted LDP | |||
| protocol needed to learn the label binding at the repair tunnel | protocol needed to learn the label binding at the repair tunnel | |||
| endpoint is a well understood and widely deployed technology. | endpoint Section 8 is a well understood and widely deployed | |||
| technology. | ||||
| The technique described in this document is directed at providing | The technique described in this document is directed at providing | |||
| repairs in the case of link failures. Considerations regarding node | repairs in the case of link failures. Considerations regarding node | |||
| failures are discussed in Section 6. This memo describes a solution | 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 | 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 | 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 | 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 | 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 | however cover the more complicated case where the failed interface is | |||
| a broadcast or non-broadcast multi-access (NBMA) link. | a broadcast or non-broadcast multi-access (NBMA) link. | |||
| This document considers the case when the repair path is confined to | 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 | 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 | other cases, the chosen PQ node should be regarded as a tunnel | |||
| adjacency of the repairing node, and the considerations described in | adjacency of the repairing node, and the considerations described in | |||
| Section 6 of [RFC5286] taken into account. | Section 6 of [RFC5286] taken into account. | |||
| 3. Repair Paths | 4. Repair Paths | |||
| As with LFA FRR, when a router detects an adjacent link failure, it | 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 | uses one or more repair paths in place of the failed link. Repair | |||
| paths are pre-computed in anticipation of later failures so they can | paths are pre-computed in anticipation of later failures so they can | |||
| be promptly activated when a failure is detected. | be promptly activated when a failure is detected. | |||
| A tunneled repair path tunnels traffic to some staging point in the | 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 | network from which it is known that, in the absence of a worse than | |||
| anticipated failure, the traffic will travel to its destination using | anticipated failure, the traffic will travel to its destination using | |||
| normal forwarding without looping back. This is equivalent to | normal forwarding without looping back. This is equivalent to | |||
| providing a virtual loop-free alternate to supplement the physical | providing a virtual loop-free alternate to supplement the physical | |||
| loop-free alternates. Hence the name "Remote LFA FRR". In its | loop-free alternates. Hence the name "Remote LFA FRR". In its | |||
| simplest form, when a link cannot be entirely protected with local | simplest form, when a link cannot be entirely protected with local | |||
| LFA neighbors, the protecting router seeks the help of a remote LFA | LFA neighbors, the protecting router seeks the help of a remote LFA | |||
| staging point. Network manageability considerations may lead to a | staging point. Network manageability considerations may lead to a | |||
| repair strategy that uses a remote LFA more frequently | repair strategy that uses a remote LFA more frequently | |||
| [I-D.ietf-rtgwg-lfa-manageability]. | [I-D.ietf-rtgwg-lfa-manageability]. | |||
| Examples of worse failures are node failures (see Section 6 ), the | Examples of worse failures are node failures (see Section 7 ), the | |||
| failure of a shared risk link group (SRLG), the independent | failure of a shared risk link group (SRLG), the independent | |||
| concurrent failures of multiple links, broadcast or non-broadcast | concurrent failures of multiple links, broadcast or non-broadcast | |||
| multi-access (NBMA) links Section 2 ; protecting against such worse | multi-access (NBMA) links Section 3 ; protecting against such worse | |||
| failures is out of scope for this specification. | failures is out of scope for this specification. | |||
| 3.1. Tunnels as Repair Paths | 4.1. Tunnels as Repair Paths | |||
| Consider an arbitrary protected link S-E. In LFA FRR, if a path to | 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 | 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 | 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 | S can send the packet to N and the packet will be delivered to the | |||
| destination using the pre-failure forwarding information. If there | destination using the pre-failure forwarding information. If there | |||
| is no such LFA neighbor, then S may be able to create a virtual LFA | is no such LFA neighbor, then S may be able to create a virtual LFA | |||
| by using a tunnel to carry the packet to a point in the network which | by using a tunnel to carry the packet to a point in the network which | |||
| is not a direct neighbor of S from which the packet will be delivered | 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 | 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 | 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 | repair tunnel endpoint) is a "PQ node" and the repair mechanism is a | |||
| "remote LFA". This tunnel MUST NOT traverse the link S-E. | "remote LFA". This tunnel MUST NOT traverse the link S-E. | |||
| Note that the repair tunnel terminates at some intermediate router | Note that the repair tunnel terminates at some intermediate router | |||
| between S and E, and not E itself. This is clearly the case, since | 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 | if it were possible to construct a tunnel from S to E then a | |||
| conventional LFA would have been sufficient to effect the repair. | conventional LFA would have been sufficient to effect the repair. | |||
| 3.2. Tunnel Requirements | 4.2. Tunnel Requirements | |||
| There are a number of IP in IP tunnel mechanisms that may be used to | There are a number of IP in IP tunnel mechanisms that may be used to | |||
| fulfil the requirements of this design, such as IP-in-IP [RFC1853] | fulfil the requirements of this design, such as IP-in-IP [RFC1853] | |||
| and GRE[RFC1701] . | and GRE[RFC1701] . | |||
| In an MPLS enabled network using LDP[RFC5036], a simple label | In an MPLS enabled network using LDP[RFC5036], a simple label | |||
| stack[RFC3032] may be used to provide the required repair tunnel. In | 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 | this case the outer label is S's neighbor's label for the repair | |||
| tunnel end point, and the inner label is the repair tunnel end | tunnel end point, and the inner label is the repair tunnel end | |||
| point's label for the packet destination. In order for S to obtain | point's label for the packet destination. In order for S to obtain | |||
| skipping to change at page 7, line 34 ¶ | skipping to change at page 7, line 47 ¶ | |||
| into service. This is not anticipated to be a problem in normal | into service. This is not anticipated to be a problem in normal | |||
| operation since the managed introduction and removal of links is | operation since the managed introduction and removal of links is | |||
| relatively rare as is the incidence of failure in a well managed | relatively rare as is the incidence of failure in a well managed | |||
| network. | network. | |||
| When a failure is detected, it is necessary to immediately redirect | When a failure is detected, it is necessary to immediately redirect | |||
| traffic to the repair path. Consequently, the repair tunnel used | traffic to the repair path. Consequently, the repair tunnel used | |||
| MUST be provisioned beforehand in anticipation of the failure. Since | MUST be provisioned beforehand in anticipation of the failure. Since | |||
| the location of the repair tunnels is dynamically determined it is | the location of the repair tunnels is dynamically determined it is | |||
| necessary to automatically establish the repair tunnels. Multiple | necessary to automatically establish the repair tunnels. Multiple | |||
| repairs MAY share a tunnel end point. | repair tunnels may share a tunnel end point. | |||
| 4. Construction of Repair Paths | 5. Construction of Repair Paths | |||
| 4.1. Identifying Required Tunneled Repair Paths | 5.1. Identifying Required Tunneled Repair Paths | |||
| Not all links will require protection using a tunneled repair path. | 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 | 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 | does not need to be protected using a repair tunnel, since all | |||
| destinations normally reachable through E must therefore also be | destinations normally reachable through E must therefore also be | |||
| protectable by an LFA. Such an LFA is frequently termed a "link | protectable by an LFA. Such an LFA is frequently termed a "link | |||
| LFA". Tunneled repair paths (which may be calculated per-prefix) are | LFA". Tunneled repair paths (which may be calculated per-prefix) are | |||
| only required for links which do not have a link or per-prefix LFA. | only required for links which 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 | 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 | Q-space of each destination can result in failing to identify valid | |||
| remote LFAs. The extent to which this reduces the effective | remote LFAs. The extent to which this reduces the effective | |||
| protection coverage is topology dependent. | protection coverage is topology dependent. | |||
| 4.2. Determining Tunnel End Points | 5.2. Determining Tunnel End Points | |||
| The repair tunnel endpoint needs to be a node in the network | The repair tunnel endpoint needs to be a node in the network | |||
| reachable from S without traversing S-E. In addition, the repair | reachable from S without traversing S-E. In addition, the repair | |||
| tunnel end point needs to be a node from which packets will normally | tunnel end point needs to be a node from which packets will normally | |||
| flow towards their destination without being attracted back to the | flow towards their destination without being attracted back to the | |||
| failed link S-E. | failed link S-E. | |||
| Note that once released from the tunnel, the packet will be | Note that once released from the tunnel, the packet will be | |||
| forwarded, as normal, on the shortest path from the release point to | forwarded, as normal, on the shortest path from the release point to | |||
| its destination. This may result in the packet traversing the router | its destination. This may result in the packet traversing the router | |||
| skipping to change at page 8, line 39 ¶ | skipping to change at page 9, line 7 ¶ | |||
| repair tunnel will reach their destination, and will not loop after a | repair tunnel will reach their destination, and will not loop after a | |||
| single link failure. | single link failure. | |||
| In some topologies it will not be possible to find a repair tunnel | In some topologies it will not be possible to find a repair tunnel | |||
| endpoint that exhibits both the required properties. For example if | endpoint that exhibits both the required properties. For example if | |||
| the ring topology illustrated in Figure 1 had a cost of 4 for the | the ring topology illustrated in Figure 1 had a cost of 4 for the | |||
| link B-C, while the remaining links were cost 1, then it would not be | link B-C, while the remaining links were cost 1, then it would not be | |||
| possible to establish a tunnel from S to C (without resorting to some | possible to establish a tunnel from S to C (without resorting to some | |||
| form of source routing). | form of source routing). | |||
| 4.2.1. Computing Repair Paths | 5.2.1. Computing Repair Paths | |||
| To compute the repair path for link S-E we need to determine the set | To compute the repair path for link S-E it is necessary to determine | |||
| of routers which can be reached from S without traversing S-E, and | the set of routers which can be reached from S without traversing | |||
| match this with the set of routers from which the node E can be | S-E, and match this with the set of routers from which the node E can | |||
| reached, by normal forwarding, without traversing the link S-E. | be reached, by normal forwarding, without traversing the link S-E. | |||
| The approach described in this memo is as follows: | The approach used in this memo is as follows: | |||
| o We describe how to compute the set of routers which can be reached | o The method of computing the set of routers which can be reached | |||
| from S on the shortest path tree without traversing S-E. We call | from S on the shortest path tree without traversing S-E is | |||
| this the S's P-space with respect to the failure of link S-E. | described. This is called the S's P-space with respect to the | |||
| failure of link S-E. | ||||
| o We show how to extend the distance of the tunnel endpoint from the | o The distance of the tunnel endpoint from the point of local repair | |||
| point of local repair (PLR) by noting that S is able to use the | (PLR) is increased by noting that S is able to use the P-Space of | |||
| P-Space of its neighbours since S can determine which neighbour it | its neighbours with respect to the failure of link S-E, since S | |||
| will use as the next hop for the repair. We call this the S's | can determine which neighbour it will use as the next hop for the | |||
| Extended P-Space with respect to the failure of link S-E. The use | repair. This is called the S's Extended P-space with respect to | |||
| of extended P-Space allows greater repair coverage and is the | the failure of link S-E. The use of extended P-space allows | |||
| preferred approach. | greater repair coverage and is the preferred approach. | |||
| o Finally we show how to compute the set of routers from which the | o Finally two methods of computing the set of routers from which the | |||
| node E can be reached, by normal forwarding, without traversing | 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 | the link S-E. This is called the Q-space of E with respect to the | |||
| link S-E. | link S-E. | |||
| The selection of the preferred node from the set of nodes that an in | The selection of the preferred node from the set of nodes that an in | |||
| both Extended P-Space and Q-Space is described in Section 4.2.2. | 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 | A suitable cost based algorithm to compute the set of nodes common to | |||
| both extended P-space and Q-space is provided in Section 4.3. | both extended P-space and Q-space with respect to the S-E is provided | |||
| in Section 5.3. | ||||
| 4.2.1.1. P-space | 5.2.1.1. P-space | |||
| The set of routers which can be reached from S on the shortest path | The set of routers which can be reached from S on the shortest path | |||
| tree without traversing S-E is termed the P-space of S with respect | tree without traversing S-E is termed the P-space of S with respect | |||
| to the link S-E. The P-space can be obtained by computing a shortest | to the link S-E. This P-space can be obtained by computing a | |||
| path tree (SPT) rooted at S and excising the sub-tree reached via the | shortest path tree (SPT) rooted at S and excising the sub-tree | |||
| link S-E (including those routers which are members of an ECMP that | reached via the link S-E (including those routers which are members | |||
| includes link S-E). The exclusion of routers reachable via an ECMP | of an ECMP that includes link S-E). The exclusion of routers | |||
| that includes S-E prevents the forwarding subsystem from attempting | reachable via an ECMP that includes S-E prevents the forwarding | |||
| to a repair endpoint via the failed link S-E. Thus for example, if | subsystem from attempting to execute a repair via the failed link | |||
| the SPF computation stores at each node the next-hops to be used to | S-E. Thus for example, if the SPF computation stores at each node | |||
| reach that node from S, then the node can be added to P-space if none | the next-hops to be used to reach that node from S, then the node can | |||
| of its next-hops are S-E. In the case of Figure 1 the P-space | be added to P-space if none of its next-hops are link S-E. In the | |||
| comprises nodes A and B only. Expressed in cost terms the set of | case of Figure 1 this P-space comprises nodes A and B only. | |||
| routers {P} are those for which the shortest path cost S->P is | Expressed in cost terms the set of routers {P} are those for which | |||
| strictly less than the shortest path cost S->E->P. | the shortest path cost S->P is strictly less than the shortest path | |||
| cost S->E->P. | ||||
| 4.2.1.2. Extended P-space | 5.2.1.2. Extended P-space | |||
| The description in Section 4.2.1.1 calculated router S's 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 | 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 | 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 | hop of the repair path need not be subject to S's normal forwarding | |||
| decision process. Thus we introduce the concept of extended P-space. | decision process. Thus the concept of extended P-space is | |||
| Router S's extended P-space is the union of the P-spaces of each of | introduced. Router S's extended P-space is the union of the P-spaces | |||
| S's neighbours (N). This may be calculated by computing an SPT at | of each of S's neighbours (N). This may be calculated by computing a | |||
| each of S's neighbors (excluding E) and excising the subtree reached | shortest path tree (SPT) at each of S's neighbors (excluding E) and | |||
| via the path N->S->E. Note this will excise those routers which are | excising the subtree reached via the path N->S->E. Note this will | |||
| reachable through all ECMPs that includes link S-E. The use of | excise those routers which are reachable through all ECMPs that | |||
| extended P-space may allow router S to reach potential repair tunnel | includes link S-E. The use of extended P-space may allow router S to | |||
| end points that were otherwise unreachable. In cost terms a router | reach potential repair tunnel end points that were otherwise | |||
| (P) is in extended P-space if the shortest path cost N->P is strictly | unreachable. In cost terms a router (P) is in extended P-space if | |||
| less than the shortest path cost N->S->E->P. In other words, once | the shortest path cost N->P is strictly less than the shortest path | |||
| the packet it forced to N by S, it is lower cost for it to continue | cost N->S->E->P. In other words, once the packet it forced to N by | |||
| on to P by any path except one that takes it back to S and then | S, it is a lower cost for it to continue on to P by any path except | |||
| across the S->E link. | 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 | 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 comprises nodes | destination node C, the set of extended P-space nodes with respect to | |||
| A, B and C. Since node C is also in E's Q-space, there is now a node | link S-E comprises nodes A, B and C. Since node C is also in E's | |||
| common to both extended P-space and Q-space which can be used as a | Q-space with respect to link S-E, there is now a node common to both | |||
| repair tunnel end-point to protect the link S-E. | extended P-space and Q-space which can be used as a repair tunnel | |||
| end-point to protect the link S-E. | ||||
| 4.2.1.3. Q-space | 5.2.1.3. Q-space | |||
| The set of routers from which the node E can be reached, by normal | 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 | 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 | 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 | computing a reverse shortest path tree (rSPT) rooted at E, with the | |||
| sub-tree which traverses the failed link excised (including those | sub-tree which might traverse the protected link S-E excised (i.e. | |||
| which are members of an ECMP). The rSPT uses the cost towards the | those nodes that would send the packet via S-E plus those nodes which | |||
| root rather than from it and yields the best paths towards the root | have an ECMP set to E with one or more members of that ECMP set | |||
| from other nodes in the network. In the case of Figure 1 the Q-space | traversing the protected link S-E). The rSPT uses the cost towards | |||
| comprises nodes C and D only. Expressed in cost terms the set of | the root rather than from it and yields the best paths towards the | |||
| routers {Q} are those for which the shortest path cost Q<-E is | root from other nodes in the network. In the case of Figure 1 the | |||
| strictly less than the shortest path cost Q<-S<-E. In Figure 1 the | Q-space of E with respect to S-E comprises nodes C and D only. | |||
| intersection of the E's Q-space with S's P-space defines the set of | ||||
| viable repair tunnel end-points, known as "PQ nodes". As can be | 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 end-points, known as "PQ nodes". As can be | ||||
| seen, for the case of Figure 1 there is no common node and hence no | seen, for the case of Figure 1 there is no common node and hence no | |||
| viable repair tunnel end-point. However when the extended the | viable repair tunnel end-point. However when the extended the | |||
| extended P-space Section 4.2.1.2 at S is considered a suitable | extended P-space Section 5.2.1.2 at S with respect to S-E is | |||
| intersection is found at C. | considered, a suitable intersection is found at C. | |||
| Note that the Q-space calculation could be conducted for each | Note that the Q-space calculation could be conducted for each | |||
| individual destination and a per-destination repair tunnel end point | individual destination and a per-destination repair tunnel end point | |||
| determined. However this would, in the worst case, require an SPF | determined. However this would, in the worst case, require an SPF | |||
| computation per destination which is not currently considered to be | computation per destination which is not currently considered to be | |||
| scalable. We therefore use the Q-space of E as a proxy for the | scalable. Therefore the Q-space of E with respect to link S-E is | |||
| Q-space of each destination. This approximation is obviously correct | used as a proxy for the Q-space of each destination. This | |||
| since the repair is only used for the set of destinations which were, | approximation is obviously correct since the repair is only used for | |||
| prior to the failure, routed through node E. This is analogous to | the set of destinations which were, prior to the failure, routed | |||
| the use of link-LFAs rather than per-prefix LFAs. | through node E. This is analogous to the use of link-LFAs rather | |||
| than per-prefix LFAs. | ||||
| 4.2.2. Selecting Repair Paths | 5.2.2. Selecting Repair Paths | |||
| The mechanisms described above will identify all the possible repair | The mechanisms described above will identify all the possible repair | |||
| tunnel end points that can be used to protect a particular link. In | tunnel end points that can be used to protect a particular link. In | |||
| a well-connected network there are likely to be multiple possible | a well-connected network there are likely to be multiple possible | |||
| release points for each protected link. All will deliver the packets | release points for each protected link. All will deliver the packets | |||
| correctly so, arguably, it does not matter which is chosen. However, | correctly so, arguably, it does not matter which is chosen. However, | |||
| one repair tunnel end point may be preferred over the others on the | one repair tunnel end point may be preferred over the others on the | |||
| basis of path cost or some other selection criteria. | basis of path cost or some other selection criteria. | |||
| There is no technical requirement for the selection criteria to be | There is no technical requirement for the selection criteria to be | |||
| skipping to change at page 11, line 39 ¶ | skipping to change at page 12, line 12 ¶ | |||
| manageability considerations may lead to a repair strategy that uses | manageability considerations may lead to a repair strategy that uses | |||
| a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability]. | a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability]. | |||
| As described in [RFC5286], always selecting a PQ node that is | As described in [RFC5286], always selecting a PQ node that is | |||
| downstream to the destination with respect to the repairing node, | downstream to the destination with respect to the repairing node, | |||
| prevents the formation of loops when the failure is worse than | prevents the formation of loops when the failure is worse than | |||
| expected. The use of downstream nodes reduces the repair coverage, | expected. The use of downstream nodes reduces the repair coverage, | |||
| and operators are advised to determine whether adequate coverage is | and operators are advised to determine whether adequate coverage is | |||
| achieved before enabling this selection feature. | achieved before enabling this selection feature. | |||
| 4.3. A Cost Based RLFA Algorithm | 5.3. A Cost Based RLFA Algorithm | |||
| The preceding text has mostly described the computation of the remote | The preceding text has described the computation of the remote LFA | |||
| LFA repair target (PQ) in terms of the intersection of two | repair target (PQ) in terms of the intersection of two reachability | |||
| reachability graphs computed using SPFs. This section describes a | graphs computed using a shortest path first (SPF) algorithm. This | |||
| method of computing the remote LFA repair target for a specific | section describes a method of computing the remote LFA repair target | |||
| failed link using a cost based algorithm. The pseudo-code provided | for a specific failed link using a cost based algorithm. The pseudo- | |||
| in this section avoids unnecessary SPF computations, but for the sake | code provided in this section avoids unnecessary SPF computations, | |||
| of readability, it does not otherwise try to optimize the code. The | but for the sake of readability, it does not otherwise try to | |||
| algorithm covers the case where the repair first hop is reached via a | optimize the code. The algorithm covers the case where the repair | |||
| broadcast or non-broadcast multi-access (NBMA) link such as a LAN. | first hop is reached via a broadcast or non-broadcast multi-access | |||
| It also covers the case where the P or Q node is attached via such a | (NBMA) link such as a LAN. It also covers the case where the P or Q | |||
| link. It does not cover the case where the failed interface is a | node is attached via such a link. It does not cover the case where | |||
| broadcast or non-broadcast multi-access (NBMA) link. To address that | the failed interface is a broadcast or non-broadcast multi-access | |||
| case it is necessary to compute the Q space of each neighbor of the | (NBMA) link. To address that case it is necessary to compute the Q | |||
| repairing router reachable though the LAN, i.e. to treat the | space of each neighbor of the repairing router reachable though the | |||
| pseudonode as a node failure. This is because the Q spaces of the | LAN, i.e. to treat the pseudonode [RFC1195] as a node failure. This | |||
| neighbors of the pseudonode may be disjoint requiring use of a | is because the Q spaces of the neighbors of the pseudonode may be | |||
| neighbor specific PQ node. The reader is referred to | disjoint requiring use of a neighbor specific PQ node. The reader is | |||
| [I-D.ietf-rtgwg-rlfa-node-protection] for further information on the | referred to [I-D.ietf-rtgwg-rlfa-node-protection] for further | |||
| use of RLFA for node repairs. | information on the use of RLFA for node repairs. | |||
| The following notation is used: | The following notation is used: | |||
| o D_opt(a,b) is the shortest distance from node a to node b as | o D_opt(a,b) is the shortest distance from node a to node b as | |||
| computed by the SPF. | computed by the SPF. | |||
| o dest is the packet destination | o dest is the packet destination | |||
| o fail_intf is the failed interface (S-E in the example) | o fail_intf is the failed interface (S-E in the example) | |||
| skipping to change at page 14, line 24 ¶ | skipping to change at page 14, line 24 ¶ | |||
| Compute_and_Store_Forward_SPF(root) | Compute_and_Store_Forward_SPF(root) | |||
| Compute_Forward_SPF(root) | Compute_Forward_SPF(root) | |||
| foreach node y in network | foreach node y in network | |||
| store D_opt(root,y) | store D_opt(root,y) | |||
| ///////////////////////////////////////////////////////////////// | ///////////////////////////////////////////////////////////////// | |||
| // | // | |||
| // This computes the optimum distance from each neighbour (other | // This computes the optimum distance from each neighbour (other | |||
| // than the neighbour reachable through the failed link) and | // than the neighbour reachable through the failed link) and | |||
| // every other node in the network | // every other node in the network | |||
| // | ||||
| // Note that we compute this for all neighbours including the | ||||
| // neighbour on the far side the failure. This is done on the | ||||
| // expectation that more than on link will be protected, and | ||||
| // that the results are stored for later use. | ||||
| // | ||||
| Compute_Neighbor_SPFs() | Compute_Neighbor_SPFs() | |||
| foreach interface intf in self | foreach interface intf in self | |||
| Compute_and_Store_Forward_SPF(intf.remote_node) | Compute_and_Store_Forward_SPF(intf.remote_node) | |||
| ///////////////////////////////////////////////////////////////// | ///////////////////////////////////////////////////////////////// | |||
| // | // | |||
| // The reverse SPF computes the cost from each remote node to | // The reverse SPF computes the cost from each remote node to | |||
| // root. This is achieved by running the normal SPF algorithm, | // root. This is achieved by running the normal SPF algorithm, | |||
| // but using the link cost in the direction from the next hop | // but using the link cost in the direction from the next hop | |||
| skipping to change at page 16, line 38 ¶ | skipping to change at page 17, line 26 ¶ | |||
| if (y.valid_tunnel_endpoint) | if (y.valid_tunnel_endpoint) | |||
| Compute_and_Store_Forward_SPF(y) | Compute_and_Store_Forward_SPF(y) | |||
| if ((D_opt(y,dest) < D_opt(self,dest)) | if ((D_opt(y,dest) < D_opt(self,dest)) | |||
| y.valid_tunnel_endpoint = true | y.valid_tunnel_endpoint = true | |||
| else | else | |||
| y.valid_tunnel_endpoint = false | y.valid_tunnel_endpoint = false | |||
| // | // | |||
| ///////////////////////////////////////////////////////////////// | ///////////////////////////////////////////////////////////////// | |||
| 4.4. Interactions with IS-IS Overload, RFC6987, and Costed Out Links | 5.4. Interactions with IS-IS Overload, RFC6987, and Costed Out Links | |||
| Since normal link state routing takes into account the IS-IS overload | Since normal link state routing takes into account the IS-IS overload | |||
| bit, [RFC6987], and costing out of links as described in Section 3.5 | bit, [RFC6987], and costing out of links as described in Section 3.5 | |||
| of [RFC5286], the forward SPFs performed by the PLR rooted at the | 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 | 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 | tunnel path from a neighbor of the PLR to a repair tunnel endpoint | |||
| will generally avoid the nodes and links excluded by the IGP | will generally avoid the nodes and links excluded by the IGP | |||
| overload/costing out rules. However, there are two situations where | overload/costing out rules. However, there are two situations where | |||
| this behavior may result in a repair path traversing a link or router | this behavior may result in a repair path traversing a link or router | |||
| that should be excluded: | that should be excluded: | |||
| skipping to change at page 17, line 24 ¶ | skipping to change at page 18, line 9 ¶ | |||
| 2. The IS-IS overload bit and the mechanism of [RFC6987] only | 2. The IS-IS overload bit and the mechanism of [RFC6987] only | |||
| prevent transit traffic from traversing a node. They do not | prevent transit traffic from traversing a node. They do not | |||
| prevent traffic destined to a node. The per-neighbor forward | prevent traffic destined to a node. The per-neighbor forward | |||
| SPFs using the standard IGP overload rules will not prevent a PLR | SPFs using the standard IGP overload rules will not prevent a PLR | |||
| from choosing a repair tunnel endpoint that is advertising a | from choosing a repair tunnel endpoint that is advertising a | |||
| desire to not carry transit traffic. Therefore, the PLR MUST NOT | desire to not carry transit traffic. Therefore, the PLR MUST NOT | |||
| use a repair tunnel endpoint with the IS-IS overload bit set, or | use a repair tunnel endpoint with the IS-IS overload bit set, or | |||
| where all outgoing interfaces have the cost set to MaxLinkMetric | where all outgoing interfaces have the cost set to MaxLinkMetric | |||
| for OSPF. | for OSPF. | |||
| 5. Example Application of Remote LFAs | 6. Example Application of Remote LFAs | |||
| An example of a commonly deployed topology which is not fully | An example of a commonly deployed topology which is not fully | |||
| protected by LFAs alone is shown in Figure 3. PE1 and PE2 are | protected by LFAs alone is shown in Figure 3. PE1 and PE2 are | |||
| connected in the same site. P1 and P2 may be geographically | connected in the same site. P1 and P2 may be geographically | |||
| separated (inter-site). In order to guarantee the lowest latency | separated (inter-site). In order to guarantee the lowest latency | |||
| path from/to all other remote PEs, normally the shortest path follows | path from/to all other remote PEs, normally the shortest path follows | |||
| the geographical distance of the site locations. Therefore, to | the geographical distance of the site locations. Therefore, to | |||
| ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. | 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 | 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- | being used for transit traffic. The PEs are not individually dual- | |||
| skipping to change at page 18, line 19 ¶ | skipping to change at page 18, line 47 ¶ | |||
| PE1---PE2 | PE1---PE2 | |||
| 5 | 5 | |||
| Figure 3: Example SP topology | Figure 3: Example SP topology | |||
| Clearly, full protection can be provided, using the techniques | Clearly, full protection can be provided, using the techniques | |||
| described in this document, by PE1 choosing P2 as the remote LFA | described in this document, by PE1 choosing P2 as the remote LFA | |||
| repair target node, and PE2 choosing P1 as the remote LFA repair | repair target node, and PE2 choosing P1 as the remote LFA repair | |||
| target. | target. | |||
| 6. Node Failures | 7. Node Failures | |||
| When the failure is a node failure rather than a point-to-point link | 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 | failure there is a danger that the RLFA repair will loop. This is | |||
| discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the | discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the | |||
| problem is that two of more of E's neighbors each with E as the next | problem is that two of more of E's neighbors each with E as the next | |||
| hop to some destination D may attempt to repair a packet addressed to | 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 | 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 | 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 | group failure where the PLR for each failure attempts to repair via | |||
| the other failure. As will be noted from [I-D.bryant-ipfrr-tunnels], | the other failure. As will be noted from [I-D.bryant-ipfrr-tunnels], | |||
| skipping to change at page 19, line 26 ¶ | skipping to change at page 20, line 8 ¶ | |||
| failure in any particular topology will depend on the node design, | failure in any particular topology will depend on the node design, | |||
| the particular topology in use, and the strategy adopted under node | the particular topology in use, and the strategy adopted under node | |||
| failure. It is recommended that a network operator perform an | failure. It is recommended that a network operator perform an | |||
| analysis of the consequences and probability of node failure in their | analysis of the consequences and probability of node failure in their | |||
| network, and determine whether the incidence and consequence of | network, and determine whether the incidence and consequence of | |||
| occurrence are acceptable. | occurrence are acceptable. | |||
| This topic is further discussed in | This topic is further discussed in | |||
| [I-D.ietf-rtgwg-rlfa-node-protection]. | [I-D.ietf-rtgwg-rlfa-node-protection]. | |||
| 7. Operation in an LDP environment | 8. Operation in an LDP environment | |||
| Where this technique is used in an MPLS network using LDP [RFC5036], | 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 | 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 | 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 | destination, and to then push its own label for the remote LFA repair | |||
| target. | target. | |||
| In the example Figure 2 S already has the first hop (A) label for the | In the example Figure 2 S already has the first hop (A) label for the | |||
| remote LFA repair target (C) as a result of the ordinary operation of | 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 | LDP. To get the remote LFA repair target's label (C's label) for the | |||
| skipping to change at page 20, line 41 ¶ | skipping to change at page 21, line 14 ¶ | |||
| In the absence of a protocol to learn the preferred IP address for | 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 | targeted LDP, an LSR should attempt a targeted LDP session with the | |||
| Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] | Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] | |||
| [I-D.ietf-ospf-routable-ip-address], unless it is configured | [I-D.ietf-ospf-routable-ip-address], unless it is configured | |||
| otherwise. | otherwise. | |||
| No protection is available until the TLDP session has been | No protection is available until the TLDP session has been | |||
| established and a label for the destination has been learned from the | established and a label for the destination has been learned from the | |||
| remote LFA repair target. If for any reason the TLDP session cannot | remote LFA repair target. If for any reason the TLDP session cannot | |||
| not be established, an implementation SHOULD advise the operator | be established, an implementation SHOULD advise the operator about | |||
| about the protection setup issue using any well known mechanism such | the protection setup issue through the network management system. | |||
| as Syslog [RFC5424] or SNMP [RFC3411]. | ||||
| 8. Analysis of Real World Topologies | 9. Analysis of Real World Topologies | |||
| This section gives the results of analysing a number of real world | This section gives the results of analysing a number of real world | |||
| service provider topologies collected between the end of 2012 and | service provider topologies collected between the end of 2012 and | |||
| early 2013 | early 2013 | |||
| 8.1. Topology Details | 9.1. Topology Details | |||
| The figure below characterises each topology (topo) studied in terms | The figure below characterises each topology (topo) studied in terms | |||
| of : | of : | |||
| o The number of nodes (# nodes) excluding pseudonodes. | o The number of nodes (# nodes) excluding pseudonodes. | |||
| o The number of bidirectional links ( # links) including parallel | o The number of bidirectional links ( # links) including parallel | |||
| links and links to and from pseudonodes. | links and links to and from pseudonodes. | |||
| o The number of node pairs that are connected by one or more links | o The number of node pairs that are connected by one or more links | |||
| skipping to change at page 21, line 43 ¶ | skipping to change at page 22, line 24 ¶ | |||
| | 7 | 55 | 237 | 159 | 67 | 2 | | | 7 | 55 | 237 | 159 | 67 | 2 | | |||
| | 8 | 779 | 1848 | 1441 | 199 | 437 | | | 8 | 779 | 1848 | 1441 | 199 | 437 | | |||
| | 9 | 263 | 482 | 413 | 41 | 12 | | | 9 | 263 | 482 | 413 | 41 | 12 | | |||
| | 10 | 86 | 375 | 145 | 64 | 22 | | | 10 | 86 | 375 | 145 | 64 | 22 | | |||
| | 11 | 162 | 1083 | 351 | 201 | 49 | | | 11 | 162 | 1083 | 351 | 201 | 49 | | |||
| | 12 | 380 | 1174 | 763 | 231 | 0 | | | 12 | 380 | 1174 | 763 | 231 | 0 | | |||
| | 13 | 1051 | 2087 | 2037 | 48 | 64 | | | 13 | 1051 | 2087 | 2037 | 48 | 64 | | |||
| | 14 | 92 | 291 | 204 | 64 | 2 | | | 14 | 92 | 291 | 204 | 64 | 2 | | |||
| +------+---------+---------+---------+--------+--------+ | +------+---------+---------+---------+--------+--------+ | |||
| 8.2. LFA only | 9.2. LFA only | |||
| The figure below shows the percentage of protected destinations (% | The figure below shows the percentage of protected destinations (% | |||
| prot) and percentage of guaranteed node protected destinations ( % | prot) and percentage of guaranteed node protected destinations ( % | |||
| gtd N) for the set of topologies characterized in Section 8.1 | gtd N) for the set of topologies characterized in Section 9.1 | |||
| achieved using only LFA repairs. | achieved using only LFA repairs. | |||
| These statistics were generated by considering each node and then | These statistics were generated by considering each node and then | |||
| considering each link to each next hop to each destination. The | considering each link to each next hop to each destination. The | |||
| percentage of such links across the entire network that are protected | percentage of such links across the entire network that are protected | |||
| against link failure was determined. This is the percentage of | against link failure was determined. This is the percentage of | |||
| protected destinations. If a link is protected against the failure | protected destinations. If a link is protected against the failure | |||
| of the next hop node, this is considered guaranteed node protecting | of the next hop node, this is considered guaranteed node protecting | |||
| (GNP) and percentage of guaranteed node protected destinations is | (GNP) and percentage of guaranteed node protected destinations is | |||
| calculated using the same method used for calculating the link | calculated using the same method used for calculating the link | |||
| skipping to change at page 22, line 34 ¶ | skipping to change at page 23, line 24 ¶ | |||
| | 7 | 93.9 | 35.4 | | | 7 | 93.9 | 35.4 | | |||
| | 8 | 95.3 | 48.1 | | | 8 | 95.3 | 48.1 | | |||
| | 9 | 82.2 | 49.5 | | | 9 | 82.2 | 49.5 | | |||
| | 10 | 98.5 | 14.9 | | | 10 | 98.5 | 14.9 | | |||
| | 11 | 99.6 | 24.8 | | | 11 | 99.6 | 24.8 | | |||
| | 12 | 99.5 | 62.4 | | | 12 | 99.5 | 62.4 | | |||
| | 13 | 92.4 | 51.6 | | | 13 | 92.4 | 51.6 | | |||
| | 14 | 99.3 | 48.6 | | | 14 | 99.3 | 48.6 | | |||
| +------+--------+---------+ | +------+--------+---------+ | |||
| 8.3. RLFA | 9.3. RLFA | |||
| The figure below shows the percentage of protected destinations (% | The figure below shows the percentage of protected destinations (% | |||
| prot) and % guaranteed node protected destinations ( % gtd N) for | prot) and % guaranteed node protected destinations ( % gtd N) for | |||
| RLFA protection in the topologies studies. In addition, it show the | RLFA protection in the topologies studies. In addition, it show the | |||
| percentage of destinations using an RLFA repair (% PQ) together with | percentage of destinations using an RLFA repair (% PQ) together with | |||
| the total number of unidirectional RLFA targeted LDP session | the total number of unidirectional RLFA targeted LDP session | |||
| established (# PQ), the number of PQ sessions which would be required | established (# PQ), the number of PQ sessions which would be required | |||
| for complete protection, but which could not be established because | for complete protection, but which could not be established because | |||
| there was no PQ node, i.e. the number of cases whether neither LFA or | 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 | RLFA protection was possible (no PQ). It also shows the 50 (p50), 90 | |||
| skipping to change at page 23, line 42 ¶ | skipping to change at page 24, line 32 ¶ | |||
| | 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 | | | 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 | | |||
| | 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 | | | 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 | | |||
| | 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 | | | 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 | | |||
| | 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 | | | 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 | | |||
| | 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 | | | 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 | | |||
| +------+--------+--------+------+------+-------+-----+-----+------+ | +------+--------+--------+------+------+-------+-----+-----+------+ | |||
| Another study[ISOCORE2010] confirms the significant coverage increase | Another study[ISOCORE2010] confirms the significant coverage increase | |||
| provided by Remote LFAs. | provided by Remote LFAs. | |||
| 8.4. Comparison of LFA an RLFA results | 9.4. Comparison of LFA an RLFA results | |||
| The table below provides a side by side comparison the LFA and the | The table below provides a side by side comparison the LFA and the | |||
| remote LFA results. This shows a significant improvement in the | remote LFA results. This shows a significant improvement in the | |||
| percentage of protected destinations and normally a modest | percentage of protected destinations and normally a modest | |||
| improvement in the percentage of guaranteed node protected | improvement in the percentage of guaranteed node protected | |||
| destinations. | destinations. | |||
| +------+--------+--------+---------+---------+ | +------+--------+--------+---------+---------+ | |||
| | topo | LFA | RLFA | LFA | RLFA | | | topo | LFA | RLFA | LFA | RLFA | | |||
| | | % prot | %prot | % gtd N | % gtd N | | | | % prot | %prot | % gtd N | % gtd N | | |||
| skipping to change at page 24, line 39 ¶ | skipping to change at page 25, line 39 ¶ | |||
| always present as a property of an LDP-based deployment. | always present as a property of an LDP-based deployment. | |||
| In the small number of cases where there is no intersection between | 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 | the (extended)P-space and the Q-space, a number of solutions to | |||
| providing a suitable path between such disjoint regions in the | providing a suitable path between such disjoint regions in the | |||
| network have been discussed in the working group. For example an | 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 | explicitly routed LSP between P and Q might be set up using RSVP-TE | |||
| or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such | or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such | |||
| extended repair methods are outside the scope of this document. | extended repair methods are outside the scope of this document. | |||
| 9. Management and Operational Considerations | 10. Management and Operational Considerations | |||
| The management of LFA and remote LFA is the subject of ongoing work | The management of LFA and remote LFA is the subject of ongoing work | |||
| withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the | withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the | |||
| reader is referred. Management considerations may lead to a | reader is referred. Management considerations may lead to a | |||
| preference for the use of a remote LFA over an available LFA. This | 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 | preference is a matter for the network operator, and not a matter of | |||
| protocol correctness. | protocol correctness. | |||
| When the network re-converges, microloops [RFC5715] may form due to | When the network re-converges, microloops [RFC5715] can form due to | |||
| transient inconsistencies in the router FIBs. If it is determined | transient inconsistencies in the forwarding tables of different | |||
| that microloops are a significant issue in the deployment, then a | routers. If it is determined that microloops are a significant issue | |||
| suitable loop free convergence methods such as one of those described | in the deployment, then a suitable loop free convergence methods such | |||
| in [RFC5715], [RFC6976], or [I-D.litkowski-rtgwg-uloop-delay] should | as one of those described in [RFC5715], [RFC6976], or | |||
| be implemented. | [I-D.litkowski-rtgwg-uloop-delay] should be implemented. | |||
| 10. Historical Note | 11. Historical Note | |||
| The basic concepts behind Remote LFA were invented in 2002 and were | The basic concepts behind Remote LFA were invented in 2002 and were | |||
| later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004. | later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004. | |||
| [I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and | [I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and | |||
| hence included additional mechanisms on top of the Remote LFA | hence included additional mechanisms on top of the Remote LFA | |||
| concept. The addition of these mechanisms made the proposal very | concept. The addition of these mechanisms made the proposal very | |||
| complex and computationally intensive and it was therefore not | complex and computationally intensive and it was therefore not | |||
| pursued as a working group item. | pursued as a working group item. | |||
| skipping to change at page 25, line 29 ¶ | skipping to change at page 26, line 29 ¶ | |||
| not to provide coverage at any cost. A solution for this already | not to provide coverage at any cost. A solution for this already | |||
| exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is | exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is | |||
| able to provide protection in any topology thanks to the explicit | able to provide protection in any topology thanks to the explicit | |||
| routing capability of MPLS TE. | routing capability of MPLS TE. | |||
| The purpose of LFA FRR technology is to provide for a simple FRR | 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 | solution when such a solution is possible. The first step along this | |||
| simplicity approach was "local" LFA [RFC5286]. This specification of | simplicity approach was "local" LFA [RFC5286]. This specification of | |||
| "Remote LFA" is a natural second step. | "Remote LFA" is a natural second step. | |||
| 11. IANA Considerations | 12. IANA Considerations | |||
| There are no IANA considerations that arise from this architectural | There are no IANA considerations that arise from this architectural | |||
| description of IPFRR. The RFC Editor may remove this section on | description of IPFRR. The RFC Editor may remove this section on | |||
| publication. | publication. | |||
| 12. Security Considerations | 13. Security Considerations | |||
| The security considerations of [RFC5286] also apply. | The security considerations of [RFC5286] also apply. | |||
| Targeted LDP sessions and MPLS tunnels are normal features of an MPLS | Targeted LDP sessions and MPLS tunnels are normal features of an MPLS | |||
| network and their use in this application raises no additional | network and their use in this application raises no additional | |||
| security concerns. | security concerns. | |||
| To prevent their use as an attack vector IP repair tunnel endpoints | IP repair tunnel endpoints (where used) SHOULD be assigned from a set | |||
| (where used) SHOULD be assigned from a set of addresses that are not | of addresses that are not reachable from outside the routing domain. | |||
| reachable from outside the routing domain. | This would prevent their use as an attack vector. | |||
| 13. Acknowledgments | 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 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. | ||||
| 14. Acknowledgments | ||||
| The authors wish to thank Levente Csikor and Chris Bowers for their | The authors wish to thank Levente Csikor and Chris Bowers for their | |||
| contribution to the cost based algorithm text. We thank Alia Atlas, | contribution to the cost based algorithm text. The authors thank | |||
| Ross Callon, Stephane Litkowski, Bharath R, Pushpasis Sarkar and | Alia Atlas, Ross Callon, Stephane Litkowski, Bharath R, Pushpasis | |||
| Adrian Farrel for their review of this document. | Sarkar and Adrian Farrel for their review of this document. | |||
| 14. References | 15. References | |||
| 14.1. Normative References | 15.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, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast | |||
| Reroute: Loop-Free Alternates", RFC 5286, September 2008. | Reroute: Loop-Free Alternates", RFC 5286, September 2008. | |||
| 14.2. Informative References | [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC | |||
| 5714, January 2010. | ||||
| 15.2. Informative References | ||||
| [I-D.bryant-ipfrr-tunnels] | [I-D.bryant-ipfrr-tunnels] | |||
| Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP | Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP | |||
| Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 | Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 | |||
| (work in progress), November 2007. | (work in progress), November 2007. | |||
| [I-D.filsfils-spring-segment-routing] | [I-D.filsfils-spring-segment-routing] | |||
| Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | |||
| Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | |||
| Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, | Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, | |||
| "Segment Routing Architecture", draft-filsfils-spring- | "Segment Routing Architecture", draft-filsfils-spring- | |||
| segment-routing-04 (work in progress), July 2014. | segment-routing-04 (work in progress), July 2014. | |||
| [I-D.ietf-ospf-routable-ip-address] | [I-D.ietf-ospf-routable-ip-address] | |||
| Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP | Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP | |||
| Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip- | Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip- | |||
| address-01 (work in progress), October 2014. | address-01 (work in progress), October 2014. | |||
| [I-D.ietf-rtgwg-lfa-manageability] | [I-D.ietf-rtgwg-lfa-manageability] | |||
| Litkowski, S., Decraene, B., Filsfils, C., Raza, K., | Litkowski, S., Decraene, B., Filsfils, C., Raza, K., | |||
| Horneffer, M., and p. psarkar@juniper.net, "Operational | Horneffer, M., and P. Sarkar, "Operational management of | |||
| management of Loop Free Alternates", draft-ietf-rtgwg-lfa- | Loop Free Alternates", draft-ietf-rtgwg-lfa- | |||
| manageability-06 (work in progress), January 2015. | manageability-07 (work in progress), January 2015. | |||
| [I-D.ietf-rtgwg-rlfa-node-protection] | [I-D.ietf-rtgwg-rlfa-node-protection] | |||
| psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, | Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, | |||
| C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node | S., and H. Raghuveer, "Remote-LFA Node Protection and | |||
| Protection and Manageability", draft-ietf-rtgwg-rlfa-node- | Manageability", draft-ietf-rtgwg-rlfa-node-protection-01 | |||
| protection-01 (work in progress), December 2014. | (work in progress), December 2014. | |||
| [I-D.litkowski-rtgwg-uloop-delay] | [I-D.litkowski-rtgwg-uloop-delay] | |||
| Litkowski, S., Decraene, B., Filsfils, C., and P. | Litkowski, S., Decraene, B., Filsfils, C., and P. | |||
| Francois, "Microloop prevention by introducing a local | Francois, "Microloop prevention by introducing a local | |||
| convergence delay", draft-litkowski-rtgwg-uloop-delay-03 | convergence delay", draft-litkowski-rtgwg-uloop-delay-03 | |||
| (work in progress), February 2014. | (work in progress), February 2014. | |||
| [ISOCORE2010] | [ISOCORE2010] | |||
| So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) | So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) | |||
| Case Studies in Verizon's LDP Network", 2010. | Case Studies in Verizon's LDP Network", 2010. | |||
| [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | ||||
| dual environments", RFC 1195, December 1990. | ||||
| [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic | [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic | |||
| Routing Encapsulation (GRE)", RFC 1701, October 1994. | Routing Encapsulation (GRE)", RFC 1701, October 1994. | |||
| [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. | [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
| [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., | |||
| Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack | |||
| Encoding", RFC 3032, January 2001. | Encoding", RFC 3032, January 2001. | |||
| [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An | ||||
| Architecture for Describing Simple Network Management | ||||
| Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, | ||||
| December 2002. | ||||
| [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP | [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP | |||
| Specification", RFC 5036, October 2007. | Specification", RFC 5036, October 2007. | |||
| [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic | |||
| Engineering", RFC 5305, October 2008. | Engineering", RFC 5305, October 2008. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | |||
| for IPv6", RFC 5340, July 2008. | for IPv6", RFC 5340, July 2008. | |||
| [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. | ||||
| [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC | ||||
| 5714, January 2010. | ||||
| [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free | [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free | |||
| Convergence", RFC 5715, January 2010. | Convergence", RFC 5715, January 2010. | |||
| [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic | [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic | |||
| Engineering in IS-IS", RFC 6119, February 2011. | Engineering in IS-IS", RFC 6119, February 2011. | |||
| [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., | [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., | |||
| Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free | Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free | |||
| Alternate (LFA) Applicability in Service Provider (SP) | Alternate (LFA) Applicability in Service Provider (SP) | |||
| Networks", RFC 6571, June 2012. | Networks", RFC 6571, June 2012. | |||
| End of changes. 75 change blocks. | ||||
| 220 lines changed or deleted | 249 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/ | ||||