idnits 2.17.1 draft-bryant-rtgwg-plfa-01.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 (December 22, 2020) is 1220 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R' is mentioned on line 554, but not defined == Missing Reference: 'F' is mentioned on line 554, but not defined == Missing Reference: 'C' is mentioned on line 554, but not defined == Missing Reference: 'G' is mentioned on line 554, but not defined == Missing Reference: 'E' is mentioned on line 551, but not defined == Missing Reference: 'D' is mentioned on line 551, but not defined == Missing Reference: 'J' is mentioned on line 551, but not defined == Missing Reference: 'A' is mentioned on line 557, but not defined == Missing Reference: 'B' is mentioned on line 557, but not defined == Missing Reference: 'H' is mentioned on line 557, but not defined == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-06 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Bryant 3 Internet-Draft S. Bryant 4 Intended status: Informational U. Chunduri 5 Expires: June 25, 2021 T. Eckert 6 Futurewei Technologies Inc 7 December 22, 2020 9 Preferred Path Loop-Free Alternate (pLFA) 10 draft-bryant-rtgwg-plfa-01 12 Abstract 14 Fast re-route (FRR) is a technique that allows productive forwarding 15 to continue in a network after a failure has occurred, but before the 16 network has has time to re-converge. This is achieved by forwarding 17 a packet on an alternate path that will not result in the packet 18 looping. Preferred Path Routing (PPR) provides a method of injecting 19 explicit paths into the routing protocol. The use of PPR to support 20 FRR has a number of advantages. This document describes the 21 advantages of using PPR to provide a loop-free alternate FRR path, 22 and provides a framework for its use in this application. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 25, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. A Note on the term IPFRR . . . . . . . . . . . . . . . . 3 60 2. PPR Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Preferred Path LFA (pLFA) Deployment Advantages . . . . . . . 4 62 4. Simple Repair Using pLFA . . . . . . . . . . . . . . . . . . 6 63 4.1. Link Repair . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Node Repair . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . 8 66 4.4. Local Area Networks . . . . . . . . . . . . . . . . . . . 9 67 4.5. Multiple Independent Failures . . . . . . . . . . . . . . 9 68 4.6. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . 9 69 4.7. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Repair To A Traffic Engineered Alternate Path . . . . . . . . 10 71 6. Use of a Repair Graph . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Single Repair Graph . . . . . . . . . . . . . . . . . . . 11 73 6.2. Multiple Disjoint Graphs . . . . . . . . . . . . . . . . 11 74 7. Centralized and Decentralized Approaches . . . . . . . . . . 13 75 8. Independence of operation . . . . . . . . . . . . . . . . . . 14 76 9. Data-plane Considerations . . . . . . . . . . . . . . . . . . 14 77 9.1. Traditional IP . . . . . . . . . . . . . . . . . . . . . 15 78 9.2. Segment Routing over an IPv6 Data Plane (SRv6) . . . . . 15 79 9.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. Loop Free Convergence . . . . . . . . . . . . . . . . . . . . 16 81 11. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 15.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 Preferred Path Routing (PPR) 93 [I-D.chunduri-lsr-isis-preferred-path-routing] is a method of 94 introducing explicit paths to a network. Such a path may be any 95 loop-free path between two points in the network that satisfies the 96 need for which the path was created. The PPR path is not constrained 97 to be the shortest path between any points in the network, although 98 the use of shortest path segments is provided for in order to 99 compress the size of the path description flooded by the routing 100 protocol. The advantages of PPR over alternate methods of creating 101 such paths is described in 102 [I-D.chunduri-lsr-isis-preferred-path-routing]. 104 A packet is carried over the network in an appropriate form using the 105 Preferred Path Routing Identifier (PPR-ID) as the data plane 106 identifier to map the packet to the PPR path, and hence the resources 107 and next-hop (NH). One way of adding a PPR-ID to a packet would be 108 to encapsulate it, but PPR does not restrict the user to the use of 109 encapsulation. How the PPR-ID is carried in the general case is 110 outside the scope of this document. Various methods of adding the 111 PPR-ID to a packet for the purposes of Fast-Reroute (FRR) are 112 described in Section 9. 114 IP Fast Re-route (IPFRR) Section 1.1 and the methods known at the 115 time of its writing is described in [RFC5714]. A number of later 116 methods are described in [RFC6981], [RFC7490], [RFC7812] and 117 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 119 This document is a framework describing various methods whereby PPR 120 can be used to provide IP Fast Reroute (IPFRR) paths. PPR can 121 provide IPFRR in a number of ways. 123 o Signaling pre-computed preferred alternatives for the primary path 124 o Signaling individual segments on the repair path. o Selective 125 overriding of locally computed Loop Free Alternates (LFA) for the NH 126 failure. o Local repair to a Traffic Engineered paths avoiding the 127 need for multi-hop Bidirectional Forwarding Detection (BFD) 128 [RFC5880]. o Micro-loop elimination [RFC5715]. 130 These are described in more detail within this memo. 132 1.1. A Note on the term IPFRR 134 The term IP fast re-route (IPFRR) was adopted by the IETF as the 135 general name for best-effort Fast Re-route (FRR) in best effort IP 136 and MPLS networks. This was to distinguish this new work from the 137 then established FRR as described in [RFC4090] which uses RSVP 138 Traffic Engineered (RSVP-TE) MPLS paths [RFC3936]. 140 Within this document the terms IPFRR and FRR are used 141 interchangeably. 143 2. PPR Overview 145 PPR works by injecting into the network a path or a graph and a 146 corresponding forwarding identifier (PPR-ID). A node examines each 147 PPR path description and if it is on the path it inserts into the 148 Forwarding Information Database (FIB) an entry for the PPR-ID with 149 the next hop as either the next entry along the PPR path, or if a 150 loose path is specified, the next hop on the shortest path to the 151 next hop along the PPR path. This is described in 152 [I-D.chunduri-lsr-isis-preferred-path-routing]. 154 PPR also has the ability to inject into a network a tree rooted at a 155 node identified a PPR-ID. This is described in 156 [I-D.ce-lsr-ppr-graph]. This graph mechanism provides a compact 157 representation of a set of paths to a given PPR-ID. This works in a 158 similar manner to the linear path case, in which a node on the graph 159 inserts a FIB entry for the PPR-ID with the next hop as either the 160 next node in the graph, or the next hop on the shortest path to the 161 next node in the graph. Clearly the graph needs to be a spanning 162 tree and must not contain a cycle. 164 In the description of the FRR methods provided in the text, the term 165 encapsulation (and decapsulation) is frequently used in connection 166 with the addition (and removal) of a PPR-ID to be used by the 167 forwarding later to identify to the forwarders the PPR path that the 168 packet needs to traverse to be follow the repair path. Encapsulation 169 is only one of a number of methods that can be used and is used in 170 this memo as a convenience without loss of generality. For more 171 information see Section 9. 173 3. Preferred Path LFA (pLFA) Deployment Advantages 175 PPR allows the construction of arbitrary engineered backup paths. In 176 this respect it is like similar to RSVP-TE and Topology Independent 177 Loop-Free Alternates (TI-LFA) 178 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. However, unlike those 179 approaches PPR is applicable to any forwarding plane. For example, 180 it is possible to support MPLS, both IPv4 and IPv6 and Ethernet. 182 Like Segment Routing (SR) [RFC8402], PPR uses extensions to the 183 existing IGP, however, unlike SR, PPR requires no extension to the 184 data plane. Again, unlike SR, which requires a Segment Identifier 185 (SID) in the network layer header for every non-shortest path 186 forwarding instruction, an arbitrary path does not require expansion 187 of the user data packet beyond that needed for the initial insertion 188 of the PPR-ID. This mitigates the MTU stress that SR introduces to 189 the network. 191 PPR based IPFRR supports 100% failure coverage similar to RSVP-TE 192 [RFC4090], TI-LFA, Maximally Redundant Trees (MRT) [RFC7812] and Not- 193 Via [RFC6981]. It does not have the coverage restrictions that apply 194 to Loop-Free Alternate (LFA) [RFC5286] and Remote LFA (RLFA) 195 [RFC7490]. 197 Shared Risk Link Groups (SRLGs) make it more difficult find repairs 198 in LFA and RLFA reducing repair coverage. TI-LFA can address this, 199 but only at a cost of expanding the number of SIDs and hence the 200 packet size. 202 Supporting multiple concurrent failures is difficult in all of the 203 IPRFF approaches except MRT, which can repair two concurrent 204 failures. However unlike MRT, which is constrained by its network 205 wide algorithm, PPR allows individual, arbitrary repair paths to 206 instantiated, for any failure. 208 In the current TI-LFA design, priority is given to repairing 209 connectivity rather than conforming to the operator traffic policy. 210 A PPR based FFR approach can apply policy to the repaired traffic, 211 including, if required multiple policies to an individual failure. 213 One of the main advantages of TI-LFA compared to other IPFRR 214 approaches is that it creates repair paths that are congruent with 215 the post convergence path from the Point of Local Repair (PLR) 216 [RFC4090] to the destination. These paths, which may be longer than 217 strictly necessary to reach Q-space [I-D.bryant-ipfrr-tunnels], stop 218 micro-loops from forming along the repair path during re-convergence. 219 PPR can also create these congruent paths without the need to 220 introduce SR into the network. 222 One of the limitations in TI-LFA, RLFA and LFA is that they do not 223 have a method of selectively creating alternative next-hops or indeed 224 full repair paths based on policy, or traffic engineering information 225 known to the operator. PPR provides a simple way to inject arbitrary 226 paths. It may therefore be used to enhance an existing LFA/RLFA/TI- 227 LFA IPFRR enabled network by selectively injecting paths to provide a 228 repair for business critical links with a policy in the PLR that 229 where provided a PPR path should be preferred over a local calculated 230 LFA based paths. 232 PPR is applicable to both centralized and PLR computed repair paths 233 each of which has advantages in different circumstances. A centrally 234 computed repair path only requires interaction with one network node 235 which then floods the instruction. This differs from the normal SDN 236 approach which requires interaction with all of the nodes along the 237 path and RSVP-TE which requires interaction with at least one end- 238 point of every repair. 240 Like TI-LFA, pLFA is based on a small extension to the IGP. It uses 241 the IGP flooding mechanism and in-built state maintenance and 242 consistency checks. This contrasts with RSVP-TE which needs its own 243 separate Signaling and soft-state maintenance method. 245 The requirement that the pLFA solution addresses is thus the ability 246 to construct repair paths that conform to operator policy without 247 data-plane changes or significant MTU increase, and without 248 introducing any control plane changes other than a small addition to 249 the existing IGP. 251 A more detailed technical comparison between pLFA and the existing 252 solutions is provided in the technical description of pLFA that 253 follows. 255 4. Simple Repair Using pLFA 257 4.1. Link Repair 259 In this, the most basic, scenario Figure 1 we assume that we have a 260 path A-B-C-D that the packet must traverse. This may be a normal 261 best effort path or a traffic engineered path. 263 c' 264 A---B--//--C---D 265 | | 266 E---F--G 267 f' 269 Figure 1: Simple IPFRR Using pLFA 271 PPR is used to inject the repair path B->E->F->G->C into the network 272 with a PPR-ID of c'. B is monitoring the health of link B->C, for 273 example looking for loss-of-light, or using Bidirectional Forwarding 274 Detection (BFD) [RFC5880]. When B detects a failure it encapsulates 275 the packet to C by adding to the packet the PPR-ID for c' and sending 276 it to E. At C the packet is decapsulated and sent to D. The path 277 C->E->F->G->C may be a traffic engineered path or it may be a best 278 effort path. B may have at its disposal multiple paths to C with 279 different properties for different traffic classes. In this case 280 each path to be used would require its own PPR-ID (c', c'' etc). 282 In some circumstances, the repair path may be terminated at another 283 point in Q-space or at a node between C and D. For example, in 284 Figure 1 if all costs are 1, F is in Q-space with respect to a B->C 285 failure (F->G->C cost = 2, whilst F->E->B->C cost = 3) and thus the 286 packet can safely be encapsulated and send to F with a PPR-ID of f'. 287 Releasing the packet early in Q-space has two advantages, firstly the 288 packet can take a shorter path to its destination if one is available 289 rather than traveling to the far side of the failure and then back 290 tracking. 292 Releasing a packet in Q-space also reduces the size of the PPR path 293 that needs to be advertised, and potentially allows a repair path to 294 be shared among a number of failures. For example in Figure 2 G with 295 PPR-ID g' via B->E->F->G can be used to provide an IPFRR path for the 296 failure of both B->C and B->H. 298 c' 299 A---B--//--C---D 300 |\ | 301 | H--+ | 302 | \| 303 E---F--G 304 g' 306 Figure 2: Simple IPFRR Using pLFA With Shared Repair 308 Shared paths are useful in reducing the number of PPR paths that need 309 to be flooded to support FRR. 311 Note that where the packet takes the shortest path to the point in 312 Q-space that is closest to the destination, it will be taking a path 313 that is congruent with the post convergence path from the PLR to the 314 destination. This is the path that TI-LFA chooses to avoid its loop- 315 free convergence. However this is not the only loop-free strategy 316 available to a pLFA based solution. 318 4.2. Node Repair 320 Consider the network fragment shown in Figure 3 taken from 321 [I-D.bryant-ipfrr-tunnels], and consider that node A needs to deal 322 with the possible failure of node E. 324 Repair S-E 325 +----------------+ 326 | | 327 | Repair S-S s1'| 328 |+---------->[S1]| 329 || | / 330 || | / 331 || |/e' s2' 332 ----->[S]----//-----[E]---------[S2] 333 || | ^ 334 || | | 335 ||Repair S-S3 | | 336 |+---------->[S3] | 337 | s3' | 338 +-------------------------+ 339 Repair S-S2 341 Figure 3: Simple IPFRR - Node Failure 343 Node S needs the use of four repair paths to address the failure of 344 node E, one repair to each of E's neighbours for which E is on the 345 path to that neighbour. In Figure 3 there are three of these next- 346 next-hop repairs, noted as Repair S-Sx in the figure. In addition a 347 repair to E (Repair S->E) using a path other than along the path S-E> 348 should be installed for traffic to E on the basis that the problem 349 may be a failure of link S->E rather than a failure of the node. 351 The three repair paths to the next-next-hops of E can be installed as 352 PPR path S-Sx with a PPR-ID of sx'. The link repair for E a PPR path 353 to E which avoids link S-E with a PPR-ID of e'. 355 4.3. Shared Risk Link Groups 357 A shared risk link group (SRLG) is a set of links that are believed 358 to have some systematic connection such that when one fails there is 359 a high probability of all of them failing. This occurs, for example, 360 where all of the members of the group run in a common cable duct. 361 Where this relationship is known, and the simultaneous failure does 362 not partition the network,PPR can install paths such that all members 363 of the SRLG are avoided. pLFA has fewer constraints than other 364 methods in constructing arbitrary repair paths in the network. 365 [RFC6981] Section 6.1 describes the SRLG problem as it applies to 366 IPFRR. pLFA can address all of the cases described in [RFC6981]. 368 SRLG avoiding IPFRR paths can be complex. Since a packet can be 369 attracted towards the failure whenever it is released from a strict 370 path, the repair path may need a number of segments to steer it 371 safely into Q-space. If this is done in the data-plane this can 372 stress the MTU. pLFA creates the path in the control plane and its 373 encapsulation is invariant with respect to the complexity of the 374 path. Furthermore, if the need to reduce the data-plane 375 encapsulation side means that the repair path needs to use a sequence 376 of loose hops it is necessary to determine the behaviour of each 377 router on the chosen path. This contrasts with pLFA which can 378 determine the path using whatever metrics and policy is appropriate, 379 and then simply impose it without any data-plane overhead beyond that 380 needed for a simple repair. 382 4.4. Local Area Networks 384 LANs are a special type of SRLG and are solved using the SRLG 385 mechanisms outlined above. With all SRLGs, there is a trade-off 386 between the sophistication of the fault detection and the size of the 387 SRLG. [RFC6981] Section 6.2 describes the LAN problem as it applies 388 to IPFRR. pLFA can address all of the cases described in [RFC6981]. 390 4.5. Multiple Independent Failures 392 The Multiple Independent Failure cases described in [RFC6981] 393 Section 6.3 will be analyzed in a future version of this document. 395 4.6. Multi-homed Prefixes 397 The Multi-Homed Prefix (MHP) problem is described in [RFC5286] 398 Section 6.1, [RFC6981] Section 5.3 and [RFC8518]. MHP will be 399 addressed in a future version of this document. 401 4.7. ECMP 403 Equal Cost Multi-Path (ECMP) is a consideration in any IPFRR method 404 that does not use strict paths, and can be both an opportunity and 405 threat. It is an opportunity in that it allows for the repair 406 traffic to be distributed over a number of alternative paths to 407 minimize congestion. If a loose pLFA path is injected into the 408 network, then any available ECMP paths that fulfill the PPR path 409 constraints can be installed following the same procedure used in 410 normal IGP path computation. 412 However, care must be taken that a packet is not in a position where 413 it is released from a repair at an ECMP point such that one of the 414 ECMP paths is back via the failure. This can never happen if the 415 correct definition of Q-space [RFC7490] is used in calculating the 416 repair path. 418 5. Repair To A Traffic Engineered Alternate Path 420 In this approach there are two traffic engineered paths from A to D 421 (Figure 4. 423 d' 424 A-??-B--??--C--??-D 425 | | | | 426 E----F------G-----+ 428 Figure 4: Traffic Engineered IPFRR Using pLFA 430 The primary path A->B->C->D is protected by a traffic engineered path 431 A->F->G->D (PPR-ID d') with traffic engineered connectors from B 432 (B->F) and C (C->G). The path A->F->G->D and its connectors can be 433 created and injected by any node with access to the IGP, but it is 434 more likely to be created by a traffic engineering controller. 436 If link B->C fails, B re-routes packets destined for D to the traffic 437 engineered path A->F->G->D via connector B->F. It does this by 438 encapsulating the packet with a PPR-ID of d'. 440 Clearly there is nothing special needed to get the packet from B to F 441 as they are adjacent but if there is a node say X on the path from B 442 to F an explicit path needs to be created from B to F via X. 443 Normally the repair would be created as a single PPR path (i.e. 444 B->F->G->D) with a PPR-ID of d'. In this approach the repair from A 445 would be A->F->G->D with a PPR-ID of d' also. Similarly C-G-D would 446 again share the PPR-ID d'. 448 If preferred the repair path could also be constructed using double 449 encapsulation or using an SR approach in which the first segment was 450 B-F with a PPR-ID/SID f' and the second segment was F-D with PPR-ID 451 of d'. 453 In the example shown in Figure 4 the proposed B-//->C protection path 454 was B->F->G->D. This is node protecting on C since the repair path 455 avoids C. Although link failures tend to be more common than node 456 failures some critical applications would prefer node protection 457 where possible. Node avoidance may not be possible within the 458 network, and may come at a cost of increased path repair path length. 459 However, whether to include node protection and as what cost to 460 accept its inclusion is a matter of network operator policy. 462 The repair constructed in this section required the inclusion of a 463 set of PPR defined links to construct the repair. PPR has the 464 ability to construct graphs [I-D.ce-lsr-ppr-graph] which can simplify 465 the specification of the required repair topology. This is discussed 466 in Section 6. 468 6. Use of a Repair Graph 470 PPR has the ability to inject graphs into a network as well as linear 471 paths [I-D.ce-lsr-ppr-graph]. PPR graphs specify the paths from a 472 set of nodes to a single node, and are a compact method of 473 representing a set of paths to that destination with shared 474 properties. 476 6.1. Single Repair Graph 478 In [I-D.ce-lsr-ppr-graph] the S bit in the PPR Path Description 479 Element (PDE) specifies that a a network node is a Source and a D bit 480 specifies that it is a destination. A graph with all S bits set on 481 the leaves and a D bit on the root is a unidirectional tree. 483 d' 484 S S S D 485 A-??-B--??--C--??-D 486 | | | | 487 E----F------G-----+ 489 Figure 5: pLFA using PPR Graphs 491 Consider the network fragment shown in Figure 5. A graph with a PPR- 492 ID d' is constructed attaching each of the nodes A, B, and C to D. 493 Should any of the nodes A, B or C fail the packet can be forwarded on 494 the PPR graph to D with the PPR-ID of d'. In the unidirectional 495 repair graph A, B, and C are all sources (signaled with the S bit 496 set), and D is the only destination (signaled with the D bit set. 498 6.2. Multiple Disjoint Graphs 500 Consider Figure 1 from [RFC7812] which illustrates the problem of 501 IPFRR in a network that is 2-connected. 503 [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| 504 | | | | ^ | | | 505 | | | V | | V V 506 [R] [F] [C] r'[R] [F] [C] r''[R] [F] [C] 507 | | | ^ ^ ^ | | 508 | | | | | | V | 509 [A]---[B]---| [A]-->[B]---| [A]<--[B]<--| 511 (a) (b) (c) 512 a 2-connected graph Blue Tree towards R Red Tree towards R 514 Figure 6: A 2-Connected Network 516 Figure 6(a) is the full network, and Figure 6(b) and (b) are two 517 corresponding redundant trees from [RFC7812]. Using the Red and Blue 518 trees towards R every node has at least two paths to R. We give R a 519 PPR-ID of r' in the Blue tree and a PPR-ID of r'' in the Red tree. R 520 is the only destination in the PPR graph (D bit set), but all other 521 nodes are sources (S bit set). For clarity this bit setting is not 522 shown in Figure 6. 524 It is worth noting what happens at nodes B and D in Figure 6(b). B 525 is an ECMP to D via F and C. What happens at node B is a matter of 526 implementation and operator preference. Either B can choose one of 527 the next-hops, or it use them as an ECMP pair. It can also use the 528 availability of the pair to protect against B->F or B->C being an 529 unexpected SRLG with respect to link A->R. D is a merge point for 530 traffic destined for r' arriving from F and from C. It simply 531 forwards the traffic to r' as normal. Similarly in Figure 6(c) D can 532 sent traffic to r'' via F or C. 534 Whilst in this example the Red and Blue trees use exactly the same 535 links and nodes used by the main topology, a repair graph could use 536 available nodes and links outside this network fragment. 538 Now consider Figure 2 from [RFC7812] which illustrates the problem of 539 IPFRR in a network that is not 2-connected. 541 [E]---[D]---| |---[J] 542 | | | | | 543 | | | | | 544 [R] [F] [C]---[G] | 545 | | | | | 546 | | | | | 547 [A]---[B]---| |---[H] 549 (a) a graph that is not 2-connected 551 [E]<--[D]<--| [J] [E]-->[D]---| |---[J] 552 | ^ | | | | | ^ 553 V | | | r'' V V V | 554 [R] [F] [C]<--[G] | [R] [F] [C]<--[G] | 555 r' ^ ^ ^ | ^ | | | 556 | | | V | V | | 557 [A]-->[B]---| |---[H] [A]<--[B]<--| [H] 559 (b) Blue Tree towards R (c) Red Tree towards R 561 Figure 7: A Network That Is Not 2-Connected 563 Again there are two paths (with PPR-IDs r' and r'') to R from all 564 nodes except that G, J and H all depend on link G->C and node C which 565 is a single point of failure in the network. 567 Again note that B in the Blue tree and D in the Red tree has two 568 paths to r' and r'' respectively that it may use according to 569 configuration or preference. 571 7. Centralized and Decentralized Approaches 573 pLFA paths can be established through both centralized and 574 decentralized approaches. 576 A centralized system has a more holistic view of the network and its 577 policies, its resource constraints and resource usage. A 578 decentralized system is inherently more resilient to failure and is a 579 good fit where the network is a simple best effort network as is 580 commonly deployed. 582 A centralized system gathers the network state, just as any SDN 583 system does, and computes the FRR paths needed. However, unlike 584 normal SDN operation where the controller needs to individually 585 instruct every entity on the path for every path, in a PPR network it 586 is only necessary to inject the PPR path at one point. In practice, 587 for reliability, it would inject the PPR paths in a small number of 588 places, and the naturally reliability of the IGP would ensure the 589 complete distribution of the paths. Furthermore, the system 590 collecting the network state would naturally send the PPR LSPs back 591 to the SDN controller providing quality assurance that the FRR paths 592 had been distributed. 594 In a decentralized approach the pLFA path is computed within the 595 network, normally by the PLR. Further details of this approach will 596 be provided in a future version of this document. 598 8. Independence of operation 600 Each PPR path is independent of all other paths in the network. This 601 means that there is no constraint on how the path is calculated, and 602 a different algorithm can be used on every path. Some of the other 603 FRR approaches have this property, but not all. For example LFA is 604 constrained by the properties of the base IGP as to a large degree is 605 RLFA. PPR can incorporate best effort segments if required, but from 606 a data-plane perspective there is no advantage in doing so. In this 607 case there is a dependence on the path choice in the base routing 608 protocol. 610 MRT and Not-Via can use any algorithm to calculate the repair, but it 611 needs to be common across the network, although the expectation in 612 the case of Not-Via is that the algorithm would be a Dijkstra based 613 SPF calculation. In both these cases to change the algorithm would 614 require turning off FRR for the whole network, re-configuring and 615 then restarting FRR. 617 RSVP-TE based FRR can specify any path, but at the cost of 618 maintaining the soft-state. 620 A PLR in a TI-LFA or any SR based approach can also compute paths 621 independent of each other, but they tend to need to do this as a 622 concatenation of a series of shortest paths in order to reduce the 623 number of SIDs they need to form the path. TI-LFA is thus highly 624 dependent on the underlying best effort paths. 626 pLFA can be used as a method of converting classic LFA or RLFA to 627 full coverage by providing the paths that these methods are unable to 628 support, or to provide any the sub-paths needed to reduce the number 629 of TI-LFA SIDs. 631 9. Data-plane Considerations 633 This section is a survey of a number of data-planes in each case 634 considering how a PPR-ID could added to map the packet to required 635 FRR path. 637 9.1. Traditional IP 639 Where the data-plane is "traditional" IP the user packet needs to be 640 encapsulated such that the outer IP address is the PPR-ID. Any 641 preferred encapsulation can be used such as: IP in IP, IP in GRE, or 642 IP in UDP. 644 The tunnel capabilities of a node can be advertised using the method 645 described in [I-D.xu-isis-encapsulation-cap] allowing different 646 tunnel types to be used for different PPR paths, depending on the 647 capability of the various nodes in the network. 649 A common operational issue with this type of encapsulation for IPFRR 650 has been the shortage of IP addresses. However this is not an issue 651 in an IPv6 network. 653 9.2. Segment Routing over an IPv6 Data Plane (SRv6) 655 Where the data-plane is SRv6 [I-D.ietf-6man-segment-routing-header] 656 pLFA would be used to steer a packet towards the next segment end- 657 point. Clearly an extra level of IP encapsulation could be used 658 Section 9.1, but that expands the packet by adding at least 36 659 octets. 661 Where the packet is a "traditional" IP packet, and the repair end- 662 point is SRv6 capable, an alternative to the methods described in 663 Section 9.1 is to insert an SRH into the IP packet setting the SID in 664 the SRH to the original packet DA and replacing the outer DA with the 665 PPR-ID. If this method is used the semantics of the PPR-ID must 666 include the reconstruction of the packet, by replacing the DA with 667 the original DA retrieved from the SRH and the removal of the SRH. 669 9.3. MPLS 671 Where the data-plane is MPLS any encapsulation needed is tiny (a 672 label push), but the exact action depends on the repair strategy, and 673 there is the usual FRR problem of the setting of the new value for 674 the top label prior to pushing the PPR-ID label. 676 Where the FRR path terminates at an MPLS node other than the network 677 egress provider edge (PE) in the type of pLFA repair described in 678 Section 4, the original top label needed to be set to the label the 679 node was expecting. 681 Consider the network fragment shown in Figure 1. This is straight 682 forward case because node B swaps the top label the label it would 683 have used without the failure and then pushes the label that 684 corresponds to c'. If the repair strategy had been to exit Q-space 685 at the earliest opportunity for example at F, then B would have 686 needed to know what label F required to reach the destination. A 687 very similar problem occurs when a node repair is undertaken 688 Figure 3, where S needs to know the label that the next-next-hops 689 (S1, S2 and S3) need to reach the destination. 691 Where the traffic is being moved to a new path terminating at the 692 egress PE as shown in Figure 4, the problem much simpler and only 693 requires the swapping of the top label with the label that represents 694 d'. 696 10. Loop Free Convergence 698 Whilst IPFRR puts in place a temporary network repair, eventually the 699 network needs to re-converge around the surviving network components. 700 During this phase there is a danger that micro-loops will form and 701 disrupt the traffic flowing across the network. A similar problem 702 can occur when the failed component returns to service, or when a new 703 component is introduced into the network. [RFC5715] describes the 704 problem of loop-free convergence in detail and examines the methods 705 known at the time of its writing. Since that time [RFC8333] has 706 proposed a timer based loop mitigation (but not elimination) process, 707 and [I-D.ietf-rtgwg-segment-routing-ti-lfa] has proposed that by 708 making the IPFRR path congruent with the post convergence path loops 709 can be eliminated along the repair path. However whilst these 710 mitigation techniques address component failure, neither are targeted 711 at the repair/new component case. 713 These problems only effect best effort paths and path segments, fully 714 defined paths do not have this problem. 716 A network using pLFA is compatible with all of the know loop-free 717 convergence and loop mitigation approaches. 719 11. OAM Considerations 721 PPR may also be used in a way that provides an alternative to running 722 multi-hop BFD from ingress on a traffic engineered (TE) path with 723 reducing the complexities that arise from echo reply false alarms. 724 In this use case pLFA works by locally detecting the failure and 725 transferring the traffic to preferred TE backups which are in time 726 replaced by the newly computed TE paths to the same PPR-ID. 728 12. Privacy Considerations 730 As noted in Section 13 pLFA paths are constrained by the routing 731 domain and thus the traffic will be no more subject to observation 732 than it would in normal operation. Indeed PPR has the capability to 733 constrain the path of the traffic more tightly than other IPFRR 734 approaches. pLFA therefore does not reduce the privacy of user 735 traffic on the network. 737 13. Security Considerations 739 The security considerations of PPR are discussed in 740 [I-D.chunduri-lsr-isis-preferred-path-routing] which in turn refers 741 the reader to the security considerations of the underlying routing 742 protocol and the data-plane in use. The pLFA application of PPR to 743 IPFRR introduces no additional security regarding PPR itself. 745 General IPFRR security considerations are discussed in [RFC5714] and 746 these apply to this solution. 748 One further consideration, is the whether policy that applied to the 749 original path needs to be applied to the repair path. The decision 750 is operator and application specific, however pLFA is better than 751 some other IPFRR solution in that it is possible to precisely choose 752 the repair path. 754 IPFRR is deployed within the scope of the routing protocol that 755 underpins it which limits the security vulnerability. Furthermore it 756 is unlikely that IPFRR would be deployed outside a well managed 757 network. These restrictions in-turn significantly mitigate any 758 security threat. 760 14. IANA Considerations 762 This document makes no IANA requests. 764 15. References 766 15.1. Normative References 768 [I-D.ce-lsr-ppr-graph] 769 Chunduri, U. and T. Eckert, "Preferred Path Route Graph 770 Structure", draft-ce-lsr-ppr-graph-04 (work in progress), 771 September 2020. 773 [I-D.chunduri-lsr-isis-preferred-path-routing] 774 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 775 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 776 draft-chunduri-lsr-isis-preferred-path-routing-06 (work in 777 progress), September 2020. 779 15.2. Informative References 781 [I-D.bryant-ipfrr-tunnels] 782 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 783 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 784 (work in progress), November 2007. 786 [I-D.ietf-6man-segment-routing-header] 787 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 788 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 789 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 790 progress), October 2019. 792 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 793 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 794 and D. Voyer, "Topology Independent Fast Reroute using 795 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 796 lfa-05 (work in progress), November 2020. 798 [I-D.xu-isis-encapsulation-cap] 799 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 800 L., and L. Jalil, "Advertising Tunnelling Capability in 801 IS-IS", draft-xu-isis-encapsulation-cap-07 (work in 802 progress), October 2016. 804 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 805 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 806 DOI 10.17487/RFC3936, October 2004, 807 . 809 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 810 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 811 DOI 10.17487/RFC4090, May 2005, 812 . 814 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 815 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 816 DOI 10.17487/RFC5286, September 2008, 817 . 819 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 820 RFC 5714, DOI 10.17487/RFC5714, January 2010, 821 . 823 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 824 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 825 2010, . 827 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 828 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 829 . 831 [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP 832 and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, 833 DOI 10.17487/RFC6981, August 2013, 834 . 836 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 837 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 838 RFC 7490, DOI 10.17487/RFC7490, April 2015, 839 . 841 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 842 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 843 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 844 . 846 [RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P. 847 Francois, "Micro-loop Prevention by Introducing a Local 848 Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 849 2018, . 851 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 852 Decraene, B., Litkowski, S., and R. Shakir, "Segment 853 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 854 July 2018, . 856 [RFC8518] Sarkar, P., Ed., Chunduri, U., Ed., Hegde, S., Tantsura, 857 J., and H. Gredler, "Selection of Loop-Free Alternates for 858 Multi-Homed Prefixes", RFC 8518, DOI 10.17487/RFC8518, 859 March 2019, . 861 Authors' Addresses 863 Stewart Bryant 864 Futurewei Technologies Inc 866 Email: stewart.bryant@gmail.com 868 Stewart Bryant 869 Futurewei Technologies Inc 871 Email: sb@stewartbryant.com 872 Uma Chunduri 873 Futurewei Technologies Inc 875 Email: uchundur@futurewei.com 877 Toerless Eckert 878 Futurewei Technologies Inc 880 Email: tte+ietf@cs.fau.de