idnits 2.17.1 draft-ietf-rtgwg-mrt-frr-architecture-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2016) is 3022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'R' is mentioned on line 514, but not defined == Missing Reference: 'F' is mentioned on line 514, but not defined == Missing Reference: 'C' is mentioned on line 514, but not defined == Missing Reference: 'I' is mentioned on line 512, but not defined == Missing Reference: 'G' is mentioned on line 514, but not defined == Missing Reference: 'J' is mentioned on line 516, but not defined == Missing Reference: 'A' is mentioned on line 1301, but not defined == Missing Reference: 'ABR1' is mentioned on line 1311, but not defined == Missing Reference: 'H' is mentioned on line 1311, but not defined == Unused Reference: 'I-D.ietf-rtgwg-lfa-manageability' is defined on line 2004, but no explicit reference was found in the text == Unused Reference: 'LightweightNotVia' is defined on line 2016, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-06 == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-00 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-rlfa-node-protection-05 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group A. Atlas 3 Internet-Draft C. Bowers 4 Intended status: Standards Track Juniper Networks 5 Expires: July 13, 2016 G. Enyedi 6 Ericsson 7 January 10, 2016 9 An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees 10 draft-ietf-rtgwg-mrt-frr-architecture-09 12 Abstract 14 This document defines the architecture for IP/LDP Fast-Reroute using 15 Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that 16 gives link-protection and node-protection with 100% coverage in any 17 network topology that is still connected after the failure. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 13, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Importance of 100% Coverage . . . . . . . . . . . . . . . 8 55 1.2. Partial Deployment and Backwards Compatibility . . . . . 9 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 9 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 11 59 5. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . 12 60 6. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . 13 61 6.1. MRT Forwarding Mechanisms . . . . . . . . . . . . . . . . 14 62 6.1.1. MRT LDP labels . . . . . . . . . . . . . . . . . . . 14 63 6.1.1.1. Topology-scoped FEC encoded using a single label 64 (Option 1A) . . . . . . . . . . . . . . . . . . . 14 65 6.1.1.2. Topology and FEC encoded using a two label stack 66 (Option 1B) . . . . . . . . . . . . . . . . . . . 15 67 6.1.1.3. Compatibility of Option 1A and 1B . . . . . . . . 15 68 6.1.1.4. Mandatory support for MRT LDP Label option 1A . . 15 69 6.1.2. MRT IP tunnels (Options 2A and 2B) . . . . . . . . . 16 70 6.2. Forwarding LDP Unicast Traffic over MRT Paths . . . . . . 16 71 6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option 72 1A) . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 6.2.2. Forwarding LDP traffic using MRT LDP Labels (Option 74 1B) . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.2.3. Other considerations for forwarding LDP traffic using 76 MRT LDP Labels . . . . . . . . . . . . . . . . . . . 17 77 6.3. Forwarding IP Unicast Traffic over MRT Paths . . . . . . 18 78 6.3.1. Tunneling IP traffic using MRT LDP Labels . . . . . . 18 79 6.3.1.1. Tunneling IP traffic using MRT LDP Labels (Option 80 1A) . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option 82 1B) . . . . . . . . . . . . . . . . . . . . . . . 19 83 6.3.2. Tunneling IP traffic using MRT IP Tunnels . . . . . . 19 84 6.3.3. Required support . . . . . . . . . . . . . . . . . . 19 85 7. MRT Island Formation . . . . . . . . . . . . . . . . . . . . 19 86 7.1. IGP Area or Level . . . . . . . . . . . . . . . . . . . . 20 87 7.2. Support for a specific MRT profile . . . . . . . . . . . 20 88 7.3. Excluding additional routers and interfaces from the MRT 89 Island . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 7.3.1. Existing IGP exclusion mechanisms . . . . . . . . . . 21 91 7.3.2. MRT-specific exclusion mechanism . . . . . . . . . . 22 92 7.4. Connectivity . . . . . . . . . . . . . . . . . . . . . . 22 93 7.5. Algorithm for MRT Island Identification . . . . . . . . . 22 94 8. MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 8.1. MRT Profile Options . . . . . . . . . . . . . . . . . . . 22 96 8.2. Router-specific MRT paramaters . . . . . . . . . . . . . 24 97 8.3. Default MRT profile . . . . . . . . . . . . . . . . . . . 24 98 9. LDP signaling extensions and considerations . . . . . . . . . 25 99 10. Inter-area Forwarding Behavior . . . . . . . . . . . . . . . 25 100 10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A . . 26 101 10.1.1. Motivation for Creating the Rainbow-FEC . . . . . . 27 102 10.2. ABR Forwarding Behavior with IP Tunneling (option 2) . . 27 103 10.3. ABR Forwarding Behavior with LDP Label option 1B . . . . 28 104 11. Prefixes Multiply Attached to the MRT Island . . . . . . . . 29 105 11.1. Protecting Multi-Homed Prefixes using Tunnel Endpoint 106 Selection . . . . . . . . . . . . . . . . . . . . . . . 31 107 11.2. Protecting Multi-Homed Prefixes using Named Proxy-Nodes 32 108 11.3. MRT Alternates for Destinations Outside the MRT Island . 34 109 12. Network Convergence and Preparing for the Next Failure . . . 34 110 12.1. Micro-loop prevention and MRTs . . . . . . . . . . . . . 35 111 12.2. MRT Recalculation for the Default MRT Profile . . . . . 36 112 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 113 14. Operational Considerations . . . . . . . . . . . . . . . . . 38 114 14.1. Verifying Forwarding on MRT Paths . . . . . . . . . . . 38 115 14.2. Traffic Capacity on Backup Paths . . . . . . . . . . . . 39 116 14.3. MRT IP Tunnel Loopback Address Management . . . . . . . 40 117 14.4. MRT-FRR in a Network with Degraded Connectivity . . . . 41 118 14.5. Partial Deployment of MRT-FRR in a Network . . . . . . . 41 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 120 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 121 17. Security Considerations . . . . . . . . . . . . . . . . . . . 42 122 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 123 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 124 19.1. Normative References . . . . . . . . . . . . . . . . . . 43 125 19.2. Informative References . . . . . . . . . . . . . . . . . 44 126 Appendix A. General Issues with Area Abstraction . . . . . . . . 46 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 129 1. Introduction 131 This document describes a solution for IP/LDP fast-reroute [RFC5714]. 132 MRT-FRR creates two alternate trees separate from the primary next- 133 hop forwarding used during stable operation. These two trees are 134 maximally diverse from each other, providing link and node protection 135 for 100% of paths and failures as long as the failure does not cut 136 the network into multiple pieces. This document defines the 137 architecture for IP/LDP fast-reroute with MRT. 139 [I-D.ietf-rtgwg-mrt-frr-algorithm] describes how to compute maximally 140 redundant trees using a specific algorithm, the MRT Lowpoint 141 algorithm. The MRT Lowpoint algorithm is used by a router that 142 supports the Default MRT Profile, as specified in this document. 144 IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse 145 forwarding topologies to provide alternates. A primary next-hop 146 should be on only one of the diverse forwarding topologies; thus, the 147 other can be used to provide an alternate. Once traffic has been 148 moved to one of the MRTs by one point of local repair (PLR), that 149 traffic is not subject to further repair actions by another PLR, even 150 in the event of multiple simultaneous failures. Therefore, traffic 151 repaired by MRT-FRR will not loop between different PLRs responding 152 to different simultaneous failures. 154 While MRT provides 100% protection for a single link or node failure, 155 it may not protect traffic in the event of multiple simultaneous 156 failures, nor does take into account Shared Risk Link Groups (SRLGs). 157 Also, while the MRT Lowpoint algorithm is computationally efficient, 158 it is also new. In order for MRT-FRR to function properly, all of 159 the other nodes in the network that support MRT must correctly 160 compute next-hops based on the same algorithm, and install the 161 corresponding forwarding state. This is in contrast to other FRR 162 methods where the calculation of backup paths generally involves 163 repeated application of the simpler and widely-deployed SPF 164 algorithm, and backup paths themselves re-use the forwarding state 165 used for shortest path forwarding of normal traffic. Section 14 166 provides operational guidance related to verification of MRT 167 forwarding paths. 169 In addition to supporting IP and LDP unicast fast-reroute, the 170 diverse forwarding topologies and guarantee of 100% coverage permit 171 fast-reroute technology to be applied to multicast traffic as 172 described in [I-D.atlas-rtgwg-mrt-mc-arch]. However, the current 173 document does not address the multicast applications of MRTs. 175 Figure 1 compares different methods of providing FRR for IP and LDP 176 traffic, illustrating some of the trade-offs between the different 177 approaches. For several methods, the methods are separated into 178 link-protecting (LP) and node-protecting (NP) variants. The first 179 column indicates whether the method provides 100% protection coverage 180 (when topologically feasible). The second column indicates whether 181 or not traffic traversing alternate path can loop when multiple 182 failures occur. 184 The third column gives an estimate of the amount of computation 185 required at each node to support the FRR method, in addition to the 186 usual SPF computation rooted at the computing node itself. This 187 metric of comparison is important for implementations that seek to 188 quickly recompute repair paths following their initial use after a 189 topology change, without reliance on an external system, in order to 190 minimize the risk of a new failure occurring before the new repair 191 paths are in place. 193 The fourth column indicates the maximum number of additional labels 194 that need to be applied to packets to support the FRR method, while 195 the fifth column gives the size of the MPLS label table needed to 196 support the FRR method. These two metrics may be useful for 197 evaluating requirements placed on hardware to support the different 198 FRR methods. 200 The last column indicates the additional requirements placed on the 201 control plane by the FRR method, beyond what is required for IGP 202 shortest path forwarding with LDP. 204 +---------+-----+------+-------------+-------+-------------+----------+ 205 | Method |100% | Alt. | Additional | Max. | Label table | Control | 206 | |prot.| can | computation | addit.| size | plane | 207 | |cov. | loop?| at each | labels|(relative to | reqs. | 208 | | | | node | | SPF labels) | | 209 +---------+-----+------+-------------+-------+-------------+----------+ 210 | MRT-FRR | Yes | No | equivalent | 0(LDP)| 3x | MRT- | 211 | LP and | | | of less | 1(IP) | | specific | 212 | NP | | | than | | | protocol | 213 | | | | 3 SPFs | | | extens. | 214 +---------+-----+------+-------------+-------+-------------+----------+ 215 | LFA LP | No | Yes | SPF per | 0 | 1x | None | 216 | and NP | | | neighbor | | | | 217 +---------+-----+------+-------------+-------+-------------+----------+ 218 | Remote | No | Yes | SPF per | 1 | 1x | T-LDP | 219 | LFA LP | | | neighbor | | | session | 220 | | | | | | | for each | 221 | | | | | | | selected | 222 | | | | | | | PQ node | 223 +---------+-----+------+-------------+-------+-------------+----------+ 224 | Remote | No | Yes | SPF per nbr | 1 | 1x | T-LDP | 225 | LFA NP | | | and SPF per | | | session | 226 | | | | per PQ node | | | for each | 227 | | | | evaluated | | | selected | 228 | | | | | | | PQ node | 229 +---------+-----+------+-------------+-------+-------------+----------+ 230 | Not-Via | Yes | No | SPF per | 1 | (average | T-LDP | 231 | LP and | | | link and | | number of | session | 232 | NP | | | per node | | neighbors) | for each | 233 | | | | in topology | | x | nbr's nbr| 234 +---------+-----+------+-------------+-------+-------------+----------+ 235 | TI-LFA | Yes | Yes | SPF per | 2 | 1x | uses | 236 | LP with | | | neighbor | | | SPRING | 237 | symm. | | | | | | for | 238 | metrics | | | | | | label | 239 | | | | | | | dist. | 240 +---------+-----+------+-------------+-------+-------------+----------+ 241 | TI-LFA | Yes | Yes | # of SPFs |depth | 1x | uses | 242 | NP or | | | dependent |depend-| | SPRING | 243 | LP with | | | on topology |ent on | | for | 244 | asymm. | | | |topo. | | label | 245 | metrics | | | | | | dist. | 246 +---------+-----+------+-------------+-------+-------------+----------+ 248 Figure 1: Comparison of IP/LDP FRR Methods 250 MRT: MRT provides 100% coverage for link and node protection, and 251 traffic on the alternate paths will not loop. The computation 252 required on each node is equivalent to less than 3 additional SPFs 253 in terms of computational complexity. For IP traffic, MRT 254 requires one additional label, while for LDP traffic, no 255 additional labels are needed. However, the size of the MPLS label 256 table is three times what would normally be required for shortest 257 path LDP forwarding, due to the presence of additional red and 258 blue labels for each FEC. MRT requires protocol extensions in 259 order to allow a node to advertise support for MRT as well as a 260 value for the GADAG Root Selection Priority. It also requires 261 support for multi-topology LDP extensions. 263 Loop-Free Alternates (LFA): LFAs [RFC5286] provide limited 264 topology-dependent coverage for link and node protection. 265 Restrictions on choice of alternates can be relaxed to improve 266 coverage, but this can cause forwarding loops if a worse failure 267 is experienced than protected against. [RFC6571] discusses the 268 applicability of LFA to different topologies with a focus on 269 common PoP architectures. The computation required is one SPF per 270 neighbor. LFA imposes no additional labels imposed, has no impact 271 on the label table size, and has no additional control plane 272 requirements. 274 Remote LFA: Remote LFA [RFC7490] improves coverage over LFA for 275 both link and node protection, but it does not guarantee 100% 276 coverage. The alternates can also loop with worse than expected 277 failures. Computation for link protection is one SPF per 278 neighbor, while computation for node protection requires an 279 additional SPF per PQ node [I-D.ietf-rtgwg-rlfa-node-protection]. 280 Remote LFA can impose up to one additional label on the packet, 281 but does not increase the size of the label table. It requires a 282 T-LDP session for each selected PQ node. 284 Not-Via: Not-Via [RFC6981] provides 100% coverage for link and node 285 failures and does not have potential looping among alternates. 286 The computation is high with an SPF per potential failure point 287 (all links and nodes in the topology). When implemented with LDP, 288 Not-Via adds one additional label to a tunnelled packet. It 289 significantly increases the size of the label table, multiplying 290 it by roughly the average number of neighbors. Not-Via also 291 requires targeted LDP sessions to each neighbor's neighbor. 293 TI-LFA: Topology Independent Loop-free Alternate Fast Re-route (TI- 294 LFA) [I-D.francois-rtgwg-segment-routing-ti-lfa] aims to provide 295 link and node protection of node and adjacency segments within the 296 Segment Routing (SR) framework. It guarantees complete coverage. 297 The TI-LFA computation for link-protection is fairly 298 straightforward, while the computation for node-protection is more 299 complex. For link-protection with symmetric link costs, TI-LFA 300 can provide complete coverage by pushing up to two additional 301 labels. For node protection on arbitrary topologies, the label 302 stack size can grow significantly based on repair path. Note that 303 TI-LFA requires shortest path forwarding based on SR Node-SIDs, as 304 opposed to LDP labels, in order to construct label stacks for 305 backups paths without relying on a large number of targeted LDP 306 sessions to learn remote FEC-label bindings. It also requires the 307 use of Adj-SIDs to achieve 100% coverage. 309 1.1. Importance of 100% Coverage 311 Fast-reroute is based upon the single failure assumption - that the 312 time between single failures is long enough for a network to 313 reconverge and start forwarding on the new shortest paths. That does 314 not imply that the network will only experience one failure or 315 change. 317 It is straightforward to analyze a particular network topology for 318 coverage. However, a real network does not always have the same 319 topology. For instance, maintenance events will take links or nodes 320 out of use. Simply costing out a link can have a significant effect 321 on what LFAs are available. Similarly, after a single failure has 322 happened, the topology is changed and its associated coverage. 323 Finally, many networks have new routers or links added and removed; 324 each of those changes can have an effect on the coverage for 325 topology-sensitive methods such as LFA and Remote LFA. If fast- 326 reroute is important for the network services provided, then a method 327 that guarantees 100% coverage is important to accomodate natural 328 network topology changes. 330 Asymmetric link costs are also a common aspect of networks. There 331 are at least three common causes for them. First, any broadcast 332 interface is represented by a pseudo-node and has asymmetric link 333 costs to and from that pseudo-node. Second, when routers come up or 334 a link with LDP comes up, it is recommended in [RFC5443] and 335 [RFC6987] that the link metric be raised to the maximum cost; this 336 may not be symmetric and for [RFC6987] is not expected to be. Third, 337 techniques such as IGP metric tuning for traffic-engineering can 338 result in asymmetric link costs. A fast-reroute solution needs to 339 handle network topologies with asymmetric link costs. 341 When a network needs to use a micro-loop prevention mechanism 342 [RFC5715] such as Ordered FIB[RFC6976] or Nearside 343 Tunneling[RFC5715], then the whole IGP area needs to have alternates 344 available so that the micro-loop prevention mechanism, which requires 345 slower network convergence, can take the necessary time without 346 adversely impacting traffic. Without complete coverage, traffic to 347 the unprotected destinations will be dropped for significantly longer 348 than with current convergence - where routers individually converge 349 as fast as possible. See Section 12.1 for more discussion of micro- 350 loop prevention and MRTs. 352 1.2. Partial Deployment and Backwards Compatibility 354 MRT-FRR supports partial deployment. Routers advertise their ability 355 to support MRT. Inside the MRT-capable connected group of routers 356 (referred to as an MRT Island), the MRTs are computed. Alternates to 357 destinations outside the MRT Island are computed and depend upon the 358 existence of a loop-free neighbor of the MRT Island for that 359 destination. MRT Islands are discussed in detail in Section 7, and 360 partial deployment is discussed in more detail in Section 14.5. 362 2. Requirements Language 364 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 365 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 366 document are to be interpreted as described in [RFC2119]. 368 3. Terminology 370 network graph: A graph that reflects the network topology where all 371 links connect exactly two nodes and broadcast links have been 372 transformed into the standard pseudo-node representation. 374 cut-link: A link whose removal partitions the network. A cut-link 375 by definition must be connected between two cut-vertices. If 376 there are multiple parallel links, then they are referred to as 377 cut-links in this document if removing the set of parallel links 378 would partition the network graph. 380 cut-vertex: A vertex whose removal partitions the network graph. 382 2-connected: A graph that has no cut-vertices. This is a graph 383 that requires two nodes to be removed before the network is 384 partitioned. 386 2-connected cluster: A maximal set of nodes that are 2-connected. 388 block: Either a 2-connected cluster, a cut-edge, or an isolated 389 vertex. 391 Redundant Trees (RT): A pair of trees where the path from any node 392 X to the root R along the first tree is node-disjoint with the 393 path from the same node X to the root along the second tree. 394 Redundant trees can always be computed in 2-connected graphs. 396 Maximally Redundant Trees (MRT): A pair of trees where the path 397 from any node X to the root R along the first tree and the path 398 from the same node X to the root along the second tree share the 399 minimum number of nodes and the minimum number of links. Each 400 such shared node is a cut-vertex. Any shared links are cut-links. 401 In graphs that are not 2-connected, it is not possible to compute 402 RTs. However, it is possible to compute MRTs. MRTs are maximally 403 redundant in the sense that they are as redundant as possible 404 given the constraints of the network graph. 406 DAG: Directed Acyclic Graph - a graph where all links are directed 407 and there are no cycles in it. 409 ADAG: Almost Directed Acyclic Graph - a graph that, if all links 410 incoming to the root were removed, would be a DAG. 412 GADAG: Generalized ADAG - a graph that is the combination of the 413 ADAGs of all blocks. 415 MRT-Red: MRT-Red is used to describe one of the two MRTs; it is 416 used to describe the associated forwarding topology and MPLS 417 multi-topology identifier (MT-ID). Specifically, MRT-Red is the 418 decreasing MRT where links in the GADAG are taken in the direction 419 from a higher topologically ordered node to a lower one. 421 MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 422 used to described the associated forwarding topology and MPLS MT- 423 ID. Specifically, MRT-Blue is the increasing MRT where links in 424 the GADAG are taken in the direction from a lower topologically 425 ordered node to a higher one. 427 Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the 428 multiple MRT forwarding topologies and to the default forwarding 429 topology. This is referred to as the Rainbow MRT MPLS MT-ID and 430 is used by LDP to reduce signaling and permit the same label to 431 always be advertised to all peers for the same (MT-ID, Prefix). 433 MRT Island: The set of routers that support a particular MRT 434 profile and the links connecting them that support MRT. 436 Island Border Router (IBR): A router in the MRT Island that is 437 connected to a router not in the MRT Island and both routers are 438 in a common area or level. 440 Island Neighbor (IN): A router that is not in the MRT Island but is 441 adjacent to an IBR and in the same area/level as the IBR. 443 named proxy-node: A proxy-node can represent a destination prefix 444 that can be attached to the MRT Island via at least two routers. 445 It is named if there is a way that traffic can be encapsulated to 446 reach specifically that proxy node; this could be because there is 447 an LDP FEC for the associated prefix or because MRT-Red and MRT- 448 Blue IP addresses are advertised in an undefined fashion for that 449 proxy-node. 451 4. Maximally Redundant Trees (MRT) 453 A pair of Maximally Redundant Trees is a pair of directed spanning 454 trees that provides maximally disjoint paths towards their common 455 root. Only links or nodes whose failure would partition the network 456 (i.e. cut-links and cut-vertices) are shared between the trees. The 457 MRT Lowpoint algorithm is given in 458 [I-D.ietf-rtgwg-mrt-frr-algorithm]. This algorithm can be computed 459 in O(e + n log n); it is less than three SPFs. This document 460 describes how the MRTs can be used and not how to compute them. 462 MRT provides destination-based trees for each destination. Each 463 router stores its normal primary next-hop(s) as well as MRT-Blue 464 next-hop(s) and MRT-Red next-hop(s) toward each destination. The 465 alternate will be selected between the MRT-Blue and MRT-Red. 467 The most important thing to understand about MRTs is that for each 468 pair of destination-routed MRTs, there is a path from every node X to 469 the destination D on the Blue MRT that is as disjoint as possible 470 from the path on the Red MRT. 472 For example, in Figure 2, there is a network graph that is 473 2-connected in (a) and associated MRTs in (b) and (c). One can 474 consider the paths from B to R; on the Blue MRT, the paths are 475 B->F->D->E->R or B->C->D->E->R. On the Red MRT, the path is B->A->R. 476 These are clearly link and node-disjoint. These MRTs are redundant 477 trees because the paths are disjoint. 479 [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| 480 | | | | ^ | | | 481 | | | V | | V V 482 [R] [F] [C] [R] [F] [C] [R] [F] [C] 483 | | | ^ ^ ^ | | 484 | | | | | | V | 485 [A]---[B]---| [A]-->[B]---| [A]<--[B]<--| 487 (a) (b) (c) 488 a 2-connected graph Blue MRT towards R Red MRT towards R 490 Figure 2: A 2-connected Network 492 By contrast, in Figure 3, the network in (a) is not 2-connected. If 493 F, G or the link F<->G failed, then the network would be partitioned. 494 It is clearly impossible to have two link-disjoint or node-disjoint 495 paths from G, I or J to R. The MRTs given in (b) and (c) offer paths 496 that are as disjoint as possible. For instance, the paths from B to 497 R are the same as in Figure 2 and the path from G to R on the Blue 498 MRT is G->F->D->E->R and on the Red MRT is G->F->B->A->R. 500 [E]---[D]---| 501 | | | |----[I] 502 | | | | | 503 [R]---[C] [F]---[G] | 504 | | | | | 505 | | | |----[J] 506 [A]---[B]---| 508 (a) 509 a non-2-connected graph 511 [E]<--[D]<--| [E]-->[D] 512 | ^ | [I] | |----[I] 513 V | | | V V ^ 514 [R] [C] [F]<--[G] | [R]<--[C] [F]<--[G] | 515 ^ ^ ^ V ^ | | 516 | | |----[J] | | [J] 517 [A]-->[B]---| [A]<--[B]<--| 519 (b) (c) 520 Blue MRT towards R Red MRT towards R 522 Figure 3: A non-2-connected network 524 5. Maximally Redundant Trees (MRT) and Fast-Reroute 526 In normal IGP routing, each router has its shortest path tree (SPT)to 527 all destinations. From the perspective of a particular destination, 528 D, this looks like a reverse SPT. To use maximally redundant trees, 529 in addition, each destination D has two MRTs associated with it; by 530 convention these will be called the MRT-Blue and MRT-Red. MRT-FRR is 531 realized by using multi-topology forwarding. There is a MRT-Blue 532 forwarding topology and a MRT-Red forwarding topology. 534 Any IP/LDP fast-reroute technique beyond LFA requires an additional 535 dataplane procedure, such as an additional forwarding mechanism. The 536 well-known options are multi-topology forwarding (used by MRT-FRR), 537 tunneling (e.g. [RFC6981] or [RFC7490]), and per-interface 538 forwarding (e.g. Loop-Free Failure Insensitive Routing in 539 [EnyediThesis]). 541 When there is a link or node failure affecting, but not partitioning, 542 the network, each node will still have at least one path via one of 543 the MRTs to reach the destination D. For example, in Figure 3, C 544 would normally forward traffic to R across the C<->R link. If that 545 C<->R link fails, then C could use the Blue MRT path C->D->E->R. 547 As is always the case with fast-reroute technologies, forwarding does 548 not change until a local failure is detected. Packets are forwarded 549 along the shortest path. The appropriate alternate to use is pre- 550 computed. [I-D.ietf-rtgwg-mrt-frr-algorithm] describes exactly how 551 to determine whether the MRT-Blue next-hops or the MRT-Red next-hops 552 should be the MRT alternate next-hops for a particular primary next- 553 hop to a particular destination. 555 MRT alternates are always available to use. It is a local decision 556 whether to use an MRT alternate, a Loop-Free Alternate or some other 557 type of alternate. 559 As described in [RFC5286], when a worse failure than is anticipated 560 happens, using LFAs that are not downstream neighbors can cause 561 looping among alternates. Section 1.1 of [RFC5286] gives an example 562 of link-protecting alternates causing a loop on node failure. Even 563 if a worse failure than anticipated happens, the use of MRT 564 alternates will not cause looping. 566 6. Unicast Forwarding with MRT Fast-Reroute 568 There are three possible types of routers involved in forwarding a 569 packet along an MRT path. At the MRT ingress router, the packet 570 leaves the shortest path to the destination and follows an MRT path 571 to the destination. In a FRR application, the MRT ingress router is 572 the PLR. An MRT transit router takes a packet that arrives already 573 associated with the particular MRT, and forwards it on that same MRT. 574 In some situations (to be discussed later), the packet will need to 575 leave the MRT path and return to the shortest path. This takes place 576 at the MRT egress router. The MRT ingress and egress functionality 577 may depend on the underlying type of packet being forwarded (LDP or 578 IP). The MRT transit functionality is independent of the type of 579 packet being forwarded. We first consider several MRT transit 580 forwarding mechanisms. Then we look at how these forwarding 581 mechanisms can be applied to carrying LDP and IP traffic. 583 6.1. MRT Forwarding Mechanisms 585 The following options for MRT forwarding mechanisms are considered. 587 1. MRT LDP Labels 589 A. Topology-scoped FEC encoded using a single label 591 B. Topology and FEC encoded using a two label stack 593 2. MRT IP Tunnels 595 A. MRT IPv4 Tunnels 597 B. MRT IPv6 Tunnels 599 6.1.1. MRT LDP labels 601 We consider two options for the MRT forwarding mechanisms using MRT 602 LDP labels. 604 6.1.1.1. Topology-scoped FEC encoded using a single label (Option 1A) 606 [RFC7307] provides a mechanism to distribute FEC-Label bindings 607 scoped to a given MPLS topology (represented by MPLS MT-ID). To use 608 multi-topology LDP to create MRT forwarding topologies, we associate 609 two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies, 610 in addition to the default shortest path forwarding topology with MT- 611 ID=0. 613 With this forwarding mechanism, a single label is distributed for 614 each topology-scoped FEC. For a given FEC in the default topology 615 (call it default-FEC-A), two additional topology-scoped FECs would be 616 created, corresponding to the Red and Blue MRT forwarding topologies 617 (call them red-FEC-A and blue-FEC-A). A router supporting this MRT 618 transit forwarding mechanism advertises a different FEC-label binding 619 for each of the three topology-scoped FECs. When a packet is 620 received with a label corresponding to red-FEC-A (for example), an 621 MRT transit router will determine the next-hop for the MRT-Red 622 forwarding topology for that FEC, swap the incoming label with the 623 outgoing label corresponding to red-FEC-A learned from the MRT-Red 624 next-hop router, and forward the packet. 626 This forwarding mechanism has the useful property that the FEC 627 associated with the packet is maintained in the labels at each hop 628 along the MRT. We will take advantage of this property when 629 specifying how to carry LDP traffic on MRT paths using multi-topology 630 LDP labels. 632 This approach is very simple for hardware to support. However, it 633 reduces the label space for other uses, and it increases the memory 634 needed to store the labels and the communication required by LDP to 635 distribute FEC-label bindings. 637 This forwarding option uses the LDP signaling extensions described in 638 [RFC7307]. The MRT-specific LDP extensions required to support this 639 option will be described elsewhere. 641 6.1.1.2. Topology and FEC encoded using a two label stack (Option 1B) 643 With this forwarding mechanism, a two label stack is used to encode 644 the topology and the FEC of the packet. The top label (topology-id 645 label) identifies the MRT forwarding topology, while the second label 646 (FEC label) identifies the FEC. The top label would be a new FEC 647 type with two values corresponding to MRT Red and Blue topologies. 649 When an MRT transit router receives a packet with a topology-id 650 label, the router pops the top label and uses that it to guide the 651 next-hop selection in combination with the next label in the stack 652 (the FEC label). The router then swaps the FEC label, using the FEC- 653 label bindings learned through normal LDP mechanisms. The router 654 then pushes the topology-id label for the next-hop. 656 As with Option 1A, this forwarding mechanism also has the useful 657 property that the FEC associated with the packet is maintained in the 658 labels at each hop along the MRT. 660 This forwarding mechanism has minimal usage of additional labels, 661 memory and LDP communication. It does increase the size of packets 662 and the complexity of the required label operations and look-ups. 664 This forwarding option is consistent with context-specific label 665 spaces, as described in [RFC5331]. However, the precise LDP behavior 666 required to support this option for MRT has not been specified. 668 6.1.1.3. Compatibility of Option 1A and 1B 670 In principle, MRT transit forwarding mechanisms 1A and 1B can coexist 671 in the same network, with a packet being forwarding along a single 672 MRT path using the single label of option 1A for some hops and the 673 two label stack of option 1B for other hops. 675 6.1.1.4. Mandatory support for MRT LDP Label option 1A 677 If a router supports a profile that includes the MRT LDP Label option 678 for MRT transit forwarding mechanism, then it MUST support option 1A, 679 which encodes topology-scoped FECs using a single label. 681 6.1.2. MRT IP tunnels (Options 2A and 2B) 683 IP tunneling can also be used as an MRT transit forwarding mechanism. 684 Each router supporting this MRT transit forwarding mechanism 685 announces two additional loopback addresses and their associated MRT 686 color. Those addresses are used as destination addresses for MRT- 687 blue and MRT-red IP tunnels respectively. The special loopback 688 addresses allow the transit nodes to identify the traffic as being 689 forwarded along either the MRT-blue or MRT-red topology to reach the 690 tunnel destination. For example, an MRT ingress router can cause a 691 packet to be tunneled along the MRT-red path to router X by 692 encapsulating the packet using the MRT-red loopback address 693 advertised by router X. Upon receiving the packet, router X would 694 remove the encapsulation header and forward the packet based on the 695 original destination address. 697 Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the 698 tunneling mechanism. 700 Note that the two forwarding mechanisms using LDP Label options do 701 not require additional loopbacks per router, as is required by the IP 702 tunneling mechanism. This is because LDP labels are used on a hop- 703 by-hop basis to identify MRT-blue and MRT-red forwarding topologies. 705 6.2. Forwarding LDP Unicast Traffic over MRT Paths 707 In the previous section, we examined several options for providing 708 MRT transit forwarding functionality, which is independent of the 709 type of traffic being carried. We now look at the MRT ingress 710 functionality, which will depend on the type of traffic being carried 711 (IP or LDP). We start by considering LDP traffic. 713 We also simplify the initial discussion by assuming that the network 714 consists of a single IGP area, and that all routers in the network 715 participate in MRT. Other deployment scenarios that require MRT 716 egress functionality are considered later in this document. 718 In principle, it is possible to carry LDP traffic in MRT IP tunnels. 719 However, for LDP traffic, it is desirable to avoid tunneling. 720 Tunneling LDP traffic to a remote node requires knowledge of remote 721 FEC-label bindings so that the LDP traffic can continue to be 722 forwarded properly when it leaves the tunnel. This requires targeted 723 LDP sessions which can add management complexity. As described 724 below, the two MRT forwarding mechanisms that use LDP labels do not 725 require targeted LDP sessions. 727 6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option 1A) 729 The MRT LDP Label option 1A forwarding mechanism uses topology-scoped 730 FECs encoded using a single label as described in section 731 Section 6.1.1.1. When a PLR receives an LDP packet that needs to be 732 forwarded on the Red MRT (for example), it does a label swap 733 operation, replacing the usual LDP label for the FEC with the Red MRT 734 label for that FEC received from the next-hop router in the Red MRT 735 computed by the PLR. When the next-hop router in the Red MRT 736 receives the packet with the Red MRT label for the FEC, the MRT 737 transit forwarding functionality continues as described in 738 Section 6.1.1.1. In this way the original FEC associated with the 739 packet is maintained at each hop along the MRT. 741 6.2.2. Forwarding LDP traffic using MRT LDP Labels (Option 1B) 743 The MRT LDP Label option 1B forwarding mechanism encodes the topology 744 and the FEC using a two label stack as described in Section 6.1.1.2. 745 When a PLR receives an LDP packet that needs to be forwarded on the 746 Red MRT, it first does a normal LDP label swap operation, replacing 747 the incoming normal LDP label associated with a given FEC with the 748 outgoing normal LDP label for that FEC learned from the next-hop on 749 the Red MRT. In addition, the PLR pushes the topology-identification 750 label associated with the Red MRT, and forward the packet to the 751 appropriate next-hop on the Red MRT. When the next-hop router in the 752 Red MRT receives the packet with the Red MRT label for the FEC, the 753 MRT transit forwarding functionality continues as described in 754 Section 6.1.1.2. As with option 1A, the original FEC associated with 755 the packet is maintained at each hop along the MRT. 757 6.2.3. Other considerations for forwarding LDP traffic using MRT LDP 758 Labels 760 Note that forwarding LDP traffic using MRT LDP Labels can be done 761 without the use of targeted LDP sessions when an MRT path to the 762 destination FEC is used. The alternates selected in 763 [I-D.ietf-rtgwg-mrt-frr-algorithm] use the MRT path to the 764 destination FEC, so targeted LDP sessions are not needed. If instead 765 one found it desirable to have the PLR use an MRT to reach the 766 primary next-next-hop for the FEC, and then continue forwarding the 767 LDP packet along the shortest path tree from the primary next-next- 768 hop, this would require tunneling to the primary next-next-hop and a 769 targeted LDP session for the PLR to learn the FEC-label binding for 770 primary next-next-hop to correctly forward the packet. 772 For greatest hardware compatibility, routers implementing MRT fast- 773 reroute of LDP traffic MUST support Option 1A of encoding the MT-ID 774 in the labels (See Section 9). 776 6.3. Forwarding IP Unicast Traffic over MRT Paths 778 For IPv4 traffic, there is no currently practical alternative except 779 tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red 780 forwarding topology. For IPv6 traffic, in principle one could define 781 bits in the IPv6 options header to indicate the MRT-Blue or MRT-Red 782 forwarding topology. However, in this document, we have chosen not 783 to define a solution that would work for IPv6 traffic but not for 784 IPv4 traffic. 786 The choice of tunnel egress is flexible since any router closer to 787 the destination than the next-hop can work. This architecture 788 assumes that the original destination in the area is selected (see 789 Section 11 for handling of multi-homed prefixes); another possible 790 choice is the next-next-hop towards the destination. As discussed in 791 the previous section, for LDP traffic, using the MRT to the original 792 destination simplifies MRT-FRR by avoiding the need for targeted LDP 793 sessions to the next-next-hop. For IP, that consideration doesn't 794 apply. 796 Some situations require tunneling IP traffic along an MRT to a tunnel 797 endpoint that is not the destination of the IP traffic. These 798 situations will be discussed in detail later. We note here that an 799 IP packet with a destination in a different IGP area/level from the 800 PLR should be tunneled on the MRT to the ABR/LBR on the shortest path 801 to the destination. For a destination outside of the PLR's MRT 802 Island, the packet should be tunneled on the MRT to a non-proxy-node 803 immediately before the named proxy-node on that particular color MRT. 805 6.3.1. Tunneling IP traffic using MRT LDP Labels 807 An IP packet can be tunneled along an MRT path by pushing the 808 appropriate MRT LDP label(s). Tunneling using LDP labels, as opposed 809 to IP headers, has the the advantage that more installed routers can 810 do line-rate encapsulation and decapsulation using LDP than using IP. 811 Also, no additional IP addresses would need to be allocated or 812 signaled. 814 6.3.1.1. Tunneling IP traffic using MRT LDP Labels (Option 1A) 816 The MRT LDP Label option 1A forwarding mechanism uses topology-scoped 817 FECs encoded using a single label as described in section 818 Section 6.1.1.1. When a PLR receives an IP packet that needs to be 819 forwarded on the Red MRT to a particular tunnel endpoint, it does a 820 label push operation. The label pushed is the Red MRT label for a 821 FEC originated by the tunnel endpoint, learned from the next-hop on 822 the Red MRT. 824 6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option 1B) 826 The MRT LDP Label option 1B forwarding mechanism encodes the topology 827 and the FEC using a two label stack as described in Section 6.1.1.2. 828 When a PLR receives an IP packet that needs to be forwarded on the 829 Red MRT to a particular tunnel endpoint, the PLR pushes two labels on 830 the IP packet. The first (inner) label is the normal LDP label 831 learned from the next-hop on the Red MRT, associated with a FEC 832 originated by the tunnel endpoint. The second (outer) label is the 833 topology-identification label associated with the Red MRT. 835 For completeness, we note here a potential variation that uses a 836 single label as opposed to two labels. In order to tunnel an IP 837 packet over an MRT to the destination of the IP packet (as opposed to 838 an arbitrary tunnel endpoint), then we could just push a topology- 839 identification label directly onto the packet. An MRT transit router 840 would need to pop the topology-id label, do an IP route lookup in the 841 context of that topology-id , and push the topology-id label. 843 6.3.2. Tunneling IP traffic using MRT IP Tunnels 845 In order to tunnel over the MRT to a particular tunnel endpoint, the 846 PLR encapsulates the original IP packet with an additional IP header 847 using the MRT-Blue or MRT-Red loopack address of the tunnel endpoint. 849 6.3.3. Required support 851 For greatest hardware compatibility and ease in removing the MRT- 852 topology marking at area/level boundaries, routers that support MPLS 853 and implement IP MRT fast-reroute MUST support tunneling of IP 854 traffic using MRT LDP Labels Option 1A (topology-scoped FEC encoded 855 using a single label). 857 7. MRT Island Formation 859 The purpose of communicating support for MRT is to indicate that the 860 MRT-Blue and MRT-Red forwarding topologies are created for transit 861 traffic. The MRT architecture allows for different, potentially 862 incompatible options. In order to create consistent MRT forwarding 863 topologies, the routers participating in a particular MRT Island need 864 to use the same set of options. These options are grouped into MRT 865 profiles. In addition, the routers in an MRT Island all need to use 866 the same set of nodes and links within the Island when computing the 867 MRT forwarding topologies. This section describes the information 868 used by a router to determine the nodes and links to include in a 869 particular MRT Island. Some information already exists in the IGPs 870 and can be used by MRT in Island formation, subject to the 871 interpretation defined here. 873 Other information needs to be communicated between routers for which 874 there do not currently exist protocol extensions. This new 875 information needs to be shared among all routers in an IGP area, so 876 defining extensions to existing IGPs to carry this information makes 877 sense. These new protocol extensions will be defined elsewhere. 879 Deployment scenarios using multi-topology OSPF or IS-IS, or running 880 both ISIS and OSPF on the same routers is out of scope for this 881 specification. As with LFA, it is expected that OSPF Virtual Links 882 will not be supported. 884 7.1. IGP Area or Level 886 All links in an MRT Island MUST be bidirectional and belong to the 887 same IGP area or level. For ISIS, a link belonging to both level 1 888 and level 2 would qualify to be in multiple MRT Islands. A given ABR 889 or LBR can belong to multiple MRT Islands, corresponding to the areas 890 or levels in which it participates. Inter-area forwarding behavior 891 is discussed in Section 10. 893 7.2. Support for a specific MRT profile 895 All routers in an MRT Island MUST support the same MRT profile. A 896 router advertises support for a given MRT profile using an 8-bit MRT 897 Profile ID value. The registry for the MRT Profile ID is defined in 898 this document. The protocol extensions for advertising the MRT 899 Profile ID value will be defined elsewhere. A given router can 900 support multiple MRT profiles and participate in multiple MRT 901 Islands. The options that make up an MRT profile, as well as the 902 default MRT profile, are defined in Section 8. 904 Note that a router may advertise support for multiple different MRT 905 profiles. The process of MRT Island formation takes place 906 independently for each MRT profile advertised by a given router. For 907 example, consider a network with 40 connected routers in the same 908 area advertising support for MRT Profile A and MRT Profile B. Two 909 distinct MRT Islands will be formed corresponding to Profile A and 910 Profile B, with each island containing all 40 routers. A complete 911 set of maximally redundant trees will be computed for each island 912 following the rules defined for each profile. If we add a third MRT 913 Profile to this example, with Profile C being advertised by a 914 connected subset of 30 routers, there will be a third MRT Island 915 formed corresponding to those 30 routers, and a third set of 916 maximally redundant trees will be computed. In this example, 40 917 routers would compute and install two sets of MRT transit forwarding 918 entries corresponding to Profiles A and B, while 30 routers would 919 compute and install three sets of MRT transit forwarding entries 920 corresponding to Profiles A, B, and C. 922 7.3. Excluding additional routers and interfaces from the MRT Island 924 MRT takes into account existing IGP mechanisms for discouraging 925 traffic from using particular links and routers, and it introduces an 926 MRT-specific exclusion mechanism for links. 928 7.3.1. Existing IGP exclusion mechanisms 930 Mechanisms for discouraging traffic from using particular links 931 already exist in ISIS and OSPF. In ISIS, an interface configured 932 with a metric of 2^24-2 (0xFFFFFE) will only be used as a last 933 resort. (An interface configured with a metric of 2^24-1 (0xFFFFFF) 934 will not be advertised into the topology.) In OSPF, an interface 935 configured with a metric of 2^16-1 (0xFFFF) will only be used as a 936 last resort. These metrics can be configured manually to enforce 937 administrative policy, or they can be set in an automated manner as 938 with LDP IGP synchronization [RFC5443]. 940 Mechanisms also already exist in ISIS and OSPF to discourage or 941 prevent transit traffic from using a particular router. In ISIS, the 942 overload bit is prevents transit traffic from using a router. 944 For OSPFv2 and OSPFv3, [RFC6987] specifies setting all outgoing 945 interface metrics to 0xFFFF to discourage transit traffic from using 946 a router.( [RFC6987] defines the metric value 0xFFFF as 947 MaxLinkMetric, a fixed architectural value for OSPF.) For OSPFv3, 948 [RFC5340] specifies that a router be excluded from the intra-area 949 shortest path tree computation if the V6-bit or R-bit of the LSA 950 options is not set in the Router LSA. 952 The following rules for MRT Island formation ensure that MRT FRR 953 protection traffic does not use a link or router that is discouraged 954 or prevented from carrying traffic by existing IGP mechanisms. 956 1. A bidirectional link MUST be excluded from an MRT Island if 957 either the forward or reverse cost on the link is 0xFFFFFE (for 958 ISIS) or 0xFFFF for OSPF. 960 2. A router MUST be excluded from an MRT Island if it is advertised 961 with the overload bit set (for ISIS), or it is advertised with 962 metric values of 0xFFFF on all of its outgoing interfaces (for 963 OSPFv2 and OSPFv3). 965 3. A router MUST be excluded from an MRT Island if it is advertised 966 with either the V6-bit or R-bit of the LSA options not set in the 967 Router LSA. 969 7.3.2. MRT-specific exclusion mechanism 971 This architecture also defines a means of excluding an otherwise 972 usable link from MRT Islands. The protocol extensions for 973 advertising that a link is MRT-Ineligible will be defined elsewhere. 974 A link with either interface advertised as MRT-Ineligible MUST be 975 excluded from an MRT Island. Note that an interface advertised as 976 MRT-Ineligible by a router is ineligible with respect to all profiles 977 advertised by that router. 979 7.4. Connectivity 981 All of the routers in an MRT Island MUST be connected by 982 bidirectional links with other routers in the MRT Island. 983 Disconnected MRT Islands will operate independently of one another. 985 7.5. Algorithm for MRT Island Identification 987 An algorithm that allows a computing router to identify the routers 988 and links in the local MRT Island satisfying the above rules is given 989 in section 5.2 of [I-D.ietf-rtgwg-mrt-frr-algorithm]. 991 8. MRT Profile 993 An MRT Profile is a set of values and options related to MRT 994 behavior. The complete set of options is designated by the 995 corresponding 8-bit Profile ID value. 997 This document specifies the values and options that correspond to the 998 Default MRT Profile (Profile ID = 0). Future documents may define 999 other MRT Profiles by specifying the MRT Profile Options below. 1001 8.1. MRT Profile Options 1003 Below is a description of the values and options that define an MRT 1004 Profile. 1006 MRT Algorithm: This identifies the particular algorithm for 1007 computing maximally redundant trees used by the router for this 1008 profile. 1010 MRT-Red MT-ID: This specifies the MPLS MT-ID to be associated with 1011 the MRT-Red forwarding topology. It is allocated from the MPLS 1012 Multi-Topology Identifiers Registry. 1014 MRT-Blue MT-ID: This specifies the MPLS MT-ID to be associated with 1015 the MRT-Blue forwarding topology. It is allocated from the MPLS 1016 Multi-Topology Identifiers Registry. 1018 GADAG Root Selection Policy: This specifies the manner in which the 1019 GADAG root is selected. All routers in the MRT island need to use 1020 the same GADAG root in the calculations used construct the MRTs. 1021 A valid GADAG Root Selection Policy MUST be such that each router 1022 in the MRT island chooses the same GADAG root based on information 1023 available to all routers in the MRT island. GADAG Root Selection 1024 Priority values, advertised as router-specific MRT parameters, MAY 1025 be used in a GADAG Root Selection Policy. 1027 MRT Forwarding Mechanism: This specifies which forwarding mechanism 1028 the router uses to carry transit traffic along MRT paths. A 1029 router which supports a specific MRT forwarding mechanism must 1030 program appropriate next-hops into the forwarding plane. The 1031 current options are MRT LDP Labels, IPv4 Tunneling, IPv6 1032 Tunneling, and None. If the MRT LDP Labels option is supported, 1033 then option 1A and the appropriate signaling extensions MUST be 1034 supported. If IPv4 is supported, then both MRT-Red and MRT-Blue 1035 IPv4 Loopback Addresses SHOULD be specified. If IPv6 is 1036 supported, both MRT-Red and MRT-Blue IPv6 Loopback Addresses 1037 SHOULD be specified. 1039 Recalculation: Recalculation specifies the process and timing by 1040 which new MRTs are computed after the topology has been modified. 1042 Area/Level Border Behavior: This specifies how traffic traveling on 1043 the MRT-Blue or MRT-Red in one area should be treated when it 1044 passes into another area. 1046 Other Profile-Specific Behavior: Depending upon the use-case for 1047 the profile, there may be additional profile-specific behavior. 1049 When a new MRT Profile is defined, new and unique values should be 1050 allocated from the MPLS Multi-Topology Identifiers Registry, 1051 corresponding to the MRT-Red and MRT-Blue MT-ID values for the new 1052 MRT Profile . 1054 If a router advertises support for multiple MRT profiles, then it 1055 MUST create the transit forwarding topologies for each of those, 1056 unless the profile specifies the None option for MRT Forwarding 1057 Mechanism. 1059 The ability of MRT-FRR to support transit forwarding entries for 1060 multiple profiles can be used to facilitate a smooth transition from 1061 an existing deployed MRT Profile to a new MRT Profile. The new 1062 profile can be activated in parallel with the existing profile, 1063 installing the transit forwarding entries for the new profile without 1064 affecting the transit forwarding entries for the existing profile. 1065 Once the new transit forwarding state has been verified, the router 1066 can be configured to use the alternates computed by the new profile 1067 in the event of a failure. 1069 8.2. Router-specific MRT paramaters 1071 For some profiles, additional router-specific MRT parameters may need 1072 to be advertised. While the set of options indicated by the MRT 1073 Profile ID must be identical for all routers in an MRT Island, these 1074 router-specific MRT parameters may differ between routers in the same 1075 MRT island. Several such parameters are described below. 1077 GADAG Root Selection Priority: A GADAG Root Selection Policy MAY 1078 rely on the GADAG Root Selection Priority values advertised by 1079 each router in the MRT island. A GADAG Root Selection Policy may 1080 use the GADAG Root Selection Priority to allow network operators 1081 to configure a parameter to ensure that the GADAG root is selected 1082 from a particular subset of routers. An example of this use of 1083 the GADAG Root Selection Priority value by the GADAG Root 1084 Selection Policy is given in the Default MRT profile below. 1086 MRT-Red Loopback Address: This provides the router's loopback 1087 address to reach the router via the MRT-Red forwarding topology. 1088 It can be specified for either IPv4 or IPv6. Note that this 1089 parameter is not needed to support the Default MRT profile. 1091 MRT-Blue Loopback Address: This provides the router's loopback 1092 address to reach the router via the MRT-Blue forwarding topology. 1093 It can be specified for either IPv4 and IPv6. Note that this 1094 parameter is not needed to support the Default MRT profile. 1096 Protocol extensions for advertising a router's GADAG Root Selection 1097 Priority value will be defined in other documents. Protocol 1098 extensions for the advertising a router's MRT-Red and MRT-Blue 1099 Loopback Addresses will be defined elsewhere. 1101 8.3. Default MRT profile 1103 The following set of options defines the default MRT Profile. The 1104 default MRT profile is indicated by the MRT Profile ID value of 0. 1106 MRT Algorithm: MRT Lowpoint algorithm defined in 1107 [I-D.ietf-rtgwg-mrt-frr-algorithm]. 1109 MRT-Red MPLS MT-ID: This value will be allocated from the MPLS 1110 Multi-Topology Identifiers Registry. The IANA request for this 1111 allocation will be in another document. 1113 MRT-Blue MPLS MT-ID: This value will be allocated from the MPLS 1114 Multi-Topology Identifiers Registry. The IANA request for this 1115 allocation will be in another document. 1117 GADAG Root Selection Policy: Among the routers in the MRT Island 1118 and with the most preferred GADAG Root Selection Priority 1119 advertised (corresponding to the lowest numerical value of GADAG 1120 Root Selection Priority), an implementation MUST pick the router 1121 with the highest Router ID to be the GADAG root. 1123 Forwarding Mechanisms: MRT LDP Labels 1125 Recalculation: Recalculation of MRTs SHOULD occur as described in 1126 Section 12.2. This allows the MRT forwarding topologies to 1127 support IP/LDP fast-reroute traffic. 1129 Area/Level Border Behavior: As described in Section 10, ABRs/LBRs 1130 SHOULD ensure that traffic leaving the area also exits the MRT-Red 1131 or MRT-Blue forwarding topology. 1133 9. LDP signaling extensions and considerations 1135 The protocol extensions for LDP will be defined in another document. 1136 A router must indicate that it has the ability to support MRT; having 1137 this explicit allows the use of MRT-specific processing, such as 1138 special handling of FECs sent with the Rainbow MRT MT-ID. 1140 A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies 1141 to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles. 1142 The FEC-label bindings for the default shortest-path based MT-ID 0 1143 MUST still be sent (even though it could be inferred from the Rainbow 1144 FEC-label bindings) to ensure continuous operation of normal LDP 1145 forwarding. The Rainbow MRT MT-ID is defined to provide an easy way 1146 to handle the special signaling that is needed at ABRs or LBRs. It 1147 avoids the problem of needing to signal different MPLS labels to 1148 different LDP neighbors for the same FEC. Because the Rainbow MRT 1149 MT-ID is used only by ABRs/LBRs or an LDP egress router, it is not 1150 MRT profile specific. 1152 The value of the Rainbow MRT MPLS MT-ID will be allocated from the 1153 MPLS Multi-Topology Identifiers Registry. The IANA request for this 1154 allocation will be in another document. 1156 10. Inter-area Forwarding Behavior 1158 An ABR/LBR has two forwarding roles. First, it forwards traffic 1159 within areas. Second, it forwards traffic from one area into 1160 another. These same two roles apply for MRT transit traffic. 1162 Traffic on MRT-Red or MRT-Blue destined inside the area needs to stay 1163 on MRT-Red or MRT-Blue in that area. However, it is desirable for 1164 traffic leaving the area to also exit MRT-Red or MRT-Blue and return 1165 to shortest path forwarding. 1167 For unicast MRT-FRR, the need to stay on an MRT forwarding topology 1168 terminates at the ABR/LBR whose best route is via a different area/ 1169 level. It is highly desirable to go back to the default forwarding 1170 topology when leaving an area/level. There are three basic reasons 1171 for this. First, the default topology uses shortest paths; the 1172 packet will thus take the shortest possible route to the destination. 1173 Second, this allows failures that might appear in multiple areas 1174 (e.g. ABR/LBR failures) to be separately identified and repaired 1175 around. Third, the packet can be fast-rerouted again, if necessary, 1176 due to a failure in a different area. 1178 An ABR/LBR that receives a packet on MRT-Red or MRT-Blue towards 1179 destination Z should continue to forward the packet along MRT-Red or 1180 MRT-Blue only if the best route to Z is in the same area as the 1181 interface that the packet was received on. Otherwise, the packet 1182 should be removed from MRT-Red or MRT-Blue and forwarded on the 1183 shortest-path default forwarding topology. 1185 To avoid per-interface forwarding state for MRT-Red and MRT-Blue, the 1186 ABR/LBR needs to arrange that packets destined to a different area 1187 arrive at the ABR/LBR already not marked as MRT-Red or MRT-Blue. 1189 10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A 1191 For LDP forwarding where a single label specifies (MT-ID, FEC), the 1192 ABR/LBR is responsible for advertising the proper label to each 1193 neighbor. Assume that an ABR/LBR has allocated three labels for a 1194 particular destination; those labels are L_primary, L_blue, and 1195 L_red. To those routers in the same area as the best route to the 1196 destination, the ABR/LBR advertises the following FEC-label bindings: 1197 L_primary for the default topology, L_blue for the MRT-Blue MT-ID and 1198 L_red for the MRT-Red MT-ID, as expected. However, to routers in 1199 other areas, the ABR/LBR advertises the following FEC-label bindings: 1200 L_primary for the default topology, and L_primary for the Rainbow MRT 1201 MT-ID. Associating L_primary with the Rainbow MRT MT-ID causes the 1202 receiving routers to use L_primary for the MRT-Blue MT-ID and for the 1203 MRT-Red MT-ID. 1205 The ABR/LBR installs all next-hops for the best area: primary next- 1206 hops for L_primary, MRT-Blue next-hops for L_blue, and MRT-Red next- 1207 hops for L_red. Because the ABR/LBR advertised (Rainbow MRT MT-ID, 1208 FEC) with L_primary to neighbors not in the best area, packets from 1209 those neighbors will arrive at the ABR/LBR with a label L_primary and 1210 will be forwarded into the best area along the default topology. By 1211 controlling what labels are advertised, the ABR/LBR can thus enforce 1212 that packets exiting the area do so on the shortest-path default 1213 topology. 1215 10.1.1. Motivation for Creating the Rainbow-FEC 1217 The desired forwarding behavior could be achieved in the above 1218 example without using the Rainbow-FEC. This could be done by having 1219 the ABR/LBR advertise the following FEC-label bindings to neighbors 1220 not in the best area: L1_primary for the default topology, L1_primary 1221 for the MRT-Blue MT-ID, and L1_primary for the MRT-Red MT-ID. Doing 1222 this would require machinery to spoof the labels used in FEC-label 1223 binding advertisements on a per-neighbor basis. Such label-spoofing 1224 machinery does not currently exist in most LDP implmentations and 1225 doesn't have other obvious uses. 1227 Many existing LDP implmentations do however have the ability to 1228 filter FEC-label binding advertisements on a per-neighbor basis. The 1229 Rainbow-FEC allows us to re-use the existing per-neighbor FEC 1230 filtering machinery to achieve the desired result. By introducing 1231 the Rainbow FEC, we can use per-neighbor FEC-filtering machinery to 1232 advertise the FEC-label binding for the Rainbow-FEC (and filter those 1233 for MRT-Blue and MRT-Red) to non-best-area neighbors of the ABR. 1235 The use of the Rainbow-FEC by the ABR for non-best-area 1236 advertisements is RECOMMENDED. An ABR MAY advertise the label for 1237 the default topology in separate MRT-Blue and MRT-Red advertisements. 1238 However, a router that supports the LDP Label MRT Forwarding 1239 Mechanism MUST be able to receive and correctly interpret the 1240 Rainbow-FEC. 1242 10.2. ABR Forwarding Behavior with IP Tunneling (option 2) 1244 If IP tunneling is used, then the ABR/LBR behavior is dependent upon 1245 the outermost IP address. If the outermost IP address is an MRT 1246 loopback address of the ABR/LBR, then the packet is decapsulated and 1247 forwarded based upon the inner IP address, which should go on the 1248 default SPT topology. If the outermost IP address is not an MRT 1249 loopback address of the ABR/LBR, then the packet is simply forwarded 1250 along the associated forwarding topology. A PLR sending traffic to a 1251 destination outside its local area/level will pick the MRT and use 1252 the associated MRT loopback address of the selected ABR/LBR 1253 advertising the lowest cost to the external destination. 1255 Thus, for these two MRT Forwarding Mechanisms (MRT LDP Label option 1256 1A and IP tunneling option 2), there is no need for additional 1257 computation or per-area forwarding state. 1259 10.3. ABR Forwarding Behavior with LDP Label option 1B 1261 The other MRT forwarding mechanism described in Section 6 uses two 1262 labels, a topology-id label, and a FEC-label. This mechanism would 1263 require that any router whose MRT-Red or MRT-Blue next-hop is an ABR/ 1264 LBR would need to determine whether the ABR/LBR would forward the 1265 packet out of the area/level. If so, then that router should pop off 1266 the topology-identification label before forwarding the packet to the 1267 ABR/LBR. 1269 For example, in Figure 4, if node H fails, node E has to put traffic 1270 towards prefix p onto MRT-Red. But since node D knows that ABR1 will 1271 use a best route from another area, it is safe for D to pop the 1272 Topology-Identification Label and just forward the packet to ABR1 1273 along the MRT-Red next-hop. ABR1 will use the shortest path in Area 1274 10. 1276 In all cases for ISIS and most cases for OSPF, the penultimate router 1277 can determine what decision the adjacent ABR will make. The one case 1278 where it can't be determined is when two ASBRs are in different non- 1279 backbone areas attached to the same ABR, then the ASBR's Area ID may 1280 be needed for tie-breaking (prefer the route with the largest OPSF 1281 area ID) and the Area ID isn't announced as part of the ASBR link- 1282 state advertisement (LSA). In this one case, suboptimal forwarding 1283 along the MRT in the other area would happen. If that becomes a 1284 realistic deployment scenario, protocol extensions could be developed 1285 to address this issue. 1287 +----[C]---- --[D]--[E] --[D]--[E] 1288 | \ / \ / \ 1289 p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+ 1290 | / \ / | \ / | 1291 +----[B]---- --[F]--[G] | --[F]--[G] | 1292 | | 1293 | other | 1294 +----------[p]-------+ 1295 area 1297 (a) Example topology (b) Proxy node view in Area 0 nodes 1299 +----[C]<--- [D]->[E] 1300 V \ \ 1301 +-[A] Area 10 [ABR1] Area 0 [H]-+ 1302 | ^ / / | 1303 | +----[B]<--- [F]->[G] V 1304 | | 1305 +------------->[p]<--------------+ 1307 (c) rSPT towards destination p 1309 ->[D]->[E] -<[D]<-[E] 1310 / \ / \ 1311 [ABR1] Area 0 [H]-+ +-[ABR1] [H] 1312 / | | \ 1313 [F]->[G] V V -<[F]<-[G] 1314 | | 1315 | | 1316 [p]<------+ +--------->[p] 1318 (d) Blue MRT in Area 0 (e) Red MRT in Area 0 1320 Figure 4: ABR Forwarding Behavior and MRTs 1322 11. Prefixes Multiply Attached to the MRT Island 1324 How a computing router S determines its local MRT Island for each 1325 supported MRT profile is already discussed in Section 7. 1327 There are two types of prefixes or FECs that may be multiply attached 1328 to an MRT Island. The first type are multi-homed prefixes that 1329 usually connect at a domain or protocol boundary. The second type 1330 represent routers that do not support the profile for the MRT Island. 1332 The key difference is whether the traffic, once out of the MRT 1333 Island, might re-enter the MRT Island if a loop-free exit point is 1334 not selected. 1336 FRR using LFA has the useful property that it is able to protect 1337 multi-homed prefixes against ABR failure. For instance, if a prefix 1338 from the backbone is available via both ABR A and ABR B, if A fails, 1339 then the traffic should be redirected to B. This can be accomplished 1340 with MRT FRR as well. 1342 If ASBR protection is desired, this has additional complexities if 1343 the ASBRs are in different areas. Similarly, protecting labeled BGP 1344 traffic in the event of an ASBR failure has additional complexities 1345 due to the per-ASBR label spaces involved. 1347 As discussed in [RFC5286], a multi-homed prefix could be: 1349 o An out-of-area prefix announced by more than one ABR, 1351 o An AS-External route announced by 2 or more ASBRs, 1353 o A prefix with iBGP multipath to different ASBRs, 1355 o etc. 1357 See Appendix A for a discussion of a general issue with multi-homed 1358 prefixes connected in two different areas. 1360 There are also two different approaches to protection. The first is 1361 tunnel endpoint selection where the PLR picks a router to tunnel to 1362 where that router is loop-free with respect to the failure-point. 1363 Conceptually, the set of candidate routers to provide LFAs expands to 1364 all routers that can be reached via an MRT alternate, attached to the 1365 prefix. 1367 The second is to use a proxy-node, that can be named via MPLS label 1368 or IP address, and pick the appropriate label or IP address to reach 1369 it on either MRT-Blue or MRT-Red as appropriate to avoid the failure 1370 point. A proxy-node can represent a destination prefix that can be 1371 attached to the MRT Island via at least two routers. It is termed a 1372 named proxy-node if there is a way that traffic can be encapsulated 1373 to reach specifically that proxy-node; this could be because there is 1374 an LDP FEC for the associated prefix or because MRT-Red and MRT-Blue 1375 IP addresses are advertised (in an as-yet undefined fashion) for that 1376 proxy-node. Traffic to a named proxy-node may take a different path 1377 than traffic to the attaching router; traffic is also explicitly 1378 forwarded from the attaching router along a predetermined interface 1379 towards the relevant prefixes. 1381 For IP traffic, multi-homed prefixes can use tunnel endpoint 1382 selection. For IP traffic that is destined to a router outside the 1383 MRT Island, if that router is the egress for a FEC advertised into 1384 the MRT Island, then the named proxy-node approach can be used. 1386 For LDP traffic, there is always a FEC advertised into the MRT 1387 Island. The named proxy-node approach should be used, unless the 1388 computing router S knows the label for the FEC at the selected tunnel 1389 endpoint. 1391 If a FEC is advertised from outside the MRT Island into the MRT 1392 Island and the forwarding mechanism specified in the profile includes 1393 LDP, then the routers learning that FEC MUST also advertise labels 1394 for (MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors inside the MRT 1395 Island. Any router receiving a FEC corresponding to a router outside 1396 the MRT Island or to a multi-homed prefix MUST compute and install 1397 the transit MRT-Blue and MRT-Red next-hops for that FEC. The FEC- 1398 label bindings for the topology-scoped FECs ((MT-ID 0, FEC), (MRT- 1399 Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via LDP to 1400 neighbors inside the MRT Island. 1402 11.1. Protecting Multi-Homed Prefixes using Tunnel Endpoint Selection 1404 Tunnel endpoint selection is a local matter for a router in the MRT 1405 Island since it pertains to selecting and using an alternate and does 1406 not affect the transit MRT-Red and MRT-Blue forwarding topologies. 1408 Let the computing router be S and the next-hop F be the node whose 1409 failure is to be avoided. Let the destination be prefix p. Have A 1410 be the router to which the prefix p is attached for S's shortest path 1411 to p. 1413 The candidates for tunnel endpoint selection are those to which the 1414 destination prefix is attached in the area/level. For a particular 1415 candidate B, it is necessary to determine if B is loop-free to reach 1416 p with respect to S and F for node-protection or at least with 1417 respect to S and the link (S, F) for link-protection. If B will 1418 always prefer to send traffic to p via a different area/level, then 1419 this is definitional. Otherwise, distance-based computations are 1420 necessary and an SPF from B's perspective may be necessary. The 1421 following equations give the checks needed; the rationale is similar 1422 to that given in [RFC5286]. 1424 Loop-Free for S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p) 1426 Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p) 1427 The latter is equivalent to the following, which avoids the need to 1428 compute the shortest path from F to p. 1430 Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S, 1431 F) 1433 Finally, the rules for Endpoint selection are given below. The basic 1434 idea is to repair to the prefix-advertising router selected for the 1435 shortest-path and only to select and tunnel to a different endpoint 1436 if necessary (e.g. A=F or F is a cut-vertex or the link (S,F) is a 1437 cut-link). 1439 1. Does S have a node-protecting alternate to A? If so, select 1440 that. Tunnel the packet to A along that alternate. For example, 1441 if LDP is the forwarding mechanism, then push the label (MRT-Red, 1442 A) or (MRT-Blue, A) onto the packet. 1444 2. If not, then is there a router B that is loop-free to reach p 1445 while avoiding both F and S? If so, select B as the end-point. 1446 Determine the MRT alternate to reach B while avoiding F. Tunnel 1447 the packet to B along that alternate. For example, with LDP, 1448 push the label (MRT-Red, B) or (MRT-Blue, B) onto the packet. 1450 3. If not, then does S have a link-protecting alternate to A? If 1451 so, select that. 1453 4. If not, then is there a router B that is loop-free to reach p 1454 while avoiding S and the link from S to F? If so, select B as 1455 the endpoint and the MRT alternate for reaching B from S that 1456 avoid the link (S,F). 1458 The tunnel endpoint selected will receive a packet destined to itself 1459 and, being the egress, will pop that MPLS label (or have signaled 1460 Implicit Null) and forward based on what is underneath. This 1461 suffices for IP traffic since the tunnel endpoint can use the IP 1462 header of the original packet to continue forwarding the packet. 1463 However, tunnelling of LDP traffic requires targeted LDP sessions for 1464 learning the FEC-label binding at the tunnel endpoint. 1466 11.2. Protecting Multi-Homed Prefixes using Named Proxy-Nodes 1468 Instead, the named proxy-node method works with LDP traffic without 1469 the need for targeted LDP sessions. It also has a clear advantage 1470 over tunnel endpoint selection, in that it is possible to explicitly 1471 forward from the MRT Island along an interface to a loop-free island 1472 neighbor when that interface may not be a primary next-hop. 1474 A named proxy-node represents one or more destinations and, for LDP 1475 forwarding, has a FEC associated with it that is signalled into the 1476 MRT Island. Therefore, it is possible to explicitly label packets to 1477 go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT 1478 Island, the label will swap to meaning (MT-ID 0, FEC). It would be 1479 possible to have named proxy-nodes for IP forwarding, but this would 1480 require extensions to signal two IP addresses to be associated with 1481 MRT-Red and MRT-Blue for the proxy-node. A named proxy-node can be 1482 uniquely represented by the two routers in the MRT Island to which it 1483 is connected. The extensions to signal such IP addresses will be 1484 defined elsewhere. The details of what label-bindings must be 1485 originated will be described in another document. 1487 Computing the MRT next-hops to a named proxy-node and the MRT 1488 alternate for the computing router S to avoid a particular failure 1489 node F is straightforward. The details of the simple constant-time 1490 functions, Select_Proxy_Node_NHs() and 1491 Select_Alternates_Proxy_Node(), are given in 1492 [I-D.ietf-rtgwg-mrt-frr-algorithm]. A key point is that computing 1493 these MRT next-hops and alternates can be done as new named proxy- 1494 nodes are added or removed without requiring a new MRT computation or 1495 impacting other existing MRT paths. This maps very well to, for 1496 example, how OSPFv2 (see [RFC2328] Section 16.5) does incremental 1497 updates for new summary-LSAs. 1499 The remaining question is how to attach the named proxy-node to the 1500 MRT Island; all the routers in the MRT Island MUST do this 1501 consistently. No more than 2 routers in the MRT Island can be 1502 selected; one should only be selected if there are no others that 1503 meet the necessary criteria. The named proxy-node is logically part 1504 of the area/level. 1506 There are two sources for candidate routers in the MRT Island to 1507 connect to the named proxy-node. The first set are those routers in 1508 the MRT Island that are advertising the prefix; the named-proxy-cost 1509 assigned to each prefix-advertising router is the announced cost to 1510 the prefix. The second set are those routers in the MRT Island that 1511 are connected to routers not in the MRT Island but in the same area/ 1512 level; such routers will be defined as Island Border Routers (IBRs). 1513 The routers connected to the IBRs that are not in the MRT Island and 1514 are in the same area/level as the MRT island are Island 1515 Neighbors(INs). 1517 Since packets sent to the named proxy-node along MRT-Red or MRT-Blue 1518 may come from any router inside the MRT Island, it is necessary that 1519 whatever router to which an IBR forwards the packet be loop-free with 1520 respect to the whole MRT Island for the destination. Thus, an IBR is 1521 a candidate router only if it possesses at least one IN whose 1522 shortest path to the prefix does not enter the MRT Island. A method 1523 for identifying loop-free Island Neighbors(LFINs) is given in 1524 [I-D.ietf-rtgwg-mrt-frr-algorithm]. The named-proxy-cost assigned to 1525 each (IBR, IN) pair is cost(IBR, IN) + D_opt(IN, prefix). 1527 From the set of prefix-advertising routers and the set of IBRs with 1528 at least one LFIN, the two routers with the lowest named-proxy-cost 1529 are selected. Ties are broken based upon the lowest Router ID. For 1530 ease of discussion, the two selected routers will be referred to as 1531 proxy-node attachment routers. 1533 A proxy-node attachment router has a special forwarding role. When a 1534 packet is received destined to (MRT-Red, prefix) or (MRT-Blue, 1535 prefix), if the proxy-node attachment router is an IBR, it MUST swap 1536 to the shortest path forwarding topology (e.g. swap to the label for 1537 (MT-ID 0, prefix) or remove the outer IP encapsulation) and forward 1538 the packet to the IN whose cost was used in the selection. If the 1539 proxy-node attachment router is not an IBR, then the packet MUST be 1540 removed from the MRT forwarding topology and sent along the 1541 interface(s) that caused the router to advertise the prefix; this 1542 interface might be out of the area/level/AS. 1544 11.3. MRT Alternates for Destinations Outside the MRT Island 1546 A natural concern with new functionality is how to have it be useful 1547 when it is not deployed across an entire IGP area. In the case of 1548 MRT FRR, where it provides alternates when appropriate LFAs aren't 1549 available, there are also deployment scenarios where it may make 1550 sense to only enable some routers in an area with MRT FRR. A simple 1551 example of such a scenario would be a ring of 6 or more routers that 1552 is connected via two routers to the rest of the area. 1554 Destinations inside the local island can obviously use MRT 1555 alternates. Destinations outside the local island can be treated 1556 like a multi-homed prefix and either Endpoint Selection or Named 1557 Proxy-Nodes can be used. Named Proxy-Nodes MUST be supported when 1558 LDP forwarding is supported and a label-binding for the destination 1559 is sent to an IBR. 1561 Naturally, there are more complicated options to improve coverage, 1562 such as connecting multiple MRT islands across tunnels, but the need 1563 for the additional complexity has not been justified. 1565 12. Network Convergence and Preparing for the Next Failure 1567 After a failure, MRT detours ensure that packets reach their intended 1568 destination while the IGP has not reconverged onto the new topology. 1569 As link-state updates reach the routers, the IGP process calculates 1570 the new shortest paths. Two things need attention: micro-loop 1571 prevention and MRT re-calculation. 1573 12.1. Micro-loop prevention and MRTs 1575 A micro-loop is a transient packet forwarding loop among two or more 1576 routers that can occur during convergence of IGP forwarding state. 1577 [RFC5715] discusses several techniques for preventing micro-loops. 1578 This section discusses how MRT-FRR relates to two of the micro-loop 1579 prevention techniques discussed in [RFC5715], Nearside Tunneling and 1580 Farside Tunneling. 1582 In Nearside Tunneling, a router (PLR) adjacent to a failure perform 1583 local repair and inform remote routers of the failure. The remote 1584 routers initially tunnel affected traffic to the nearest PLR, using 1585 tunnels which are unaffected by the failure. Once the forwarding 1586 state for normal shortest path routing has converged, the remote 1587 routers return the traffic to shortest path forwarding. MRT-FRR is 1588 relevant for Nearside Tunneling for the following reason. The 1589 process of tunneling traffic to the PLRs and waiting a sufficient 1590 amount of time for IGP forwarding state convergence with Nearside 1591 Tunneling means that traffic will generally be relying on the local 1592 repair at the PLR for longer than it would in the absence of Nearside 1593 Tunneling. Since MRT-FRR provides 100% coverage for single link and 1594 node failure, it may be an attractive option to provide the local 1595 repair paths when Nearside Tunneling is deployed. 1597 MRT-FRR is also relevant for the Farside Tunneling micro-loop 1598 prevention technique. In Farside Tunneling, remote routers tunnel 1599 traffic affected by a failure to a node downstream of the failure 1600 with respect to traffic destination. This node can be viewed as 1601 being on the farside of the failure with respect to the node 1602 initiating the tunnel. Note that the discussion of Farside Tunneling 1603 in [RFC5715] focuses on the case where the farside node is 1604 immediately adjacent to a failed link or node. However, the farside 1605 node may be any node downstream of the failure with respect to 1606 traffic destination, including the destination itself. The tunneling 1607 mechanism used to reach the farside node must be unaffected by the 1608 failure. The alternative forwarding paths created by MRT-FRR have 1609 the potential to be used to forward traffic from the remote routers 1610 upstream of the failure all the way to the destination. In the event 1611 of failure, either the MRT-Red or MRT-Blue path from the remote 1612 upstream router to the destination is guaranteed to avoid a link 1613 failure or inferred node failure. The MRT forwarding paths are also 1614 guaranteed to not be subject to micro-loops because they are locked 1615 to the topology before the failure. 1617 We note that the computations in [I-D.ietf-rtgwg-mrt-frr-algorithm] 1618 address the case of a PLR adjacent to a failure determining which 1619 choice of MRT-Red or MRT-Blue will avoid a failed link or node. More 1620 computation may be required for an arbitrary remote upstream router 1621 to determine whether to choose MRT-Red or MRT-Blue for a given 1622 destination and failure. 1624 12.2. MRT Recalculation for the Default MRT Profile 1626 This section describes how the MRT recalculation SHOULD be performed 1627 for the Default MRT Profile. This is intended to support FRR 1628 applications. Other approaches are possible, but they are not 1629 specified in this document. 1631 When a failure event happens, traffic is put by the PLRs onto the MRT 1632 topologies. After that, each router recomputes its shortest path 1633 tree (SPT) and moves traffic over to that. Only after all the PLRs 1634 have switched to using their SPTs and traffic has drained from the 1635 MRT topologies should each router install the recomputed MRTs into 1636 the FIBs. 1638 At each router, therefore, the sequence is as follows: 1640 1. Receive failure notification 1642 2. Recompute SPT. 1644 3. Install the new SPT in the FIB. 1646 4. If the network was stable before the failure occured, wait a 1647 configured (or advertised) period for all routers to be using 1648 their SPTs and traffic to drain from the MRTs. 1650 5. Recompute MRTs. 1652 6. Install new MRTs in the FIB. 1654 While the recomputed MRTs are not installed in the FIB, protection 1655 coverage is lowered. Therefore, it is important to recalculate the 1656 MRTs and install them quickly. 1658 New protocol extensions for advertising the time needed to recompute 1659 shortest path routes and install them in the FIB will be defined 1660 elsewhere. 1662 13. Implementation Status 1664 [RFC Editor: please remove this section prior to publication.] 1666 This section records the status of known implementations of the 1667 protocol defined by this specification at the time of posting of this 1668 Internet-Draft, and is based on a proposal described in [RFC6982]. 1669 The description of implementations in this section is intended to 1670 assist the IETF in its decision processes in progressing drafts to 1671 RFCs. Please note that the listing of any individual implementation 1672 here does not imply endorsement by the IETF. Furthermore, no effort 1673 has been spent to verify the information presented here that was 1674 supplied by IETF contributors. This is not intended as, and must not 1675 be construed to be, a catalog of available implementations or their 1676 features. Readers are advised to note that other implementations may 1677 exist. 1679 According to [RFC6982], "this will allow reviewers and working groups 1680 to assign due consideration to documents that have the benefit of 1681 running code, which may serve as evidence of valuable experimentation 1682 and feedback that have made the implemented protocols more mature. 1683 It is up to the individual working groups to use this information as 1684 they see fit". 1686 Juniper Networks Implementation 1688 o Organization responsible for the implementation: Juniper Networks 1690 o Implementation name: MRT-FRR 1692 o Implementation description: MRT-FRR using OSPF as the IGP has been 1693 implemented and verified. 1695 o The implementation's level of maturity: prototype 1697 o Protocol coverage: This implementation of the MRT-FRR includes 1698 Island identification, GADAG root selection, MRT Lowpoint 1699 algorithm, augmentation of GADAG with additional links, and 1700 calculation of MRT transit next-hops alternate next-hops based on 1701 draft "draft-ietf-rtgwg-mrt-frr-algorithm-00". This 1702 implementation also includes the M-bit in OSPF based on "draft- 1703 atlas-ospf-mrt-01" as well as LDP MRT Capability based on "draft- 1704 atlas-mpls-ldp-mrt-00". 1706 o Licensing: proprietary 1707 o Implementation experience: Implementation was useful for verifying 1708 functionality and lack of gaps. It has also been useful for 1709 improving aspects of the algorithm. 1711 o Contact information: akatlas@juniper.net, shraddha@juniper.net, 1712 kishoret@juniper.net 1714 Huawei Technology Implementation 1716 o Organization responsible for the implementation: Huawei Technology 1717 Co., Ltd. 1719 o Implementation name: MRT-FRR and IS-IS extensions for MRT. 1721 o Implementation description: The MRT-FRR using IS-IS extensions for 1722 MRT and LDP multi-topology have been implemented and verified. 1724 o The implementation's level of maturity: prototype 1726 o Protocol coverage: This implementation of the MRT algorithm 1727 includes Island identification, GADAG root selection, MRT Lowpoint 1728 algorithm, augmentation of GADAG with additional links, and 1729 calculation of MRT transit next-hops alternate next-hops based on 1730 draft "draft-enyedi-rtgwg-mrt-frr-algorithm-03". This 1731 implementation also includes IS-IS extension for MRT based on 1732 "draft-li-mrt-00". 1734 o Licensing: proprietary 1736 o Implementation experience: It is important produce a second 1737 implementation to verify the algorithm is implemented correctly 1738 without looping. It is important to verify the ISIS extensions 1739 work for MRT-FRR. 1741 o Contact information: lizhenbin@huawei.com, eric.wu@huawei.com 1743 14. Operational Considerations 1745 The following aspects of MRT-FRR are useful to consider when 1746 deploying the technology in different operational environments and 1747 network topologies. 1749 14.1. Verifying Forwarding on MRT Paths 1751 The forwarding paths created by MRT-FRR are not used by normal (non- 1752 FRR) traffic. They are only used to carry FRR traffic for a short 1753 period of time after a failure has been detected. It is RECOMMENDED 1754 that an operator proactively monitor the MRT forwarding paths in 1755 order to be certain that the paths will be able to carry FRR traffic 1756 when needed. Therefore, an implementation SHOULD provide an operator 1757 with the ability to test MRT paths with OAM traffic. For example, 1758 when MRT paths are realized using LDP labels distributed for 1759 topology-scoped FECs, an implementation can use the MPLS ping and 1760 traceroute as defined in [RFC4379] and extended in [RFC7307] for 1761 topology-scoped FECs. 1763 14.2. Traffic Capacity on Backup Paths 1765 During a fast-reroute event initiated by a PLR in response to a 1766 network failure, the flow of traffic in the network will generally 1767 not be identical to the flow of traffic after the IGP forwarding 1768 state has converged, taking the failure into account. Therefore, 1769 even if a network has been engineered to have enough capacity on the 1770 appropriate links to carry all traffic after the IGP has converged 1771 after the failure, the network may still not have enough capacity on 1772 the appropriate links to carry the flow of traffic during a fast- 1773 reroute event. This can result in more traffic loss during the fast- 1774 reroute event than might otherwise be expected. 1776 Note that there are two somewhat distinct aspects to this phenomenon. 1777 The first is that the path from the PLR to the destination during the 1778 fast-reroute event may be different from the path after the IGP 1779 converges. In this case, any traffic for the destination that 1780 reaches the PLR during the fast-reroute event will follow a different 1781 path from the PLR to the destination than will be followed after IGP 1782 convergence. 1784 The second aspect is that the amount of traffic arriving at the PLR 1785 for affected destinations during the fast-reroute event may be larger 1786 than the amount of traffic arriving at the PLR for affected 1787 destinations after IGP convergence. Immediately after a failure, any 1788 non-PLR routers that were sending traffic to the PLR before the 1789 failure will continue sending traffic to the PLR, and that traffic 1790 will be carried over backup paths from the PLR to the destinations. 1791 After IGP convergence, upstream non-PLR routers may direct some 1792 traffic away from the PLR. 1794 In order to reduce or eliminate the potential for transient traffic 1795 loss due to inadequate capacity during fast-reroute events, an 1796 operator can model the amount of traffic taking different paths 1797 during a fast-reroute event. If it is determined that there is not 1798 enough capacity to support a given fast-reroute event, the operator 1799 can address the issue either by augmenting capacity on certain links 1800 or modifying the backup paths themselves. 1802 The MRT Lowpoint algorithm produces a pair of diverse paths to each 1803 destination. These paths are generated by following the directed 1804 links on a common GADAG. MRT-FRR allows an operator to exclude a 1805 link from the MRT Island, and thus the GADAG, by advertising it as 1806 MRT-Ineligible. Such a link will not be used on the MRT forwarding 1807 path for any destination. Advertising links as MRT-Ineligible is the 1808 main tool provided by MRT-FRR for keeping backup traffic off of lower 1809 bandwidth links during fast-reroute events. 1811 Note that all of the backup paths produced by the MRT Lowpoint 1812 algorithm are closely tied to the common GADAG computed as part of 1813 that algorithm. Therefore, it is generally not possible to modify a 1814 subset of paths without affecting other paths. This precludes more 1815 fine-grained modification of individual backup paths when using only 1816 paths computed by the MRT Lowpoint algorithm. 1818 However, it may be desirable to allow an operator to use MRT-FRR 1819 alternates together with alternates provided by other FRR 1820 technologies. A policy-based alternate selection process can allow 1821 an operator to select the best alternate from those provided by MRT 1822 and other FRR technologies. As a concrete example, it may be 1823 desirable to implement a policy where a downstream LFA (if it exists 1824 for a given failure mode and destination) is preferred over a given 1825 MRT alternate. This combination gives the operator the ability to 1826 affect where traffic flows during a fast-reroute event, while still 1827 producing backup paths that use no additional labels for LDP traffic 1828 and will not loop under multiple failures. This and other choices of 1829 alternate selection policy can be evaluated in the context of their 1830 effect on fast-reroute traffic flow and available capacity, as well 1831 as other deployment considerations. 1833 Note that future documents may define MRT profiles in addition to the 1834 default profile defined here. Different MRT profiles will generally 1835 produce alternate paths with different properties. An implementation 1836 may allow an operator to use different MRT profiles instead of or in 1837 addition to the default profile. 1839 14.3. MRT IP Tunnel Loopback Address Management 1841 As described in Section 6.1.2, if an implementation uses IP tunneling 1842 as the mechanism to realize MRT forwarding paths, each node must 1843 advertise an MRT-Red and an MRT-Blue loopback address. These IP 1844 addresses must be unique within the routing domain to the extent that 1845 they do not overlap with each other or with any other routing table 1846 entries. It is expected that operators will use existing tools and 1847 processes for managing infrastructure IP addresses to manage these 1848 additional MRT-related loopback addresses. 1850 14.4. MRT-FRR in a Network with Degraded Connectivity 1852 Ideally, routers is a service provider network using MRT-FRR will be 1853 initially deployed in a 2-connected topology, allowing MRT-FRR to 1854 find completely diverse paths to all destinations. However, a 1855 network can differ from an ideal 2-connected topology for many 1856 possible reasons, including network failures and planned maintenance 1857 events. 1859 MRT-FRR is designed to continue to function properly when network 1860 connectivity is degraded. When a network contains cut-vertices or 1861 cut-links dividing the network into different 2-connected blocks, 1862 MRT-FRR will continue to provide completely diverse paths for 1863 destinations within the same block as the PLR. For a destination in 1864 a different block from the PLR, the redundant paths created by MRT- 1865 FRR will be link and node diverse within each block, and the paths 1866 will only share links and nodes that are cut-links or cut-vertices in 1867 the topology. 1869 If a network becomes partitioned with one set of routers having no 1870 connectivity to another set of routers, MRT-FRR will function 1871 independently in each set of connected routers, providing redundant 1872 paths to destinations in same set of connected routers as a given 1873 PLR. 1875 14.5. Partial Deployment of MRT-FRR in a Network 1877 A network operator may choose to deploy MRT-FRR only on a subset of 1878 routers in an IGP area. MRT-FRR is designed to accommodate this 1879 partial deployment scenario. Only routers that advertise support for 1880 a given MRT profile will be included in a given MRT Island. For a 1881 PLR within the MRT Island, MRT-FRR will create redundant forwarding 1882 paths to all destinations with the MRT Island using maximally 1883 redundant trees all the way to those destinations. For destinations 1884 outside of the MRT Island, MRT-FRR creates paths to the destination 1885 which use forwarding state created by MRT-FRR within the MRT Island 1886 and shortest path forwarding state outside of the MRT Island. The 1887 paths created by MRT-FRR to non-Island destinations are guaranteed to 1888 be diverse within the MRT Island (if topologically possible). 1889 However, the part of the paths outside of the MRT Island may not be 1890 diverse. 1892 15. Acknowledgements 1894 The authors would like to thank Mike Shand for his valuable review 1895 and contributions. 1897 The authors would like to thank Joel Halpern, Hannes Gredler, Ted 1898 Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin 1899 Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, Bruno 1900 Decraene, Eric Wu, Janos Farkas, Rob Shakir, and Stewart Bryant for 1901 their suggestions and review. 1903 16. IANA Considerations 1905 IANA is requested to create a registry entitled "MRT Profile 1906 Identifier Registry". The range is 0 to 255. The Default MRT 1907 Profile defined in this document has value 0. Values 1-200 are 1908 allocated by Standards Action. Values 201-220 are for 1909 experimentation. Values 221-255 are for vendor private use. 1911 17. Security Considerations 1913 In general, MRT forwarding paths do not follow shortest paths. The 1914 transit forwarding state corresponding to the MRT paths is created 1915 during normal operations (before a failure occurs). Therefore, a 1916 malicious packet with an appropriate header injected into the network 1917 from a compromised location would be forwarded to a destination along 1918 a non-shortest path. When this technology is deployed, a network 1919 security design should not rely on assumptions about potentially 1920 malicious traffic only following shortest paths. 1922 It should be noted that the creation of non-shortest forwarding paths 1923 is not unique to MRT. 1925 MRT-FRR requires that routers advertise information used in the 1926 formation of MRT backup paths. While this document does not specify 1927 the protocol extensions used to advertise this information, we 1928 discuss security considerations related to the information itself. 1929 Injecting false MRT-related information could be used to direct some 1930 MRT backup paths over compromised transmission links. Combined with 1931 the ability to generate network failures, this could be used to send 1932 traffic over compromised transmission links during a fast-reroute 1933 event. In order to prevent this potential exploit, a receiving 1934 router needs to be able to authenticate MRT-related information that 1935 claims to have been advertised by another router. 1937 18. Contributors 1938 Robert Kebler 1939 Juniper Networks 1940 10 Technology Park Drive 1941 Westford, MA 01886 1942 USA 1943 Email: rkebler@juniper.net 1945 Andras Csaszar 1946 Ericsson 1947 Konyves Kalman krt 11 1948 Budapest 1097 1949 Hungary 1950 Email: Andras.Csaszar@ericsson.com 1952 Jeff Tantsura 1953 Ericsson 1954 300 Holger Way 1955 San Jose, CA 95134 1956 USA 1957 Email: jeff.tantsura@ericsson.com 1959 Russ White 1960 VCE 1961 Email: russw@riw.us 1963 19. References 1965 19.1. Normative References 1967 [I-D.ietf-rtgwg-mrt-frr-algorithm] 1968 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 1969 Gopalan, "Algorithms for computing Maximally Redundant 1970 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 1971 algorithm-06 (work in progress), October 2015. 1973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1974 Requirement Levels", BCP 14, RFC 2119, 1975 DOI 10.17487/RFC2119, March 1997, 1976 . 1978 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1979 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1980 DOI 10.17487/RFC5286, September 2008, 1981 . 1983 19.2. Informative References 1985 [EnyediThesis] 1986 Enyedi, G., "Novel Algorithms for IP Fast Reroute", 1987 Department of Telecommunications and Media Informatics, 1988 Budapest University of Technology and Economics Ph.D. 1989 Thesis, February 2011, 1990 . 1992 [I-D.atlas-rtgwg-mrt-mc-arch] 1993 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 1994 Envedi, "An Architecture for Multicast Protection Using 1995 Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- 1996 arch-02 (work in progress), July 2013. 1998 [I-D.francois-rtgwg-segment-routing-ti-lfa] 1999 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 2000 "Topology Independent Fast Reroute using Segment Routing", 2001 draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in 2002 progress), August 2015. 2004 [I-D.ietf-rtgwg-lfa-manageability] 2005 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 2006 Horneffer, M., and P. Sarkar, "Operational management of 2007 Loop Free Alternates", draft-ietf-rtgwg-lfa- 2008 manageability-11 (work in progress), June 2015. 2010 [I-D.ietf-rtgwg-rlfa-node-protection] 2011 Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S. 2012 Litkowski, "Remote-LFA Node Protection and Manageability", 2013 draft-ietf-rtgwg-rlfa-node-protection-05 (work in 2014 progress), December 2015. 2016 [LightweightNotVia] 2017 Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP 2018 Fast ReRoute: Lightweight Not-Via without Additional 2019 Addresses", Proceedings of IEEE INFOCOM , 2009, 2020 . 2022 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 2023 DOI 10.17487/RFC2328, April 1998, 2024 . 2026 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 2027 Label Switched (MPLS) Data Plane Failures", RFC 4379, 2028 DOI 10.17487/RFC4379, February 2006, 2029 . 2031 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 2032 Label Assignment and Context-Specific Label Space", 2033 RFC 5331, DOI 10.17487/RFC5331, August 2008, 2034 . 2036 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2037 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2038 . 2040 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 2041 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2042 2009, . 2044 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 2045 RFC 5714, DOI 10.17487/RFC5714, January 2010, 2046 . 2048 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 2049 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 2050 2010, . 2052 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 2053 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 2054 Alternate (LFA) Applicability in Service Provider (SP) 2055 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 2056 . 2058 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 2059 Francois, P., and O. Bonaventure, "Framework for Loop-Free 2060 Convergence Using the Ordered Forwarding Information Base 2061 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2062 2013, . 2064 [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP 2065 and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, 2066 DOI 10.17487/RFC6981, August 2013, 2067 . 2069 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2070 Code: The Implementation Status Section", RFC 6982, 2071 DOI 10.17487/RFC6982, July 2013, 2072 . 2074 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 2075 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 2076 DOI 10.17487/RFC6987, September 2013, 2077 . 2079 [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. 2080 King, "LDP Extensions for Multi-Topology", RFC 7307, 2081 DOI 10.17487/RFC7307, July 2014, 2082 . 2084 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 2085 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 2086 RFC 7490, DOI 10.17487/RFC7490, April 2015, 2087 . 2089 Appendix A. General Issues with Area Abstraction 2091 When a multi-homed prefix is connected in two different areas, it may 2092 be impractical to protect them without adding the complexity of 2093 explicit tunneling. This is also a problem for LFA and Remote-LFA. 2095 50 2096 |----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0: 2097 | | ABR 1, ABR 2, C, D 2098 | | 2099 | | Area 20: A, ASBR X 2100 | | 2101 p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y 2102 5 p is a Type 1 AS-external 2104 Figure 5: AS external prefixes in different areas 2106 Consider the network in Figure 5 and assume there is a richer 2107 connective topology that isn't shown, where the same prefix is 2108 announced by ASBR X and ASBR Y which are in different non-backbone 2109 areas. If the link from A to ASBR X fails, then an MRT alternate 2110 could forward the packet to ABR 1 and ABR 1 could forward it to D, 2111 but then D would find the shortest route is back via ABR 1 to Area 2112 20. This problem occurs because the routers, including the ABR, in 2113 one area are not yet aware of the failure in a different area. 2115 The only way to get it from A to ASBR Y is to explicitly tunnel it to 2116 ASBR Y. If the traffic is unlabeled or the appropriate MPLS labels 2117 are known, then explicit tunneling MAY be used as long as the 2118 shortest-path of the tunnel avoids the failure point. In that case, 2119 A must determine that it should use an explicit tunnel instead of an 2120 MRT alternate. 2122 Authors' Addresses 2124 Alia Atlas 2125 Juniper Networks 2126 10 Technology Park Drive 2127 Westford, MA 01886 2128 USA 2130 Email: akatlas@juniper.net 2132 Chris Bowers 2133 Juniper Networks 2134 1194 N. Mathilda Ave. 2135 Sunnyvale, CA 94089 2136 USA 2138 Email: cbowers@juniper.net 2140 Gabor Sandor Enyedi 2141 Ericsson 2142 Konyves Kalman krt 11. 2143 Budapest 1097 2144 Hungary 2146 Email: Gabor.Sandor.Enyedi@ericsson.com