diff options
Diffstat (limited to 'doc/rfc/rfc7812.txt')
| -rw-r--r-- | doc/rfc/rfc7812.txt | 2467 |
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc7812.txt b/doc/rfc/rfc7812.txt new file mode 100644 index 0000000..6c176a7 --- /dev/null +++ b/doc/rfc/rfc7812.txt @@ -0,0 +1,2467 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Atlas +Request for Comments: 7812 C. Bowers +Category: Standards Track Juniper Networks +ISSN: 2070-1721 G. Enyedi + Ericsson + June 2016 + + + An Architecture for IP/LDP Fast Reroute + Using Maximally Redundant Trees (MRT-FRR) + +Abstract + + This document defines the architecture for IP and LDP Fast Reroute + using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology + that gives link-protection and node-protection with 100% coverage in + any network topology that is still connected after the failure. + +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 7841. + + 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/rfc7812. + +Copyright Notice + + Copyright (c) 2016 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. + + + + + +Atlas, et al. Standards Track [Page 1] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Importance of 100% Coverage . . . . . . . . . . . . . . . 4 + 1.2. Partial Deployment and Backwards Compatibility . . . . . 5 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 7 + 5. MRT and Fast Reroute . . . . . . . . . . . . . . . . . . . . 9 + 6. Unicast Forwarding with MRT Fast Reroute . . . . . . . . . . 9 + 6.1. Introduction to MRT Forwarding Options . . . . . . . . . 10 + 6.1.1. MRT LDP Labels . . . . . . . . . . . . . . . . . . . 10 + 6.1.1.1. Topology-Scoped FEC Encoded Using a Single Label + (Option 1A) . . . . . . . . . . . . . . . . . . . 10 + 6.1.1.2. Topology and FEC Encoded Using a Two-Label Stack + (Option 1B) . . . . . . . . . . . . . . . . . . . 11 + 6.1.1.3. Compatibility of MRT LDP Label Options 1A and 1B 12 + 6.1.1.4. Required Support for MRT LDP Label Options . . . 12 + 6.1.2. MRT IP Tunnels (Options 2A and 2B) . . . . . . . . . 12 + 6.2. Forwarding LDP Unicast Traffic over MRT Paths . . . . . . 13 + 6.2.1. Forwarding LDP Traffic Using MRT LDP Label Option 1A 13 + 6.2.2. Forwarding LDP Traffic Using MRT LDP Label Option 1B 14 + 6.2.3. Other Considerations for Forwarding LDP Traffic Using + MRT LDP Labels . . . . . . . . . . . . . . . . . . . 14 + 6.2.4. Required Support for LDP Traffic . . . . . . . . . . 14 + 6.3. Forwarding IP Unicast Traffic over MRT Paths . . . . . . 14 + 6.3.1. Tunneling IP Traffic Using MRT LDP Labels . . . . . . 15 + 6.3.1.1. Tunneling IP Traffic Using MRT LDP Label Option + 1A . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.3.1.2. Tunneling IP Traffic Using MRT LDP Label Option + 1B . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.3.2. Tunneling IP Traffic Using MRT IP Tunnels . . . . . . 16 + 6.3.3. Required Support for IP Traffic . . . . . . . . . . . 16 + 7. MRT Island Formation . . . . . . . . . . . . . . . . . . . . 16 + 7.1. IGP Area or Level . . . . . . . . . . . . . . . . . . . . 17 + 7.2. Support for a Specific MRT Profile . . . . . . . . . . . 17 + 7.3. Excluding Additional Routers and Interfaces from the MRT + Island . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.3.1. Existing IGP Exclusion Mechanisms . . . . . . . . . . 18 + 7.3.2. MRT-Specific Exclusion Mechanism . . . . . . . . . . 19 + 7.4. Connectivity . . . . . . . . . . . . . . . . . . . . . . 19 + 7.5. Algorithm for MRT Island Identification . . . . . . . . . 19 + 8. MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 8.1. MRT Profile Options . . . . . . . . . . . . . . . . . . . 19 + 8.2. Router-Specific MRT Parameters . . . . . . . . . . . . . 21 + 8.3. Default MRT Profile . . . . . . . . . . . . . . . . . . . 21 + 9. LDP Signaling Extensions and Considerations . . . . . . . . . 22 + + + + +Atlas, et al. Standards Track [Page 2] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + 10. Inter-area Forwarding Behavior . . . . . . . . . . . . . . . 23 + 10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A . . 23 + 10.1.1. Motivation for Creating the Rainbow-FEC . . . . . . 24 + 10.2. ABR Forwarding Behavior with IP Tunneling (Option 2) . . 24 + 10.3. ABR Forwarding Behavior with MRT LDP Label Option 1B . . 25 + 11. Prefixes Multiply Attached to the MRT Island . . . . . . . . 26 + 11.1. Protecting Multihomed Prefixes Using Tunnel Endpoint + Selection . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.2. Protecting Multihomed Prefixes Using Named Proxy-Nodes . 29 + 11.3. MRT Alternates for Destinations outside the MRT Island . 31 + 12. Network Convergence and Preparing for the Next Failure . . . 32 + 12.1. Micro-loop Prevention and MRTs . . . . . . . . . . . . . 32 + 12.2. MRT Recalculation for the Default MRT Profile . . . . . 33 + 13. Operational Considerations . . . . . . . . . . . . . . . . . 34 + 13.1. Verifying Forwarding on MRT Paths . . . . . . . . . . . 34 + 13.2. Traffic Capacity on Backup Paths . . . . . . . . . . . . 34 + 13.3. MRT IP Tunnel Loopback Address Management . . . . . . . 36 + 13.4. MRT-FRR in a Network with Degraded Connectivity . . . . 36 + 13.5. Partial Deployment of MRT-FRR in a Network . . . . . . . 37 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 16.2. Informative References . . . . . . . . . . . . . . . . . 39 + Appendix A. Inter-level Forwarding Behavior for IS-IS . . . . . 41 + Appendix B. General Issues with Area Abstraction . . . . . . . . 42 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + +1. Introduction + + This document describes a solution for IP/LDP fast reroute [RFC5714]. + MRT-FRR creates two alternate forwarding trees that are distinct from + the primary next-hop forwarding used during stable operation. These + two trees are maximally diverse from each other, providing link and + node protection for 100% of paths and failures as long as the failure + does not cut the network into multiple pieces. This document defines + the architecture for IP/LDP fast reroute with MRT. + + [RFC7811] describes how to compute maximally redundant trees using a + specific algorithm: the MRT Lowpoint algorithm. The MRT Lowpoint + algorithm is used by a router that supports the Default MRT Profile, + as specified in this document. + + IP/LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR) uses + two maximally diverse forwarding topologies to provide alternates. A + primary next hop should be on only one of the diverse forwarding + + + +Atlas, et al. Standards Track [Page 3] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + topologies; thus, the other can be used to provide an alternate. + Once traffic has been moved to one of the MRTs by one Point of Local + Repair (PLR), that traffic is not subject to further repair actions + by another PLR, even in the event of multiple simultaneous failures. + Therefore, traffic repaired by MRT-FRR will not loop between + different PLRs responding to different simultaneous failures. + + While MRT provides 100% protection for a single link or node failure, + it may not protect traffic in the event of multiple simultaneous + failures, nor does it take into account Shared Risk Link Groups + (SRLGs). Also, while the MRT Lowpoint algorithm is computationally + efficient, it is also new. In order for MRT-FRR to function + properly, all of the other nodes in the network that support MRT must + correctly compute next hops based on the same algorithm and install + the corresponding forwarding state. This is in contrast to other FRR + methods where the calculation of backup paths generally involves + repeated application of the simpler and widely deployed Shortest Path + First (SPF) algorithm, and backup paths themselves reuse the + forwarding state used for shortest path forwarding of normal traffic. + Section 13 provides operational guidance related to verification of + MRT forwarding paths. + + In addition to supporting IP and LDP unicast fast reroute, the + diverse forwarding topologies and guarantee of 100% coverage permit + fast-reroute technology to be applied to multicast traffic as + described in [MRT-ARCH]. However, the current document does not + address the multicast applications of MRTs. + +1.1. Importance of 100% Coverage + + Fast reroute is based upon the single failure assumption: that the + time between single failures is long enough for a network to + reconverge and start forwarding on the new shortest paths. That does + not imply that the network will only experience one failure or + change. + + It is straightforward to analyze a particular network topology for + coverage. However, a real network does not always have the same + topology. For instance, maintenance events will take links or nodes + out of use. Simply costing out a link can have a significant effect + on what Loop-Free Alternates (LFAs) are available. Similarly, after + a single failure has happened, the topology is changed and its + associated coverage has changed as well. Finally, many networks have + new routers or links added and removed; each of those changes can + have an effect on the coverage for topology-sensitive methods such as + LFA and Remote LFA. If fast reroute is important for the network + services provided, then a method that guarantees 100% coverage is + important to accommodate natural network topology changes. + + + +Atlas, et al. Standards Track [Page 4] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + When a network needs to use Ordered FIB [RFC6976] or Nearside + Tunneling [RFC5715] as a micro-loop prevention mechanism [RFC5715], + then the whole IGP area needs to have alternates available. This + allows the micro-loop prevention mechanism, which requires slower + network convergence, to take the necessary time without adversely + impacting traffic. Without complete coverage, traffic to the + unprotected destinations will be dropped for significantly longer + than with current convergence -- where routers individually converge + as fast as possible. See Section 12.1 for more discussion of micro- + loop prevention and MRTs. + +1.2. Partial Deployment and Backwards Compatibility + + MRT-FRR supports partial deployment. Routers advertise their ability + to support MRT. Inside the MRT-capable connected group of routers + (referred to as an MRT Island), the MRTs are computed. Alternates to + destinations outside the MRT Island are computed and depend upon the + existence of a loop-free neighbor of the MRT Island for that + destination. MRT Islands are discussed in detail in Section 7, and + partial deployment is discussed in more detail in Section 13.5. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + network graph: A graph that reflects the network topology where all + links connect exactly two nodes and broadcast links have been + transformed into the standard pseudonode representation. + + cut-link: A link whose removal partitions the network. A cut-link + by definition must be connected between two cut-vertices. If + there are multiple parallel links, then they are referred to as + cut-links in this document if removing the set of parallel links + would partition the network graph. + + cut-vertex: A vertex whose removal partitions the network graph. + + 2-connected: A graph that has no cut-vertices. This is a graph + that requires two nodes to be removed before the network is + partitioned. + + 2-connected cluster: A maximal set of nodes that are 2-connected. + + block: Either a 2-connected cluster, a cut-edge, or a cut-vertex. + + + +Atlas, et al. Standards Track [Page 5] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + Redundant Trees (RT): A pair of trees where the path from any node + X to the root R along the first tree is node-disjoint with the + path from the same node X to the root along the second tree. + Redundant trees can always be computed in 2-connected graphs. + + Maximally Redundant Trees (MRT): A pair of trees where the path + from any node X to the root R along the first tree and the path + from the same node X to the root along the second tree share the + minimum number of nodes and the minimum number of links. Each + such shared node is a cut-vertex. Any shared links are cut-links. + In graphs that are not 2-connected, it is not possible to compute + RTs. However, it is possible to compute MRTs. MRTs are maximally + redundant in the sense that they are as redundant as possible + given the constraints of the network graph. + + Directed Acyclic Graph (DAG): A graph where all links are directed + and there are no cycles in it. + + Almost Directed Acyclic Graph (ADAG): A graph with one node + designated as the root. The graph has the property that if all + links incoming to the root were removed, then the resulting graph + would be a DAG. + + Generalized ADAG (GADAG): A graph that is the combination of the + ADAGs of all blocks. + + MRT-Red: MRT-Red is used to describe one of the two MRTs; it is + used to describe the associated forwarding topology and MPLS + Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the + decreasing MRT where links in the GADAG are taken in the direction + from a higher topologically ordered node to a lower one. + + MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is + used to described the associated forwarding topology and MPLS + MT-ID. Specifically, MRT-Blue is the increasing MRT where links + in the GADAG are taken in the direction from a lower topologically + ordered node to a higher one. + + Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the + multiple MRT forwarding topologies and to the default forwarding + topology. This is referred to as the Rainbow MRT MPLS MT-ID and + is used by LDP to reduce signaling and permit the same label to + always be advertised to all peers for the same (MT-ID, Prefix). + + MRT Island: The set of routers that support a particular MRT + profile and the links connecting them that support MRT. + + + + + +Atlas, et al. Standards Track [Page 6] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + Island Border Router (IBR): A router in the MRT Island that is + connected to a router not in the MRT Island, both of which are in + a common area or level. + + Island Neighbor (IN): A router that is not in the MRT Island but is + adjacent to an IBR and in the same area/level as the IBR. + + named proxy-node: A proxy-node can represent a destination prefix + that can be attached to the MRT Island via at least two routers. + It is named if there is a way that traffic can be encapsulated to + reach specifically that proxy node; this could be because there is + an LDP FEC (Forwarding Equivalence Class) for the associated + prefix or because MRT-Red and MRT-Blue IP addresses are advertised + in an undefined fashion for that proxy-node. + +4. Maximally Redundant Trees (MRT) + + A pair of Maximally Redundant Trees is a pair of directed spanning + trees that provides maximally disjoint paths towards their common + root. Only links or nodes whose failure would partition the network + (i.e., cut-links and cut-vertices) are shared between the trees. The + MRT Lowpoint algorithm is given in [RFC7811]. This algorithm can be + computed in O(e + n log n); it is less than three SPFs. This + document describes how the MRTs can be used and not how to compute + them. + + MRT provides destination-based trees for each destination. Each + router stores its normal primary next hop(s) as well as MRT-Blue next + hop(s) and MRT-Red next hop(s) toward each destination. The + alternate will be selected between the MRT-Blue and MRT-Red. + + The most important thing to understand about MRTs is that for each + pair of destination-routed MRTs, there is a path from every node X to + the destination D on the Blue MRT that is as disjoint as possible + from the path on the Red MRT. + + For example, in Figure 1, there is a network graph that is + 2-connected in (a) and associated MRTs in (b) and (c). One can + consider the paths from B to R; on the Blue MRT, the paths are + B->F->D->E->R or B->C->D->E->R. On the Red MRT, the path is B->A->R. + These are clearly link and node-disjoint. These MRTs are redundant + trees because the paths are disjoint. + + + + + + + + + +Atlas, et al. Standards Track [Page 7] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| + | | | | ^ | | | + | | | V | | V V + [R] [F] [C] [R] [F] [C] [R] [F] [C] + | | | ^ ^ ^ | | + | | | | | | V | + [A]---[B]---| [A]-->[B]---| [A]<--[B]<--| + + (a) (b) (c) + a 2-connected graph Blue MRT towards R Red MRT towards R + + Figure 1: A 2-Connected Network + + By contrast, in Figure 2, the network in (a) is not 2-connected. If + C, G, or the link C<->G failed, then the network would be + partitioned. It is clearly impossible to have two link-disjoint or + node-disjoint paths from G, J, or H to R. The MRTs given in (b) and + (c) offer paths that are as disjoint as possible. For instance, the + paths from B to R are the same as in Figure 1 and the path from G to + R on the Blue MRT is G->C->D->E->R and on the Red MRT is + G->C->B->A->R. + + [E]---[D]---| |---[J] + | | | | | + | | | | | + [R] [F] [C]---[G] | + | | | | | + | | | | | + [A]---[B]---| |---[H] + + (a) a graph that is not 2-connected + + [E]<--[D]<--| [J] [E]-->[D]---| |---[J] + | ^ | | | | | ^ + V | | | V V V | + [R] [F] [C]<--[G] | [R] [F] [C]<--[G] | + ^ ^ ^ | ^ | | | + | | | V | V | | + [A]-->[B]---| |---[H] [A]<--[B]<--| [H] + + (b) Blue MRT towards R (c) Red MRT towards R + + Figure 2: A Network That Is Not 2-Connected + + + + + + + + +Atlas, et al. Standards Track [Page 8] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +5. MRT and Fast Reroute + + In normal IGP routing, each router has its Shortest Path Tree (SPT) + to all destinations. From the perspective of a particular + destination, D, this looks like a reverse SPT (rSPT). To use MRT, in + addition, each destination D has two MRTs associated with it; by + convention these will be called the MRT-Blue and MRT-Red. MRT-FRR is + realized by using multi-topology forwarding. There is a MRT-Blue + forwarding topology and a MRT-Red forwarding topology. + + Any IP/LDP fast-reroute technique beyond LFA requires an additional + dataplane procedure, such as an additional forwarding mechanism. The + well-known options are multi-topology forwarding (used by MRT-FRR), + tunneling (e.g., [RFC6981] or [RFC7490]), and per-interface + forwarding (e.g., Loop-Free Failure Insensitive Routing in + [EnyediThesis]). + + When there is a link or node failure affecting, but not partitioning, + the network, each node will still have at least one path via one of + the MRTs to reach the destination D. For example, in Figure 2, B + would normally forward traffic to R across the path B->A->R. If the + B<->A link fails, then B could use the MRT-Blue path B->F->D->E->R. + + As is always the case with fast-reroute technologies, forwarding does + not change until a local failure is detected. Packets are forwarded + along the shortest path. The appropriate alternate to use is pre- + computed. [RFC7811] describes exactly how to determine whether the + MRT-Blue next hops or the MRT-Red next hops should be the MRT + alternate next hops for a particular primary next hop to a particular + destination. + + MRT alternates are always available to use. It is a local decision + whether to use an MRT alternate, an LFA, or some other type of + alternate. + + As described in [RFC5286], when a worse failure than is anticipated + happens, using LFAs that are not downstream neighbors can cause + looping among alternates. Section 1.1 of [RFC5286] gives an example + of link-protecting alternates causing a loop on node failure. Even + if a worse failure than anticipated happens, the use of MRT + alternates will not cause looping. + +6. Unicast Forwarding with MRT Fast Reroute + + There are three possible types of routers involved in forwarding a + packet along an MRT path. At the MRT ingress router, the packet + leaves the shortest path to the destination and follows an MRT path + to the destination. In an FRR application, the MRT ingress router is + + + +Atlas, et al. Standards Track [Page 9] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + the PLR. An MRT transit router takes a packet that arrives already + associated with the particular MRT, and forwards it on that same MRT. + In some situations (to be discussed later), the packet will need to + leave the MRT path and return to the shortest path. This takes place + at the MRT egress router. The MRT ingress and egress functionality + may depend on the underlying type of packet being forwarded (LDP or + IP). The MRT transit functionality is independent of the type of + packet being forwarded. We first consider several MRT transit + forwarding mechanisms. Then, we look at how these forwarding + mechanisms can be applied to carrying LDP and IP traffic. + +6.1. Introduction to MRT Forwarding Options + + The following options for MRT forwarding mechanisms are considered. + + 1. MRT LDP Labels + + A. Topology-scoped FEC encoded using a single label + + B. Topology and FEC encoded using a two-label stack + + 2. MRT IP Tunnels + + A. MRT IPv4 Tunnels + + B. MRT IPv6 Tunnels + +6.1.1. MRT LDP Labels + + We consider two options for the MRT forwarding mechanisms using MRT + LDP labels. + +6.1.1.1. Topology-Scoped FEC Encoded Using a Single Label (Option 1A) + + [RFC7307] provides a mechanism to distribute FEC-label bindings + scoped to a given MPLS topology (represented by MPLS MT-ID). To use + multi-topology LDP to create MRT forwarding topologies, we associate + two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies, + in addition to the default shortest path forwarding topology with + MT-ID=0. + + With this forwarding mechanism, a single label is distributed for + each topology-scoped FEC. For a given FEC in the default topology + (call it default-FEC-A), two additional topology-scoped FECs would be + created, corresponding to the Red and Blue MRT forwarding topologies + (call them red-FEC-A and blue-FEC-A). A router supporting this MRT + transit forwarding mechanism advertises a different FEC-label binding + for each of the three topology-scoped FECs. When a packet is + + + +Atlas, et al. Standards Track [Page 10] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + received with a label corresponding to red-FEC-A (for example), an + MRT transit router will determine the next hop for the MRT-Red + forwarding topology for that FEC, swap the incoming label with the + outgoing label corresponding to red-FEC-A learned from the MRT-Red + next-hop router, and forward the packet. + + This forwarding mechanism has the useful property that the FEC + associated with the packet is maintained in the labels at each hop + along the MRT. We will take advantage of this property when + specifying how to carry LDP traffic on MRT paths using multi-topology + LDP labels. + + This approach is very simple for hardware to support. However, it + reduces the label space for other uses, and it increases the memory + needed to store the labels and the communication required by LDP to + distribute FEC-label bindings. In general, this approach will also + increase the time needed to install the FRR entries in the Forwarding + Information Base (FIB) and, hence, the time needed before the next + failure can be protected. + + This forwarding option uses the LDP signaling extensions described in + [RFC7307]. The MRT-specific LDP extensions required to support this + option will be described elsewhere. + +6.1.1.2. Topology and FEC Encoded Using a Two-Label Stack (Option 1B) + + With this forwarding mechanism, a two-label stack is used to encode + the topology and the FEC of the packet. The top label (topology-id + label) identifies the MRT forwarding topology, while the second label + (FEC label) identifies the FEC. The top label would be a new FEC + type with two values corresponding to MRT Red and Blue topologies. + + When an MRT transit router receives a packet with a topology-id + label, the router pops the top label and uses that it to guide the + next-hop selection in combination with the next label in the stack + (the FEC label). The router then swaps the FEC label, using the FEC- + label bindings learned through normal LDP mechanisms. The router + then pushes the topology-id label for the next hop. + + As with Option 1A, this forwarding mechanism also has the useful + property that the FEC associated with the packet is maintained in the + labels at each hop along the MRT. + + This forwarding mechanism has minimal usage of additional labels, + memory and LDP communication. It does increase the size of packets + and the complexity of the required label operations and lookups. + + + + + +Atlas, et al. Standards Track [Page 11] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + This forwarding option is consistent with context-specific label + spaces, as described in [RFC5331]. However, the precise LDP behavior + required to support this option for MRT has not been specified. + +6.1.1.3. Compatibility of MRT LDP Label Options 1A and 1B + + MRT transit forwarding based on MRT LDP Label options 1A and 1B can + coexist in the same network, with a packet being forwarded along a + single MRT path using the single label of Option 1A for some hops and + the two-label stack of Option 1B for other hops. However, to + simplify the process of MRT Island formation, we require that all + routers in the MRT Island support at least one common forwarding + mechanism. As an example, the Default MRT Profile requires support + for the MRT LDP Label Option 1A forwarding mechanism. This ensures + that the routers in an MRT island supporting the Default MRT Profile + will be able to establish MRT forwarding paths based on MRT LDP Label + Option 1A. However, an implementation supporting Option 1A may also + support Option 1B. If the scaling or performance characteristics for + the two options differ in this implementation, then it may be + desirable for a pair of adjacent routers to use Option 1B labels + instead of the Option 1A labels. If those routers successfully + negotiate the use of Option 1B labels, they are free to use them. + This can occur without any of the other routers in the MRT Island + being made aware of it. + + Note that this document only defines the Default MRT Profile, which + requires support for the MRT LDP Label Option 1A forwarding + mechanism. + +6.1.1.4. Required Support for MRT LDP Label Options + + If a router supports a profile that includes the MRT LDP Label Option + 1A for the MRT transit forwarding mechanism, then it MUST support + Option 1A, which encodes topology-scoped FECs using a single label. + The router MAY also support Option 1B. + + If a router supports a profile that includes the MRT LDP Label Option + 1B for the MRT transit forwarding mechanism, then it MUST support + Option 1B, which encodes the topology and FEC using a two-label + stack. The router MAY also support Option 1A. + +6.1.2. MRT IP Tunnels (Options 2A and 2B) + + IP tunneling can also be used as an MRT transit forwarding mechanism. + Each router supporting this MRT transit forwarding mechanism + announces two additional loopback addresses and their associated MRT + color. Those addresses are used as destination addresses for MRT- + blue and MRT-red IP tunnels, respectively. The special loopback + + + +Atlas, et al. Standards Track [Page 12] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + addresses allow the transit nodes to identify the traffic as being + forwarded along either the MRT-blue or MRT-red topology to reach the + tunnel destination. For example, an MRT ingress router can cause a + packet to be tunneled along the MRT-red path to router X by + encapsulating the packet using the MRT-red loopback address + advertised by router X. Upon receiving the packet, router X would + remove the encapsulation header and forward the packet based on the + original destination address. + + Either IPv4 (Option 2A) or IPv6 (Option 2B) can be used as the + tunneling mechanism. + + Note that the two forwarding mechanisms using LDP Label options do + not require additional loopbacks per router, as is required by the IP + tunneling mechanism. This is because LDP labels are used on a hop- + by-hop basis to identify MRT-blue and MRT-red forwarding topologies. + +6.2. Forwarding LDP Unicast Traffic over MRT Paths + + In the previous section, we examined several options for providing + MRT transit forwarding functionality, which is independent of the + type of traffic being carried. We now look at the MRT ingress + functionality, which will depend on the type of traffic being carried + (IP or LDP). We start by considering LDP traffic. + + We also simplify the initial discussion by assuming that the network + consists of a single IGP area, and that all routers in the network + participate in MRT. Other deployment scenarios that require MRT + egress functionality are considered later in this document. + + In principle, it is possible to carry LDP traffic in MRT IP tunnels. + However, for LDP traffic, it is desirable to avoid tunneling. + Tunneling LDP traffic to a remote node requires knowledge of remote + FEC-label bindings so that the LDP traffic can continue to be + forwarded properly when it leaves the tunnel. This requires targeted + LDP sessions, which can add management complexity. As described + below, the two MRT forwarding mechanisms that use LDP labels do not + require targeted LDP sessions. + +6.2.1. Forwarding LDP Traffic Using MRT LDP Label Option 1A + + The MRT LDP Label Option 1A forwarding mechanism uses topology-scoped + FECs encoded using a single label as described in Section 6.1.1.1. + When a PLR receives an LDP packet that needs to be forwarded on the + MRT-Red (for example), it does a label swap operation, replacing the + usual LDP label for the FEC with the MRT-Red label for that FEC + received from the next-hop router in the MRT-Red computed by the PLR. + When the next-hop router in the MRT-Red receives the packet with the + + + +Atlas, et al. Standards Track [Page 13] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + MRT-Red label for the FEC, the MRT transit forwarding functionality + continues as described in Section 6.1.1.1. In this way, the original + FEC associated with the packet is maintained at each hop along the + MRT. + +6.2.2. Forwarding LDP Traffic Using MRT LDP Label Option 1B + + The MRT LDP Label Option 1B forwarding mechanism encodes the topology + and the FEC using a two-label stack as described in Section 6.1.1.2. + When a PLR receives an LDP packet that needs to be forwarded on the + MRT-Red, it first does a normal LDP label swap operation, replacing + the incoming normal LDP label associated with a given FEC with the + outgoing normal LDP label for that FEC learned from the next hop on + the MRT-Red. In addition, the PLR pushes the topology-id label + associated with the MRT-Red, and forward the packet to the + appropriate next hop on the MRT-Red. When the next-hop router in the + MRT-Red receives the packet with the MRT-Red label for the FEC, the + MRT transit forwarding functionality continues as described in + Section 6.1.1.2. As with Option 1A, the original FEC associated with + the packet is maintained at each hop along the MRT. + +6.2.3. Other Considerations for Forwarding LDP Traffic Using MRT LDP + Labels + + Note that forwarding LDP traffic using MRT LDP Labels can be done + without the use of targeted LDP sessions when an MRT path to the + destination FEC is used. The alternates selected in [RFC7811] use + the MRT path to the destination FEC, so targeted LDP sessions are not + needed. If instead one found it desirable to have the PLR use an MRT + to reach the primary next-next-hop for the FEC, and then continue + forwarding the LDP packet along the shortest path from the primary + next-next-hop, this would require tunneling to the primary next-next- + hop and a targeted LDP session for the PLR to learn the FEC-label + binding for primary next-next-hop to correctly forward the packet. + +6.2.4. Required Support for LDP Traffic + + For greatest hardware compatibility, routers implementing MRT fast + reroute of LDP traffic MUST support Option 1A of encoding the MT-ID + in the labels (See Section 9). + +6.3. Forwarding IP Unicast Traffic over MRT Paths + + For IPv4 traffic, there is no currently practical alternative except + tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red + forwarding topology. For IPv6 traffic, in principle, one could + define bits in the IPv6 options header to indicate the MRT-Blue or + MRT-Red forwarding topology. However, in this document, we have + + + +Atlas, et al. Standards Track [Page 14] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + chosen not to define a solution that would work for IPv6 traffic but + not for IPv4 traffic. + + The choice of tunnel egress is flexible since any router closer to + the destination than the next hop can work. This architecture + assumes that the original destination in the area is selected (see + Section 11 for handling of multihomed prefixes); another possible + choice is the next-next-hop towards the destination. As discussed in + the previous section, for LDP traffic, using the MRT to the original + destination simplifies MRT-FRR by avoiding the need for targeted LDP + sessions to the next-next-hop. For IP, that consideration doesn't + apply. + + Some situations require tunneling IP traffic along an MRT to a tunnel + endpoint that is not the destination of the IP traffic. These + situations will be discussed in detail later. We note here that an + IP packet with a destination in a different IGP area/level from the + PLR should be tunneled on the MRT to the Area Border Router (ABR) or + Level Border Router (LBR) on the shortest path to the destination. + For a destination outside of the PLR's MRT Island, the packet should + be tunneled on the MRT to a non-proxy-node immediately before the + named proxy-node on that particular color MRT. + +6.3.1. Tunneling IP Traffic Using MRT LDP Labels + + An IP packet can be tunneled along an MRT path by pushing the + appropriate MRT LDP label(s). Tunneling using LDP labels, as opposed + to IP headers, has the advantage that more installed routers can do + line-rate encapsulation and decapsulation using LDP than using IP. + Also, no additional IP addresses would need to be allocated or + signaled. + +6.3.1.1. Tunneling IP Traffic Using MRT LDP Label Option 1A + + The MRT LDP Label Option 1A forwarding mechanism uses topology-scoped + FECs encoded using a single label as described in Section 6.1.1.1. + When a PLR receives an IP packet that needs to be forwarded on the + MRT-Red to a particular tunnel endpoint, it does a label push + operation. The label pushed is the MRT-Red label for a FEC + originated by the tunnel endpoint, learned from the next hop on the + MRT-Red. + +6.3.1.2. Tunneling IP Traffic Using MRT LDP Label Option 1B + + The MRT LDP Label Option 1B forwarding mechanism encodes the topology + and the FEC using a two-label stack as described in Section 6.1.1.2. + When a PLR receives an IP packet that needs to be forwarded on the + MRT-Red to a particular tunnel endpoint, the PLR pushes two labels on + + + +Atlas, et al. Standards Track [Page 15] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + the IP packet. The first (inner) label is the normal LDP label + learned from the next hop on the MRT-Red, associated with a FEC + originated by the tunnel endpoint. The second (outer) label is the + topology-id label associated with the MRT-Red. + + For completeness, we note here a potential variation that uses a + single label as opposed to two labels. In order to tunnel an IP + packet over an MRT to the destination of the IP packet as opposed to + an arbitrary tunnel endpoint, one could just push a topology-id label + directly onto the packet. An MRT transit router would need to pop + the topology-id label, do an IP route lookup in the context of that + topology-id label, and push the topology-id label. + +6.3.2. Tunneling IP Traffic Using MRT IP Tunnels + + In order to tunnel over the MRT to a particular tunnel endpoint, the + PLR encapsulates the original IP packet with an additional IP header + using the MRT-Blue or MRT-Red loopback address of the tunnel + endpoint. + +6.3.3. Required Support for IP Traffic + + For greatest hardware compatibility and ease in removing the MRT- + topology marking at area/level boundaries, routers that support MPLS + and implement IP MRT fast reroute MUST support tunneling of IP + traffic using MRT LDP Label Option 1A (topology-scoped FEC encoded + using a single label). + +7. MRT Island Formation + + The purpose of communicating support for MRT is to indicate that the + MRT-Blue and MRT-Red forwarding topologies are created for transit + traffic. The MRT architecture allows for different, potentially + incompatible options. In order to create consistent MRT forwarding + topologies, the routers participating in a particular MRT Island need + to use the same set of options. These options are grouped into MRT + profiles. In addition, the routers in an MRT Island all need to use + the same set of nodes and links within the Island when computing the + MRT forwarding topologies. This section describes the information + used by a router to determine the nodes and links to include in a + particular MRT Island. Some information already exists in the IGPs + and can be used by MRT in Island formation, subject to the + interpretation defined here. + + Other information needs to be communicated between routers for which + there do not currently exist protocol extensions. This new + information needs to be shared among all routers in an IGP area, so + + + + +Atlas, et al. Standards Track [Page 16] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + defining extensions to existing IGPs to carry this information makes + sense. These new protocol extensions will be defined elsewhere. + + Deployment scenarios using multi-topology OSPF or IS-IS, or running + both IS-IS and OSPF on the same routers is out of scope for this + specification. As with LFA, MRT-FRR does not support OSPF Virtual + Links. + + At a high level, an MRT Island is defined as the set of routers + supporting the same MRT profile, in the same IGP area/level and with + bidirectional links interconnecting those routers. More detailed + descriptions of these criteria are given below. + +7.1. IGP Area or Level + + All links in an MRT Island are bidirectional and belong to the same + IGP area or level. For IS-IS, a link belonging to both Level-1 and + Level-2 would qualify to be in multiple MRT Islands. A given ABR or + LBR can belong to multiple MRT Islands, corresponding to the areas or + levels in which it participates. Inter-area forwarding behavior is + discussed in Section 10. + +7.2. Support for a Specific MRT Profile + + All routers in an MRT Island support the same MRT profile. A router + advertises support for a given MRT profile using an 8-bit MRT Profile + ID value. The "MRT Profile Identifier Registry" is defined in this + document. The protocol extensions for advertising the MRT Profile ID + value will be defined in a future specification. A given router can + support multiple MRT profiles and participate in multiple MRT + Islands. The options that make up an MRT Profile, as well as the + Default MRT Profile, are defined in Section 8. + + The process of MRT Island formation takes place independently for + each MRT profile advertised by a given router. For example, consider + a network with 40 connected routers in the same area advertising + support for MRT Profile A and MRT Profile B. Two distinct MRT + Islands will be formed corresponding to Profile A and Profile B, with + each island containing all 40 routers. A complete set of maximally + redundant trees will be computed for each island following the rules + defined for each profile. If we add a third MRT Profile to this + example, with Profile C being advertised by a connected subset of 30 + routers, there will be a third MRT Island formed corresponding to + those 30 routers, and a third set of maximally redundant trees will + be computed. In this example, 40 routers would compute and install + two sets of MRT transit forwarding entries corresponding to Profiles + A and B, while 30 routers would compute and install three sets of MRT + transit forwarding entries corresponding to Profiles A, B, and C. + + + +Atlas, et al. Standards Track [Page 17] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +7.3. Excluding Additional Routers and Interfaces from the MRT Island + + MRT takes into account existing IGP mechanisms for discouraging + traffic from using particular links and routers, and it introduces an + MRT-specific exclusion mechanism for links. + +7.3.1. Existing IGP Exclusion Mechanisms + + Mechanisms for discouraging traffic from using particular links + already exist in IS-IS and OSPF. In IS-IS, an interface configured + with a metric of 2^24-2 (0xFFFFFE) will only be used as a last + resort. (An interface configured with a metric of 2^24-1 (0xFFFFFF) + will not be advertised into the topology.) In OSPF, an interface + configured with a metric of 2^16-1 (0xFFFF) will only be used as a + last resort. These metrics can be configured manually to enforce + administrative policy or they can be set in an automated manner as + with LDP IGP synchronization [RFC5443]. + + Mechanisms also already exist in IS-IS and OSPF to discourage or + prevent transit traffic from using a particular router. In IS-IS, + the overload bit is prevents transit traffic from using a router. + + For OSPFv2 and OSPFv3, [RFC6987] specifies setting all outgoing + interface metrics to 0xFFFF to discourage transit traffic from using + a router. ([RFC6987] defines the metric value 0xFFFF as + MaxLinkMetric, a fixed architectural value for OSPF.) For OSPFv3, + [RFC5340] specifies that a router be excluded from the intra-area SPT + computation if the V6-bit or R-bit of the Link State Advertisement + (LSA) options is not set in the Router LSA. + + The following rules for MRT Island formation ensure that MRT FRR + protection traffic does not use a link or router that is discouraged + or prevented from carrying traffic by existing IGP mechanisms. + + 1. A bidirectional link MUST be excluded from an MRT Island if + either the forward or reverse cost on the link is 0xFFFFFE (for + IS-IS) or 0xFFFF for OSPF. + + 2. A router MUST be excluded from an MRT Island if it is advertised + with the overload bit set (for IS-IS), or it is advertised with + metric values of 0xFFFF on all of its outgoing interfaces (for + OSPFv2 and OSPFv3). + + 3. A router MUST be excluded from an MRT Island if it is advertised + with either the V6-bit or R-bit of the LSA options not set in the + Router LSA. + + + + + +Atlas, et al. Standards Track [Page 18] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +7.3.2. MRT-Specific Exclusion Mechanism + + This architecture also defines a means of excluding an otherwise + usable link from MRT Islands. The protocol extensions for + advertising that a link is MRT-Ineligible will be defined elsewhere. + A link with either interface advertised as MRT-Ineligible MUST be + excluded from an MRT Island. Note that an interface advertised as + MRT-Ineligible by a router is ineligible with respect to all profiles + advertised by that router. + +7.4. Connectivity + + All of the routers in an MRT Island MUST be connected by + bidirectional links with other routers in the MRT Island. + Disconnected MRT Islands will operate independently of one another. + +7.5. Algorithm for MRT Island Identification + + An algorithm that allows a computing router to identify the routers + and links in the local MRT Island satisfying the above rules is given + in Section 5.2 of [RFC7811]. + +8. MRT Profile + + An MRT Profile is a set of values and options related to MRT + behavior. The complete set of options is designated by the + corresponding 8-bit Profile ID value. + + This document specifies the values and options that correspond to the + Default MRT Profile (Profile ID = 0). Future documents may define + other MRT Profiles by specifying the MRT Profile Options below. + +8.1. MRT Profile Options + + Below is a description of the values and options that define an MRT + Profile. + + MRT Algorithm: This identifies the particular algorithm for + computing maximally redundant trees used by the router for this + profile. + + MRT-Red MT-ID: This specifies the MPLS MT-ID to be associated with + the MRT-Red forwarding topology. It is allocated from the MPLS + Multi-Topology Identifiers Registry. + + MRT-Blue MT-ID: This specifies the MPLS MT-ID to be associated with + the MRT-Blue forwarding topology. It is allocated from the MPLS + Multi-Topology Identifiers Registry. + + + +Atlas, et al. Standards Track [Page 19] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + GADAG Root Selection Policy: This specifies the manner in which the + GADAG root is selected. All routers in the MRT Island need to use + the same GADAG root in the calculations used construct the MRTs. + A valid GADAG Root Selection Policy MUST be such that each router + in the MRT Island chooses the same GADAG root based on information + available to all routers in the MRT Island. GADAG Root Selection + Priority values, advertised as router-specific MRT parameters, MAY + be used in a GADAG Root Selection Policy. + + MRT Forwarding Mechanism: This specifies which forwarding mechanism + the router uses to carry transit traffic along MRT paths. A + router that supports a specific MRT forwarding mechanism must + program appropriate next hops into the forwarding plane. The + current options are MRT LDP Label Option 1A, MRT LDP Label Option + 1B, IPv4 Tunneling, IPv6 Tunneling, and None. If IPv4 is + supported, then both MRT-Red and MRT-Blue IPv4 loopback addresses + SHOULD be specified. If IPv6 is supported, both MRT-Red and MRT- + Blue IPv6 loopback addresses SHOULD be specified. + + Recalculation: Recalculation specifies the process and timing by + which new MRTs are computed after the topology has been modified. + + Area/Level Border Behavior: This specifies how traffic traveling on + the MRT-Blue or MRT-Red in one area should be treated when it + passes into another area. + + Other Profile-Specific Behavior: Depending upon the use-case for the + profile, there may be additional profile-specific behavior. + + When a new MRT Profile is defined, new and unique values should be + allocated from the "MPLS Multi-Topology Identifiers Registry", + corresponding to the MRT-Red and MRT-Blue MT-ID values for the new + MRT Profile. + + If a router advertises support for multiple MRT profiles, then it + MUST create the transit forwarding topologies for each of those, + unless the profile specifies the None option for the MRT Forwarding + Mechanism. + + The ability of MRT-FRR to support transit forwarding entries for + multiple profiles can be used to facilitate a smooth transition from + an existing deployed MRT Profile to a new MRT Profile. The new + profile can be activated in parallel with the existing profile, + installing the transit forwarding entries for the new profile without + affecting the transit forwarding entries for the existing profile. + Once the new transit forwarding state has been verified, the router + can be configured to use the alternates computed by the new profile + in the event of a failure. + + + +Atlas, et al. Standards Track [Page 20] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +8.2. Router-Specific MRT Parameters + + For some profiles, additional router-specific MRT parameters may need + to be advertised. While the set of options indicated by the MRT + Profile ID must be identical for all routers in an MRT Island, these + router-specific MRT parameters may differ between routers in the same + MRT Island. Several such parameters are described below. + + GADAG Root Selection Priority: A GADAG Root Selection Policy MAY + rely on the GADAG Root Selection Priority values advertised by + each router in the MRT Island. A GADAG Root Selection Policy may + use the GADAG Root Selection Priority to allow network operators + to configure a parameter to ensure that the GADAG root is selected + from a particular subset of routers. An example of this use of + the GADAG Root Selection Priority value by the GADAG Root + Selection Policy is given in the Default MRT Profile below. + + MRT-Red Loopback Address: This provides the router's loopback + address to reach the router via the MRT-Red forwarding topology. + It can be specified for either IPv4 or IPv6. Note that this + parameter is not needed to support the Default MRT Profile. + + MRT-Blue Loopback Address: This provides the router's loopback + address to reach the router via the MRT-Blue forwarding topology. + It can be specified for either IPv4 and IPv6. Note that this + parameter is not needed to support the Default MRT Profile. + + Protocol extensions for advertising a router's GADAG Root Selection + Priority value will be defined in other documents. Protocol + extensions for the advertising a router's MRT-Red and MRT-Blue + loopback addresses will be defined elsewhere. + +8.3. Default MRT Profile + + The following set of options defines the Default MRT Profile. The + Default MRT Profile is indicated by the MRT Profile ID value of 0. + + MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811]. + + MRT-Red MPLS MT-ID: This temporary registration has been allocated + from the "MPLS Multi-Topology Identifiers" registry. The + registration request appears in [LDP-MRT]. + + MRT-Blue MPLS MT-ID: This temporary registration has been allocated + from the "MPLS Multi-Topology Identifiers" registry. The + registration request appears in [LDP-MRT]. + + + + + +Atlas, et al. Standards Track [Page 21] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + GADAG Root Selection Policy: Among the routers in the MRT Island + with the lowest numerical value advertised for GADAG Root + Selection Priority, an implementation MUST pick the router with + the highest Router ID to be the GADAG root. Note that a lower + numerical value for GADAG Root Selection Priority indicates a + higher preference for selection. + + Forwarding Mechanisms: MRT LDP Label Option 1A + + Recalculation: Recalculation of MRTs SHOULD occur as described in + Section 12.2. This allows the MRT forwarding topologies to + support IP/LDP fast-reroute traffic. + + Area/Level Border Behavior: As described in Section 10, ABRs/LBRs + SHOULD ensure that traffic leaving the area also exits the MRT-Red + or MRT-Blue forwarding topology. + +9. LDP Signaling Extensions and Considerations + + The protocol extensions for LDP will be defined in another document. + A router must indicate that it has the ability to support MRT; having + this explicit allows the use of MRT-specific processing, such as + special handling of FECs sent with the Rainbow MRT MT-ID. + + A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies + to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles. + The FEC-label bindings for the default shortest-path-based MT-ID 0 + MUST still be sent (even though it could be inferred from the Rainbow + FEC-label bindings) to ensure continuous operation of normal LDP + forwarding. The Rainbow MRT MT-ID is defined to provide an easy way + to handle the special signaling that is needed at ABRs or LBRs. It + avoids the problem of needing to signal different MPLS labels to + different LDP neighbors for the same FEC. Because the Rainbow MRT + MT-ID is used only by ABRs/LBRs or an LDP egress router, it is not + MRT profile specific. + + The value of the Rainbow MRT MPLS MT-ID has been temporarily + allocated from the "MPLS Multi-Topology Identifiers" registry. The + registration request appears in [LDP-MRT]. + + + + + + + + + + + + +Atlas, et al. Standards Track [Page 22] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +10. Inter-area Forwarding Behavior + + An ABR/LBR has two forwarding roles. First, it forwards traffic + within areas. Second, it forwards traffic from one area into + another. These same two roles apply for MRT transit traffic. + Traffic on MRT-Red or MRT-Blue destined inside the area needs to stay + on MRT-Red or MRT-Blue in that area. However, it is desirable for + traffic leaving the area to also exit MRT-Red or MRT-Blue and return + to shortest path forwarding. + + For unicast MRT-FRR, the need to stay on an MRT forwarding topology + terminates at the ABR/LBR whose best route is via a different area/ + level. It is highly desirable to go back to the default forwarding + topology when leaving an area/level. There are three basic reasons + for this. First, the default topology uses shortest paths; the + packet will thus take the shortest possible route to the destination. + Second, this allows a single router failure that manifests itself in + multiple areas (as would be the case with an ABR/LBR failure) to be + separately identified and repaired around. Third, the packet can be + fast-rerouted again, if necessary, due to a second distinct failure + in a different area. + + In OSPF, an ABR that receives a packet on MRT-Red or MRT-Blue towards + destination Z should continue to forward the packet along MRT-Red or + MRT-Blue only if the best route to Z is in the same OSPF area as the + interface that the packet was received on. Otherwise, the packet + should be removed from MRT-Red or MRT-Blue and forwarded on the + shortest-path default forwarding topology. + + The above description applies to OSPF. The same essential behavior + also applies to IS-IS if one substitutes IS-IS level for OSPF area. + However, the analogy with OSPF is not exact. An interface in OSPF + can only be in one area, whereas an interface in IS-IS can be in both + Level-1 and Level-2. Therefore, to avoid confusion and address this + difference, we explicitly describe the behavior for IS-IS in + Appendix A. In the following sections, only the OSPF terminology is + used. + +10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A + + For LDP forwarding where a single label specifies (MT-ID, FEC), the + ABR is responsible for advertising the proper label to each neighbor. + Assume that an ABR has allocated three labels for a particular + destination: L_primary, L_blue, and L_red. To those routers in the + same area as the best route to the destination, the ABR advertises + the following FEC-label bindings: L_primary for the default topology, + L_blue for the MRT-Blue MT-ID, and L_red for the MRT-Red MT-ID, as + expected. However, to routers in other areas, the ABR advertises the + + + +Atlas, et al. Standards Track [Page 23] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + following FEC-label bindings: L_primary for the default topology and + L_primary for the Rainbow MRT MT-ID. Associating L_primary with the + Rainbow MRT MT-ID causes the receiving routers to use L_primary for + the MRT-Blue MT-ID and for the MRT-Red MT-ID. + + The ABR installs all next hops for the best area: primary next hops + for L_primary, MRT-Blue next hops for L_blue, and MRT-Red next hops + for L_red. Because the ABR advertised (Rainbow MRT MT-ID, FEC) with + L_primary to neighbors not in the best area, packets from those + neighbors will arrive at the ABR with a label L_primary and will be + forwarded into the best area along the default topology. By + controlling what labels are advertised, the ABR can thus enforce that + packets exiting the area do so on the shortest-path default topology. + +10.1.1. Motivation for Creating the Rainbow-FEC + + The desired forwarding behavior could be achieved in the above + example without using the Rainbow-FEC. This could be done by having + the ABR advertise the following FEC-label bindings to neighbors not + in the best area: L1_primary for the default topology, L1_primary for + the MRT-Blue MT-ID, and L1_primary for the MRT-Red MT-ID. Doing this + would require machinery to spoof the labels used in FEC-label binding + advertisements on a per-neighbor basis. Such label-spoofing + machinery does not currently exist in most LDP implementations and + doesn't have other obvious uses. + + Many existing LDP implementations do however have the ability to + filter FEC-label binding advertisements on a per-neighbor basis. The + Rainbow-FEC allows us to reuse the existing per-neighbor FEC + filtering machinery to achieve the desired result. By introducing + the Rainbow FEC, we can use per-neighbor FEC-filtering machinery to + advertise the FEC-label binding for the Rainbow-FEC (and filter those + for MRT-Blue and MRT-Red) to non-best-area neighbors of the ABR. + + An ABR may choose to either distribute the Rainbow-FEC or distribute + separate MRT-Blue and MRT-Red advertisements. This is a local + choice. A router that supports the MRT LDP Label Option 1A + forwarding mechanism MUST be able to receive and correctly interpret + the Rainbow-FEC. + +10.2. ABR Forwarding Behavior with IP Tunneling (Option 2) + + If IP tunneling is used, then the ABR behavior is dependent upon the + outermost IP address. If the outermost IP address is an MRT loopback + address of the ABR, then the packet is decapsulated and forwarded + based upon the inner IP address, which should go on the default SPT + topology. If the outermost IP address is not an MRT loopback address + of the ABR, then the packet is simply forwarded along the associated + + + +Atlas, et al. Standards Track [Page 24] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + forwarding topology. A PLR sending traffic to a destination outside + its local area/level will pick the MRT and use the associated MRT + loopback address of the selected ABR advertising the lowest cost to + the external destination. + + Thus, for these two MRT forwarding mechanisms (MRT LDP Label Option + 1A and IP tunneling Option 2), there is no need for additional + computation or per-area forwarding state. + +10.3. ABR Forwarding Behavior with MRT LDP Label Option 1B + + The other MRT forwarding mechanism described in Section 6 uses two + labels: a topology-id label and a FEC-label. This mechanism would + require that any router whose MRT-Red or MRT-Blue next hop is an ABR + would need to determine whether the ABR would forward the packet out + of the area/level. If so, then that router should pop off the + topology-id label before forwarding the packet to the ABR. + + For example, in Figure 3, if node H fails, node E has to put traffic + towards prefix p onto MRT-Red. But since node D knows that ABR1 will + use a best route from another area, it is safe for D to pop the + topology-id label and just forward the packet to ABR1 along the MRT- + Red next hop. ABR1 will use the shortest path in Area 10. + + In all cases for IS-IS and most cases for OSPF, the penultimate + router can determine what decision the adjacent ABR will make. The + one case where it can't be determined is when two ASBRs are in + different non-backbone areas attached to the same ABR, then the + ASBR's Area ID may be needed for tie-breaking (prefer the route with + the largest OSPF area ID), and the Area ID isn't announced as part of + the ASBR LSA. In this one case, suboptimal forwarding along the MRT + in the other area would happen. If that becomes a realistic + deployment scenario, protocol extensions could be developed to + address this issue. + + + + + + + + + + + + + + + + + +Atlas, et al. Standards Track [Page 25] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + +----[C]---- --[D]--[E] --[D]--[E] + | \ / \ / \ + p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+ + | / \ / | \ / | + +----[B]---- --[F]--[G] | --[F]--[G] | + | | + | other | + +----------[p]-------+ + area + + (a) Example topology (b) Proxy node view in Area 0 nodes + + + +----[C]<--- [D]->[E] + V \ \ + +-[A] Area 10 [ABR1] Area 0 [H]-+ + | ^ / / | + | +----[B]<--- [F]->[G] V + | | + +------------->[p]<--------------+ + + (c) rSPT towards destination p + + + + ->[D]->[E] -<[D]<-[E] + / \ / \ + [ABR1] Area 0 [H]-+ +-[ABR1] [H] + / | | \ + [F]->[G] V V -<[F]<-[G] + | | + | | + [p]<------+ +--------->[p] + + (d) MRT-Blue in Area 0 (e) MRT-Red in Area 0 + + Figure 3: ABR Forwarding Behavior and MRTs + +11. Prefixes Multiply Attached to the MRT Island + + How a computing router S determines its local MRT Island for each + supported MRT profile is already discussed in Section 7. + + There are two types of prefixes or FECs that may be multiply attached + to an MRT Island. The first type are multihomed prefixes that + usually connect at a domain or protocol boundary. The second type + represent routers that do not support the profile for the MRT Island. + + + + +Atlas, et al. Standards Track [Page 26] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + The key difference is whether the traffic, once out of the MRT + Island, might re-enter the MRT Island if a loop-free exit point is + not selected. + + FRR using LFA has the useful property that it is able to protect + multihomed prefixes against ABR failure. For instance, if a prefix + from the backbone is available via both ABR A and ABR B, if A fails, + then the traffic should be redirected to B. This can be accomplished + with MRT FRR as well. + + If ASBR protection is desired, this has additional complexities if + the ASBRs are in different areas. Similarly, protecting labeled BGP + traffic in the event of an ASBR failure has additional complexities + due to the per-ASBR label spaces involved. + + As discussed in [RFC5286], a multihomed prefix could be: + + o An out-of-area prefix announced by more than one ABR, + + o An AS-External route announced by two or more ASBRs, + + o A prefix with iBGP multipath to different ASBRs, + + o etc. + + See Appendix B for a discussion of a general issue with multihomed + prefixes connected in two different areas. + + There are also two different approaches to protection. The first is + tunnel endpoint selection where the PLR picks a router to tunnel to + where that router is loop-free with respect to the failure-point. + Conceptually, the set of candidate routers to provide LFAs expands to + all routers that can be reached via an MRT alternate, attached to the + prefix. + + The second is to use a proxy-node, which can be named via MPLS label + or IP address, and pick the appropriate label or IP address to reach + it on either MRT-Blue or MRT-Red as appropriate to avoid the failure + point. A proxy-node can represent a destination prefix that can be + attached to the MRT Island via at least two routers. It is termed a + named proxy-node if there is a way that traffic can be encapsulated + to reach specifically that proxy-node; this could be because there is + an LDP FEC for the associated prefix or because MRT-Red and MRT-Blue + IP addresses are advertised (in an as-yet undefined fashion) for that + proxy-node. Traffic to a named proxy-node may take a different path + than traffic to the attaching router; traffic is also explicitly + forwarded from the attaching router along a predetermined interface + towards the relevant prefixes. + + + +Atlas, et al. Standards Track [Page 27] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + For IP traffic, multihomed prefixes can use tunnel endpoint + selection. For IP traffic that is destined to a router outside the + MRT Island, if that router is the egress for a FEC advertised into + the MRT Island, then the named proxy-node approach can be used. + + For LDP traffic, there is always a FEC advertised into the MRT + Island. The named proxy-node approach should be used, unless the + computing router S knows the label for the FEC at the selected tunnel + endpoint. + + If a FEC is advertised from outside the MRT Island into the MRT + Island and the forwarding mechanism specified in the profile includes + LDP Label Option 1A, then the routers learning that FEC MUST also + advertise labels for (MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors + inside the MRT Island. Any router receiving a FEC corresponding to a + router outside the MRT Island or to a multihomed prefix MUST compute + and install the transit MRT-Blue and MRT-Red next hops for that FEC. + The FEC-label bindings for the topology-scoped FECs ((MT-ID 0, FEC), + (MRT-Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via LDP to + neighbors inside the MRT Island. + +11.1. Protecting Multihomed Prefixes Using Tunnel Endpoint Selection + + Tunnel endpoint selection is a local matter for a router in the MRT + Island since it pertains to selecting and using an alternate and does + not affect the transit MRT-Red and MRT-Blue forwarding topologies. + + Let the computing router be S and the next hop F be the node whose + failure is to be avoided. Let the destination be prefix p. Have A + be the router to which the prefix p is attached for S's shortest path + to p. + + The candidates for tunnel endpoint selection are those to which the + destination prefix is attached in the area/level. For a particular + candidate B, it is necessary to determine if B is loop-free to reach + p with respect to S and F for node-protection or at least with + respect to S and the link (S, F) for link-protection. If B will + always prefer to send traffic to p via a different area/level, then + this is definitional. Otherwise, distance-based computations are + necessary and an SPF from B's perspective may be necessary. The + following equations give the checks needed; the rationale is similar + to that given in [RFC5286]. In the inequalities below, D_opt(X,Y) + means the shortest distance from node X to node Y, and D_opt(X,p) + means the shortest distance from node X to prefix p. + + Loop-Free for S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p) + + Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p) + + + +Atlas, et al. Standards Track [Page 28] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + The latter is equivalent to the following, which avoids the need to + compute the shortest path from F to p. + + Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S, F) + + Finally, the rules for Endpoint selection are given below. The basic + idea is to repair to the prefix-advertising router selected for the + shortest-path and only to select and tunnel to a different endpoint + if necessary (e.g., A=F or F is a cut-vertex or the link (S,F) is a + cut-link). + + 1. Does S have a node-protecting alternate to A? If so, select + that. Tunnel the packet to A along that alternate. For example, + if LDP is the forwarding mechanism, then push the label (MRT-Red, + A) or (MRT-Blue, A) onto the packet. + + 2. If not, then is there a router B that is loop-free to reach p + while avoiding both F and S? If so, select B as the endpoint. + Determine the MRT alternate to reach B while avoiding F. Tunnel + the packet to B along that alternate. For example, with LDP, + push the label (MRT-Red, B) or (MRT-Blue, B) onto the packet. + + 3. If not, then does S have a link-protecting alternate to A? If + so, select that. + + 4. If not, then is there a router B that is loop-free to reach p + while avoiding S and the link from S to F? If so, select B as + the endpoint and the MRT alternate for reaching B from S that + avoid the link (S,F). + + The tunnel endpoint selected will receive a packet destined to itself + and, being the egress, will pop that MPLS label (or have signaled + Implicit Null) and forward based on what is underneath. This + suffices for IP traffic since the tunnel endpoint can use the IP + header of the original packet to continue forwarding the packet. + However, tunneling of LDP traffic requires targeted LDP sessions for + learning the FEC-label binding at the tunnel endpoint. + +11.2. Protecting Multihomed Prefixes Using Named Proxy-Nodes + + Instead, the named proxy-node method works with LDP traffic without + the need for targeted LDP sessions. It also has a clear advantage + over tunnel endpoint selection, in that it is possible to explicitly + forward from the MRT Island along an interface to a loop-free island + neighbor when that interface may not be a primary next hop. + + + + + + +Atlas, et al. Standards Track [Page 29] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + A named proxy-node represents one or more destinations and, for LDP + forwarding, has a FEC associated with it that is signaled into the + MRT Island. Therefore, it is possible to explicitly label packets to + go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT + Island, the label will swap to meaning (MT-ID 0, FEC). It would be + possible to have named proxy-nodes for IP forwarding, but this would + require extensions to signal two IP addresses to be associated with + MRT-Red and MRT-Blue for the proxy-node. A named proxy-node can be + uniquely represented by the two routers in the MRT Island to which it + is connected. The extensions to signal such IP addresses will be + defined elsewhere. The details of what label-bindings must be + originated will be described in another document. + + Computing the MRT next hops to a named proxy-node and the MRT + alternate for the computing router S to avoid a particular failure + node F is straightforward. The details of the simple constant-time + functions, Select_Proxy_Node_NHs() and + Select_Alternates_Proxy_Node(), are given in [RFC7811]. A key point + is that computing these MRT next hops and alternates can be done as + new named proxy-nodes are added or removed without requiring a new + MRT computation or impacting other existing MRT paths. This maps + very well to, for example, how OSPFv2 (see [RFC2328], Section 16.5) + does incremental updates for new summary-LSAs. + + The remaining question is how to attach the named proxy-node to the + MRT Island; all the routers in the MRT Island MUST do this + consistently. No more than two routers in the MRT Island can be + selected; one should only be selected if there are no others that + meet the necessary criteria. The named proxy-node is logically part + of the area/level. + + There are two sources for candidate routers in the MRT Island to + connect to the named proxy-node. The first set is made up of those + routers in the MRT Island that are advertising the prefix; the named- + proxy-cost assigned to each prefix-advertising router is the + announced cost to the prefix. The second set is made up of those + routers in the MRT Island that are connected to routers not in the + MRT Island but in the same area/level; such routers will be defined + as Island Border Routers (IBRs). The routers connected to the IBRs + that are not in the MRT Island and are in the same area/level as the + MRT Island are Island Neighbors (INs). + + Since packets sent to the named proxy-node along MRT-Red or MRT-Blue + may come from any router inside the MRT Island, it is necessary that + whatever router to which an IBR forwards the packet be loop-free with + respect to the whole MRT Island for the destination. Thus, an IBR is + a candidate router only if it possesses at least one IN whose + shortest path to the prefix does not enter the MRT Island. A method + + + +Atlas, et al. Standards Track [Page 30] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + for identifying Loop-Free Island Neighbors (LFINs) is given in + [RFC7811]. The named-proxy-cost assigned to each (IBR, IN) pair is + cost(IBR, IN) + D_opt(IN, prefix). + + From the set of prefix-advertising routers and the set of IBRs with + at least one LFIN, the two routers with the lowest named-proxy-cost + are selected. Ties are broken based upon the lowest Router ID. For + ease of discussion, the two selected routers will be referred to as + proxy-node attachment routers. + + A proxy-node attachment router has a special forwarding role. When a + packet is received destined to (MRT-Red, prefix) or (MRT-Blue, + prefix), if the proxy-node attachment router is an IBR, it MUST swap + to the shortest path forwarding topology (e.g., swap to the label for + (MT-ID 0, prefix) or remove the outer IP encapsulation) and forward + the packet to the IN whose cost was used in the selection. If the + proxy-node attachment router is not an IBR, then the packet MUST be + removed from the MRT forwarding topology and sent along the + interface(s) that caused the router to advertise the prefix; this + interface might be out of the area/level/AS. + +11.3. MRT Alternates for Destinations outside the MRT Island + + A natural concern with new functionality is how to have it be useful + when it is not deployed across an entire IGP area. In the case of + MRT FRR, where it provides alternates when appropriate LFAs aren't + available, there are also deployment scenarios where it may make + sense to only enable some routers in an area with MRT FRR. A simple + example of such a scenario would be a ring of six or more routers + that is connected via two routers to the rest of the area. + + Destinations inside the local island can obviously use MRT + alternates. Destinations outside the local island can be treated + like a multihomed prefix and either endpoint selection or Named + Proxy-Nodes can be used. Named proxy-nodes MUST be supported when + LDP forwarding is supported and a label-binding for the destination + is sent to an IBR. + + Naturally, there are more-complicated options to improve coverage, + such as connecting multiple MRT Islands across tunnels, but the need + for the additional complexity has not been justified. + + + + + + + + + + +Atlas, et al. Standards Track [Page 31] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +12. Network Convergence and Preparing for the Next Failure + + After a failure, MRT detours ensure that packets reach their intended + destination while the IGP has not reconverged onto the new topology. + As link-state updates reach the routers, the IGP process calculates + the new shortest paths. Two things need attention: micro-loop + prevention and MRT recalculation. + +12.1. Micro-loop Prevention and MRTs + + A micro-loop is a transient packet-forwarding loop among two or more + routers that can occur during convergence of IGP forwarding state. + [RFC5715] discusses several techniques for preventing micro-loops. + This section discusses how MRT-FRR relates to two of the micro-loop + prevention techniques discussed in [RFC5715]: Nearside and Farside + Tunneling. + + In Nearside Tunneling, a router (PLR) adjacent to a failure performs + local repair and informs remote routers of the failure. The remote + routers initially tunnel affected traffic to the nearest PLR, using + tunnels that are unaffected by the failure. Once the forwarding + state for normal shortest path routing has converged, the remote + routers return the traffic to shortest path forwarding. MRT-FRR is + relevant for Nearside Tunneling for the following reason. The + process of tunneling traffic to the PLRs and waiting a sufficient + amount of time for IGP forwarding state convergence with Nearside + Tunneling means that traffic will generally rely on the local repair + at the PLR for longer than it would in the absence of Nearside + Tunneling. Since MRT-FRR provides 100% coverage for single link and + node failure, it may be an attractive option to provide the local + repair paths when Nearside Tunneling is deployed. + + MRT-FRR is also relevant for the Farside Tunneling micro-loop + prevention technique. In Farside Tunneling, remote routers tunnel + traffic affected by a failure to a node downstream of the failure + with respect to traffic destination. This node can be viewed as + being on the farside of the failure with respect to the node + initiating the tunnel. Note that the discussion of Farside Tunneling + in [RFC5715] focuses on the case where the farside node is + immediately adjacent to a failed link or node. However, the farside + node may be any node downstream of the failure with respect to + traffic destination, including the destination itself. The tunneling + mechanism used to reach the farside node must be unaffected by the + failure. The alternative forwarding paths created by MRT-FRR have + the potential to be used to forward traffic from the remote routers + upstream of the failure all the way to the destination. In the event + of failure, either the MRT-Red or MRT-Blue path from the remote + upstream router to the destination is guaranteed to avoid a link + + + +Atlas, et al. Standards Track [Page 32] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + failure or inferred node failure. The MRT forwarding paths are also + guaranteed to not be subject to micro-loops because they are locked + to the topology before the failure. + + We note that the computations in [RFC7811] address the case of a PLR + adjacent to a failure determining which choice of MRT-Red or MRT-Blue + will avoid a failed link or node. More computation may be required + for an arbitrary remote upstream router to determine whether to + choose MRT-Red or MRT-Blue for a given destination and failure. + +12.2. MRT Recalculation for the Default MRT Profile + + This section describes how the MRT recalculation SHOULD be performed + for the Default MRT Profile. This is intended to support FRR + applications. Other approaches are possible, but they are not + specified in this document. + + When a failure event happens, traffic is put by the PLRs onto the MRT + topologies. After that, each router recomputes its SPT and moves + traffic over to that. Only after all the PLRs have switched to using + their SPTs and traffic has drained from the MRT topologies should + each router install the recomputed MRTs into the FIBs. + + At each router, therefore, the sequence is as follows: + + 1. Receive failure notification + + 2. Recompute SPT. + + 3. Install the new SPT in the FIB. + + 4. If the network was stable before the failure occurred, wait a + configured (or advertised) period for all routers to be using + their SPTs and traffic to drain from the MRTs. + + 5. Recompute MRTs. + + 6. Install new MRTs in the FIB. + + While the recomputed MRTs are not installed in the FIB, protection + coverage is lowered. Therefore, it is important to recalculate the + MRTs and install them quickly. + + New protocol extensions for advertising the time needed to recompute + shortest path routes and install them in the FIB will be defined + elsewhere. + + + + + +Atlas, et al. Standards Track [Page 33] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +13. Operational Considerations + + The following aspects of MRT-FRR are useful to consider when + deploying the technology in different operational environments and + network topologies. + +13.1. Verifying Forwarding on MRT Paths + + The forwarding paths created by MRT-FRR are not used by normal (non- + FRR) traffic. They are only used to carry FRR traffic for a short + period of time after a failure has been detected. It is RECOMMENDED + that an operator proactively monitor the MRT forwarding paths in + order to be certain that the paths will be able to carry FRR traffic + when needed. Therefore, an implementation SHOULD provide an operator + with the ability to test MRT paths with Operations, Administration, + and Maintenance (OAM) traffic. For example, when MRT paths are + realized using LDP labels distributed for topology-scoped FECs, an + implementation can use the MPLS ping and traceroute as defined in + [RFC4379] and extended in [RFC7307] for topology-scoped FECs. + +13.2. Traffic Capacity on Backup Paths + + During a fast-reroute event initiated by a PLR in response to a + network failure, the flow of traffic in the network will generally + not be identical to the flow of traffic after the IGP forwarding + state has converged, taking the failure into account. Therefore, + even if a network has been engineered to have enough capacity on the + appropriate links to carry all traffic after the IGP has converged + after the failure, the network may still not have enough capacity on + the appropriate links to carry the flow of traffic during a fast- + reroute event. This can result in more traffic loss during the fast- + reroute event than might otherwise be expected. + + Note that there are two somewhat distinct aspects to this phenomenon. + The first is that the path from the PLR to the destination during the + fast-reroute event may be different from the path after the IGP + converges. In this case, any traffic for the destination that + reaches the PLR during the fast-reroute event will follow a different + path from the PLR to the destination than will be followed after IGP + convergence. + + The second aspect is that the amount of traffic arriving at the PLR + for affected destinations during the fast-reroute event may be larger + than the amount of traffic arriving at the PLR for affected + destinations after IGP convergence. Immediately after a failure, any + non-PLR routers that were sending traffic to the PLR before the + failure will continue sending traffic to the PLR, and that traffic + will be carried over backup paths from the PLR to the destinations. + + + +Atlas, et al. Standards Track [Page 34] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + After IGP convergence, upstream non-PLR routers may direct some + traffic away from the PLR. + + In order to reduce or eliminate the potential for transient traffic + loss due to inadequate capacity during fast-reroute events, an + operator can model the amount of traffic taking different paths + during a fast-reroute event. If it is determined that there is not + enough capacity to support a given fast-reroute event, the operator + can address the issue either by augmenting capacity on certain links + or modifying the backup paths themselves. + + The MRT Lowpoint algorithm produces a pair of diverse paths to each + destination. These paths are generated by following the directed + links on a common GADAG. The decision process for constructing the + GADAG in the MRT Lowpoint algorithm takes into account individual IGP + link metrics. At any given node, links are explored in order from + lowest IGP metric to highest IGP metric. Additionally, the process + for constructing the MRT-Red and Blue trees uses SPF traversals of + the GADAG. Therefore, the IGP link metric values affect the computed + backup paths. However, adjusting the IGP link metrics is not a + generally applicable tool for modifying the MRT backup paths. + Achieving a desired set of MRT backup paths by adjusting IGP metrics + while at the same time maintaining the desired flow of traffic along + the shortest paths is not possible in general. + + MRT-FRR allows an operator to exclude a link from the MRT Island, and + thus the GADAG, by advertising it as MRT-Ineligible. Such a link + will not be used on the MRT forwarding path for any destination. + Advertising links as MRT-Ineligible is the main tool provided by MRT- + FRR for keeping backup traffic off of lower bandwidth links during + fast-reroute events. + + Note that all of the backup paths produced by the MRT Lowpoint + algorithm are closely tied to the common GADAG computed as part of + that algorithm. Therefore, it is generally not possible to modify a + subset of paths without affecting other paths. This precludes more + fine-grained modification of individual backup paths when using only + paths computed by the MRT Lowpoint algorithm. + + However, it may be desirable to allow an operator to use MRT-FRR + alternates together with alternates provided by other FRR + technologies. A policy-based alternate selection process can allow + an operator to select the best alternate from those provided by MRT + and other FRR technologies. As a concrete example, it may be + desirable to implement a policy where a downstream LFA (if it exists + for a given failure mode and destination) is preferred over a given + MRT alternate. This combination gives the operator the ability to + affect where traffic flows during a fast-reroute event, while still + + + +Atlas, et al. Standards Track [Page 35] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + producing backup paths that use no additional labels for LDP traffic + and will not loop under multiple failures. This and other choices of + alternate selection policy can be evaluated in the context of their + effect on fast-reroute traffic flow and available capacity, as well + as other deployment considerations. + + Note that future documents may define MRT profiles in addition to the + default profile defined here. Different MRT profiles will generally + produce alternate paths with different properties. An implementation + may allow an operator to use different MRT profiles instead of or in + addition to the default profile. + +13.3. MRT IP Tunnel Loopback Address Management + + As described in Section 6.1.2, if an implementation uses IP tunneling + as the mechanism to realize MRT forwarding paths, each node must + advertise an MRT-Red and an MRT-Blue loopback address. These IP + addresses must be unique within the routing domain to the extent that + they do not overlap with each other or with any other routing table + entries. It is expected that operators will use existing tools and + processes for managing infrastructure IP addresses to manage these + additional MRT-related loopback addresses. + +13.4. MRT-FRR in a Network with Degraded Connectivity + + Ideally, routers in a service provider network using MRT-FRR will be + initially deployed in a 2-connected topology, allowing MRT-FRR to + find completely diverse paths to all destinations. However, a + network can differ from an ideal 2-connected topology for many + possible reasons, including network failures and planned maintenance + events. + + MRT-FRR is designed to continue to function properly when network + connectivity is degraded. When a network contains cut-vertices or + cut-links dividing the network into different 2-connected blocks, + MRT-FRR will continue to provide completely diverse paths for + destinations within the same block as the PLR. For a destination in + a different block from the PLR, the redundant paths created by MRT- + FRR will be link and node diverse within each block, and the paths + will only share links and nodes that are cut-links or cut-vertices in + the topology. + + If a network becomes partitioned with one set of routers having no + connectivity to another set of routers, MRT-FRR will function + independently in each set of connected routers, providing redundant + paths to destinations in same set of connected routers as a given + PLR. + + + + +Atlas, et al. Standards Track [Page 36] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +13.5. Partial Deployment of MRT-FRR in a Network + + A network operator may choose to deploy MRT-FRR only on a subset of + routers in an IGP area. MRT-FRR is designed to accommodate this + partial deployment scenario. Only routers that advertise support for + a given MRT profile will be included in a given MRT Island. For a + PLR within the MRT Island, MRT-FRR will create redundant forwarding + paths to all destinations with the MRT Island using maximally + redundant trees all the way to those destinations. For destinations + outside of the MRT Island, MRT-FRR creates paths to the destination + that use forwarding state created by MRT-FRR within the MRT Island + and shortest path forwarding state outside of the MRT Island. The + paths created by MRT-FRR to non-Island destinations are guaranteed to + be diverse within the MRT Island (if topologically possible). + However, the part of the paths outside of the MRT Island may not be + diverse. + +14. IANA Considerations + + IANA has created the "MRT Profile Identifier Registry". The range is + 0 to 255. The Default MRT Profile defined in this document has value + 0. Values 1-200 are allocated by Standards Action. Values 201-220 + are for Experimental Use. Values 221-254 are for Private Use. Value + 255 is reserved for future registry extension. (The allocation and + use policies are described in [RFC5226].) + + The initial registry is shown below. + + Value Description Reference + ------- ---------------------------------------- ------------ + 0 Default MRT Profile RFC 7812 + 1-200 Unassigned + 201-220 Experimental Use + 221-254 Private Use + 255 Reserved (for future registry extension) + + The "MRT Profile Identifier Registry" is a new registry in the IANA + Matrix. Following existing conventions, http://www.iana.org/ + protocols displays a new header: "Maximally Redundant Tree (MRT) + Parameters". Under that header, there is an entry for "MRT Profile + Identifier Registry", which links to the registry itself at + http://www.iana.org/assignments/mrt-parameters. + + + + + + + + + +Atlas, et al. Standards Track [Page 37] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +15. Security Considerations + + In general, MRT forwarding paths do not follow shortest paths. The + transit forwarding state corresponding to the MRT paths is created + during normal operations (before a failure occurs). Therefore, a + malicious packet with an appropriate header injected into the network + from a compromised location would be forwarded to a destination along + a non-shortest path. When this technology is deployed, a network + security design should not rely on assumptions about potentially + malicious traffic only following shortest paths. + + It should be noted that the creation of non-shortest forwarding paths + is not unique to MRT. + + MRT-FRR requires that routers advertise information used in the + formation of MRT backup paths. While this document does not specify + the protocol extensions used to advertise this information, we + discuss security considerations related to the information itself. + Injecting false MRT-related information could be used to direct some + MRT backup paths over compromised transmission links. Combined with + the ability to generate network failures, this could be used to send + traffic over compromised transmission links during a fast-reroute + event. In order to prevent this potential exploit, a receiving + router needs to be able to authenticate MRT-related information that + claims to have been advertised by another router. + +16. References + +16.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. + King, "LDP Extensions for Multi-Topology", RFC 7307, + DOI 10.17487/RFC7307, July 2014, + <http://www.rfc-editor.org/info/rfc7307>. + + + + + + + +Atlas, et al. Standards Track [Page 38] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + [RFC7811] Enyedi, G., Ed., Csaszar, A., Atlas, A., Ed., Bowers, C., + and A. Gopalan, "An Algorithm for Computing IP/LDP Fast + Reroute Using Maximally Redundant Trees (MRT-FRR)", + RFC 7811, DOI 10.17487/RFC7811, June 2016, + <http://www.rfc-editor.org/info/rfc7811>. + +16.2. Informative References + + [EnyediThesis] + Enyedi, G., "Novel Algorithms for IP Fast Reroute", + Department of Telecommunications and Media Informatics, + Budapest University of Technology and Economics Ph.D. + Thesis, February 2011, + <https://repozitorium.omikk.bme.hu/bitstream/ + handle/10890/1040/ertekezes.pdf>. + + [LDP-MRT] Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and + IJ. Wijnands, "LDP Extensions to Support Maximally + Redundant Trees", Work in Progress, draft-ietf-mpls-ldp- + mrt-03, May 2016. + + [MRT-ARCH] + Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G. + Enyedi, "An Architecture for Multicast Protection Using + Maximally Redundant Trees", Work in Progress, draft-atlas- + rtgwg-mrt-mc-arch-02, July 2013. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + DOI 10.17487/RFC2328, April 1998, + <http://www.rfc-editor.org/info/rfc2328>. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + DOI 10.17487/RFC4379, February 2006, + <http://www.rfc-editor.org/info/rfc4379>. + + [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for + IP Fast Reroute: Loop-Free Alternates", RFC 5286, + DOI 10.17487/RFC5286, September 2008, + <http://www.rfc-editor.org/info/rfc5286>. + + [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", + RFC 5331, DOI 10.17487/RFC5331, August 2008, + <http://www.rfc-editor.org/info/rfc5331>. + + + + + + +Atlas, et al. Standards Track [Page 39] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, + <http://www.rfc-editor.org/info/rfc5340>. + + [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP + Synchronization", RFC 5443, DOI 10.17487/RFC5443, March + 2009, <http://www.rfc-editor.org/info/rfc5443>. + + [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", + RFC 5714, DOI 10.17487/RFC5714, January 2010, + <http://www.rfc-editor.org/info/rfc5714>. + + [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free + Convergence", RFC 5715, DOI 10.17487/RFC5715, January + 2010, <http://www.rfc-editor.org/info/rfc5715>. + + [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, DOI 10.17487/RFC6976, July + 2013, <http://www.rfc-editor.org/info/rfc6976>. + + [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP + and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, + DOI 10.17487/RFC6981, August 2013, + <http://www.rfc-editor.org/info/rfc6981>. + + [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. + McPherson, "OSPF Stub Router Advertisement", RFC 6987, + DOI 10.17487/RFC6987, September 2013, + <http://www.rfc-editor.org/info/rfc6987>. + + [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. + So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", + RFC 7490, DOI 10.17487/RFC7490, April 2015, + <http://www.rfc-editor.org/info/rfc7490>. + + + + + + + + + + + + + + + +Atlas, et al. Standards Track [Page 40] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +Appendix A. Inter-level Forwarding Behavior for IS-IS + + In the description below, we use the terms "Level-1-only interface", + "Level-2-only interface", and "Level-1-and-Level-2 interface" to mean + an interface that has formed only a Level-1 adjacency, only a Level-2 + adjacency, or both Level-1 and Level-2 adjacencies. Note that IS-IS + also defines the concept of areas. A router is configured with an + IS-IS area identifier, and a given router may be configured with + multiple IS-IS area identifiers. For an IS-IS Level-1 adjacency to + form between two routers, at least one IS-IS area identifier must + match. IS-IS Level-2 adjacencies do not require any area identifiers + to match. The behavior described below does not explicitly refer to + IS-IS area identifiers. However, IS-IS area identifiers will + indirectly affect the behavior by affecting the formation of Level-1 + adjacencies. + + First, consider a packet destined to Z on MRT-Red or MRT-Blue + received on a Level-1-only interface. If the best shortest path + route to Z was learned from a Level-1 advertisement, then the packet + should continue to be forwarded along MRT-Red or MRT-Blue. If, + instead, the best route was learned from a Level-2 advertisement, + then the packet should be removed from MRT-Red or MRT-Blue and + forwarded on the shortest-path default forwarding topology. + + Now consider a packet destined to Z on MRT-Red or MRT-Blue received + on a Level-2-only interface. If the best route to Z was learned from + a Level-2 advertisement, then the packet should continue to be + forwarded along MRT-Red or MRT-Blue. If, instead, the best route was + learned from a Level-1 advertisement, then the packet should be + removed from MRT-Red or MRT-Blue and forwarded on the shortest-path + default forwarding topology. + + Finally, consider a packet destined to Z on MRT-Red or MRT-Blue + received on a Level-1-and-Level-2 interface. This packet should + continue to be forwarded along MRT-Red or MRT-Blue, regardless of + which level the route was learned from. + + An implementation may simplify the decision-making process above by + using the interface of the next hop for the route to Z to determine + the level from which the best route to Z was learned. If the next + hop points out a Level-1-only interface, then the route was learned + from a Level-1 advertisement. If the next hop points out a Level- + 2-only interface, then the route was learned from a Level-2 + advertisement. A next hop that points out a Level-1-and-Level-2 + interface does not provide enough information to determine the source + of the best route. With this simplification, an implementation would + need to continue forwarding along MRT-Red or MRT-Blue when the next- + hop points out a Level-1-and-Level-2 interface. Therefore, a packet + + + +Atlas, et al. Standards Track [Page 41] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + + on MRT-Red or MRT-Blue going from Level-1 to Level-2 (or vice versa) + that traverses a Level-1-and-Level-2 interface in the process will + remain on MRT-Red or MRT-Blue. This simplification may not always + produce the optimal forwarding behavior, but it does not introduce + interoperability problems. The packet will stay on an MRT backup + path longer than necessary, but it will still reach its destination. + +Appendix B. General Issues with Area Abstraction + + When a multihomed prefix is connected in two different areas, it may + be impractical to protect them without adding the complexity of + explicit tunneling. This is also a problem for LFA and Remote-LFA. + + 50 + |----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0: + | | ABR 1, ABR 2, C, D + | | + | | Area 20: A, ASBR X + | | + p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y + 5 p is a Type 1 AS-external + + + Figure 4: AS External Prefixes in Different Areas + + Consider the network in Figure 4 and assume there is a richer + connective topology that isn't shown, where the same prefix is + announced by ASBR X and ASBR Y, which are in different non-backbone + areas. If the link from A to ASBR X fails, then an MRT alternate + could forward the packet to ABR 1 and ABR 1 could forward it to D, + but then D would find the shortest route is back via ABR 1 to Area + 20. This problem occurs because the routers, including the ABR, in + one area are not yet aware of the failure in a different area. + + The only way to get it from A to ASBR Y is to explicitly tunnel it to + ASBR Y. If the traffic is unlabeled or the appropriate MPLS labels + are known, then explicit tunneling MAY be used as long as the + shortest path of the tunnel avoids the failure point. In that case, + A must determine that it should use an explicit tunnel instead of an + MRT alternate. + + + + + + + + + + + +Atlas, et al. Standards Track [Page 42] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +Acknowledgements + + The authors would like to thank Mike Shand for his valuable review + and contributions. + + The authors would like to thank Joel Halpern, Hannes Gredler, Ted + Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin + Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, Bruno + Decraene, Eric Wu, Janos Farkas, Rob Shakir, Stewart Bryant, and + Alvaro Retana for their suggestions and review. + +Contributors + + Robert Kebler + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886 + United States + Email: rkebler@juniper.net + + Andras Csaszar + Ericsson + Konyves Kalman krt 11 + Budapest 1097 + Hungary + Email: Andras.Csaszar@ericsson.com + + Jeff Tantsura + Ericsson + 300 Holger Way + San Jose, CA 95134 + United States + Email: jeff.tantsura@ericsson.com + + Russ White + VCE + Email: russw@riw.us + + + + + + + + + + + + + + +Atlas, et al. Standards Track [Page 43] + +RFC 7812 MRT Unicast FRR Architecture June 2016 + + +Authors' Addresses + + Alia Atlas + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886 + United States + + Email: akatlas@juniper.net + + + Chris Bowers + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + United States + + Email: cbowers@juniper.net + + + Gabor Sandor Enyedi + Ericsson + Konyves Kalman krt 11. + Budapest 1097 + Hungary + + Email: Gabor.Sandor.Enyedi@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + +Atlas, et al. Standards Track [Page 44] + |