idnits 2.17.1 draft-bryant-rtgwg-plfa-03.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 24, 2021) is 854 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R' is mentioned on line 555, but not defined == Missing Reference: 'F' is mentioned on line 555, but not defined == Missing Reference: 'C' is mentioned on line 555, but not defined == Missing Reference: 'G' is mentioned on line 555, but not defined == Missing Reference: 'E' is mentioned on line 552, but not defined == Missing Reference: 'D' is mentioned on line 552, but not defined == Missing Reference: 'J' is mentioned on line 552, but not defined == Missing Reference: 'A' is mentioned on line 558, but not defined == Missing Reference: 'B' is mentioned on line 558, but not defined == Missing Reference: 'H' is mentioned on line 558, but not defined == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-07 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 University of Surrey 4 Intended status: Informational U. Chunduri 5 Expires: June 27, 2022 Intel 6 T. Eckert 7 Futurewei Technologies Inc 8 December 24, 2021 10 Preferred Path Loop-Free Alternate (pLFA) 11 draft-bryant-rtgwg-plfa-03 13 Abstract 15 Fast re-route (FRR) is a technique that allows productive forwarding 16 to continue in a network after a failure has occurred, but before the 17 network has has time to re-converge. This is achieved by forwarding 18 a packet on an alternate path that will not result in the packet 19 looping. Preferred Path Routing (PPR) provides a method of injecting 20 explicit paths into the routing protocol. The use of PPR to support 21 FRR has a number of advantages. This document describes the 22 advantages of using PPR to provide a loop-free alternate FRR path, 23 and provides a framework for its use in this application. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 27, 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. A Note on the term IPFRR . . . . . . . . . . . . . . . . 3 61 2. PPR Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Preferred Path LFA (pLFA) Deployment Advantages . . . . . . . 4 63 4. Simple Repair Using pLFA . . . . . . . . . . . . . . . . . . 6 64 4.1. Link Repair . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Node Repair . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . 8 67 4.4. Local Area Networks . . . . . . . . . . . . . . . . . . . 9 68 4.5. Multiple Independent Failures . . . . . . . . . . . . . . 9 69 4.6. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . 9 70 4.7. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Repair To A Traffic Engineered Alternate Path . . . . . . . . 10 72 6. Use of a Repair Graph . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Single Repair Graph . . . . . . . . . . . . . . . . . . . 11 74 6.2. Multiple Disjoint Graphs . . . . . . . . . . . . . . . . 11 75 7. Centralized and Decentralized Approaches . . . . . . . . . . 13 76 8. Independence of operation . . . . . . . . . . . . . . . . . . 14 77 9. Data-plane Considerations . . . . . . . . . . . . . . . . . . 14 78 9.1. Traditional IP . . . . . . . . . . . . . . . . . . . . . 15 79 9.2. Segment Routing over an IPv6 Data Plane (SRv6) . . . . . 15 80 9.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. Loop Free Convergence . . . . . . . . . . . . . . . . . . . . 16 82 11. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 84 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 15.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Preferred Path Routing (PPR) 94 [I-D.chunduri-lsr-isis-preferred-path-routing] is a method of 95 introducing explicit paths to a network. Such a path may be any 96 loop-free path between two points in the network that satisfies the 97 need for which the path was created. The PPR path is not constrained 98 to be the shortest path between any points in the network, although 99 the use of shortest path segments is provided for in order to 100 compress the size of the path description flooded by the routing 101 protocol. The advantages of PPR over alternate methods of creating 102 such paths is described in 103 [I-D.chunduri-lsr-isis-preferred-path-routing]. 105 A packet is carried over the network in an appropriate form using the 106 Preferred Path Routing Identifier (PPR-ID) as the data plane 107 identifier to map the packet to the PPR path, and hence the resources 108 and next-hop (NH). One way of adding a PPR-ID to a packet would be 109 to encapsulate it, but PPR does not restrict the user to the use of 110 encapsulation. How the PPR-ID is carried in the general case is 111 outside the scope of this document. Various methods of adding the 112 PPR-ID to a packet for the purposes of Fast-Reroute (FRR) are 113 described in Section 9. 115 IP Fast Re-route (IPFRR) Section 1.1 and the methods known at the 116 time of its writing is described in [RFC5714]. A number of later 117 methods are described in [RFC6981], [RFC7490], [RFC7812] and 118 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 120 This document is a framework describing various methods whereby PPR 121 can be used to provide IP Fast Reroute (IPFRR) paths. PPR can 122 provide IPFRR in a number of ways. 124 o Signaling pre-computed preferred alternatives for the primary path 125 o Signaling individual segments on the repair path. o Selective 126 overriding of locally computed Loop Free Alternates (LFA) for the NH 127 failure. o Local repair to a Traffic Engineered paths avoiding the 128 need for multi-hop Bidirectional Forwarding Detection (BFD) 129 [RFC5880]. o Micro-loop elimination [RFC5715]. 131 These are described in more detail within this memo. 133 1.1. A Note on the term IPFRR 135 The term IP fast re-route (IPFRR) was adopted by the IETF as the 136 general name for best-effort Fast Re-route (FRR) in best effort IP 137 and MPLS networks. This was to distinguish this new work from the 138 then established FRR as described in [RFC4090] which uses RSVP 139 Traffic Engineered (RSVP-TE) MPLS paths [RFC3936]. 141 Within this document the terms IPFRR and FRR are used 142 interchangeably. 144 2. PPR Overview 146 PPR works by injecting into the network a path or a graph and a 147 corresponding forwarding identifier (PPR-ID). A node examines each 148 PPR path description and if it is on the path it inserts into the 149 Forwarding Information Database (FIB) an entry for the PPR-ID with 150 the next hop as either the next entry along the PPR path, or if a 151 loose path is specified, the next hop on the shortest path to the 152 next hop along the PPR path. This is described in 153 [I-D.chunduri-lsr-isis-preferred-path-routing]. 155 PPR also has the ability to inject into a network a tree rooted at a 156 node identified a PPR-ID. This is described in 157 [I-D.ce-lsr-ppr-graph]. This graph mechanism provides a compact 158 representation of a set of paths to a given PPR-ID. This works in a 159 similar manner to the linear path case, in which a node on the graph 160 inserts a FIB entry for the PPR-ID with the next hop as either the 161 next node in the graph, or the next hop on the shortest path to the 162 next node in the graph. Clearly the graph needs to be a spanning 163 tree and must not contain a cycle. 165 In the description of the FRR methods provided in the text, the term 166 encapsulation (and decapsulation) is frequently used in connection 167 with the addition (and removal) of a PPR-ID to be used by the 168 forwarding later to identify to the forwarders the PPR path that the 169 packet needs to traverse to be follow the repair path. Encapsulation 170 is only one of a number of methods that can be used and is used in 171 this memo as a convenience without loss of generality. For more 172 information see Section 9. 174 3. Preferred Path LFA (pLFA) Deployment Advantages 176 PPR allows the construction of arbitrary engineered backup paths. In 177 this respect it is like similar to RSVP-TE and Topology Independent 178 Loop-Free Alternates (TI-LFA) 179 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. However, unlike those 180 approaches PPR is applicable to any forwarding plane. For example, 181 it is possible to support MPLS, both IPv4 and IPv6 and Ethernet. 183 Like Segment Routing (SR) [RFC8402], PPR uses extensions to the 184 existing IGP, however, unlike SR, PPR requires no extension to the 185 data plane. Again, unlike SR, which requires a Segment Identifier 186 (SID) in the network layer header for every non-shortest path 187 forwarding instruction, an arbitrary path does not require expansion 188 of the user data packet beyond that needed for the initial insertion 189 of the PPR-ID. This mitigates the MTU stress that SR introduces to 190 the network. 192 PPR based IPFRR supports 100% failure coverage similar to RSVP-TE 193 [RFC4090], TI-LFA, Maximally Redundant Trees (MRT) [RFC7812] and Not- 194 Via [RFC6981]. It does not have the coverage restrictions that apply 195 to Loop-Free Alternate (LFA) [RFC5286] and Remote LFA (RLFA) 196 [RFC7490]. 198 Shared Risk Link Groups (SRLGs) make it more difficult find repairs 199 in LFA and RLFA reducing repair coverage. TI-LFA can address this, 200 but only at a cost of expanding the number of SIDs and hence the 201 packet size. 203 Supporting multiple concurrent failures is difficult in all of the 204 IPRFF approaches except MRT, which can repair two concurrent 205 failures. However unlike MRT, which is constrained by its network 206 wide algorithm, PPR allows individual, arbitrary repair paths to 207 instantiated, for any failure. 209 In the current TI-LFA design, priority is given to repairing 210 connectivity rather than conforming to the operator traffic policy. 211 A PPR based FFR approach can apply policy to the repaired traffic, 212 including, if required multiple policies to an individual failure. 214 One of the main advantages of TI-LFA compared to other IPFRR 215 approaches is that it creates repair paths that are congruent with 216 the post convergence path from the Point of Local Repair (PLR) 217 [RFC4090] to the destination. These paths, which may be longer than 218 strictly necessary to reach Q-space [I-D.bryant-ipfrr-tunnels], stop 219 micro-loops from forming along the repair path during re-convergence. 220 PPR can also create these congruent paths without the need to 221 introduce SR into the network. 223 One of the limitations in TI-LFA, RLFA and LFA is that they do not 224 have a method of selectively creating alternative next-hops or indeed 225 full repair paths based on policy, or traffic engineering information 226 known to the operator. PPR provides a simple way to inject arbitrary 227 paths. It may therefore be used to enhance an existing LFA/RLFA/TI- 228 LFA IPFRR enabled network by selectively injecting paths to provide a 229 repair for business critical links with a policy in the PLR that 230 where provided a PPR path should be preferred over a local calculated 231 LFA based paths. 233 PPR is applicable to both centralized and PLR computed repair paths 234 each of which has advantages in different circumstances. A centrally 235 computed repair path only requires interaction with one network node 236 which then floods the instruction. This differs from the normal SDN 237 approach which requires interaction with all of the nodes along the 238 path and RSVP-TE which requires interaction with at least one end- 239 point of every repair. 241 Like TI-LFA, pLFA is based on a small extension to the IGP. It uses 242 the IGP flooding mechanism and in-built state maintenance and 243 consistency checks. This contrasts with RSVP-TE which needs its own 244 separate Signaling and soft-state maintenance method. 246 The requirement that the pLFA solution addresses is thus the ability 247 to construct repair paths that conform to operator policy without 248 data-plane changes or significant MTU increase, and without 249 introducing any control plane changes other than a small addition to 250 the existing IGP. 252 A more detailed technical comparison between pLFA and the existing 253 solutions is provided in the technical description of pLFA that 254 follows. 256 4. Simple Repair Using pLFA 258 4.1. Link Repair 260 In this, the most basic, scenario Figure 1 we assume that we have a 261 path A-B-C-D that the packet must traverse. This may be a normal 262 best effort path or a traffic engineered path. 264 c' 265 A---B--//--C---D 266 | | 267 E---F--G 268 f' 270 Figure 1: Simple IPFRR Using pLFA 272 PPR is used to inject the repair path B->E->F->G->C into the network 273 with a PPR-ID of c'. B is monitoring the health of link B->C, for 274 example looking for loss-of-light, or using Bidirectional Forwarding 275 Detection (BFD) [RFC5880]. When B detects a failure it encapsulates 276 the packet to C by adding to the packet the PPR-ID for c' and sending 277 it to E. At C the packet is decapsulated and sent to D. The path 278 C->E->F->G->C may be a traffic engineered path or it may be a best 279 effort path. B may have at its disposal multiple paths to C with 280 different properties for different traffic classes. In this case 281 each path to be used would require its own PPR-ID (c', c'' etc). 283 In some circumstances, the repair path may be terminated at another 284 point in Q-space or at a node between C and D. For example, in 285 Figure 1 if all costs are 1, F is in Q-space with respect to a B->C 286 failure (F->G->C cost = 2, whilst F->E->B->C cost = 3) and thus the 287 packet can safely be encapsulated and send to F with a PPR-ID of f'. 288 Releasing the packet early in Q-space has two advantages, firstly the 289 packet can take a shorter path to its destination if one is available 290 rather than traveling to the far side of the failure and then back 291 tracking. 293 Releasing a packet in Q-space also reduces the size of the PPR path 294 that needs to be advertised, and potentially allows a repair path to 295 be shared among a number of failures. For example in Figure 2 G with 296 PPR-ID g' via B->E->F->G can be used to provide an IPFRR path for the 297 failure of both B->C and B->H. 299 c' 300 A---B--//--C---D 301 |\ | 302 | H--+ | 303 | \| 304 E---F--G 305 g' 307 Figure 2: Simple IPFRR Using pLFA With Shared Repair 309 Shared paths are useful in reducing the number of PPR paths that need 310 to be flooded to support FRR. 312 Note that where the packet takes the shortest path to the point in 313 Q-space that is closest to the destination, it will be taking a path 314 that is congruent with the post convergence path from the PLR to the 315 destination. This is the path that TI-LFA chooses to avoid its loop- 316 free convergence. However this is not the only loop-free strategy 317 available to a pLFA based solution. 319 4.2. Node Repair 321 Consider the network fragment shown in Figure 3 taken from 322 [I-D.bryant-ipfrr-tunnels], and consider that node A needs to deal 323 with the possible failure of node E. 325 Repair S-E 326 +----------------+ 327 | | 328 | Repair S-S s1'| 329 |+---------->[S1]| 330 || | / 331 || | / 332 || |/e' s2' 333 ----->[S]----//-----[E]---------[S2] 334 || | ^ 335 || | | 336 ||Repair S-S3 | | 337 |+---------->[S3] | 338 | s3' | 339 +-------------------------+ 340 Repair S-S2 342 Figure 3: Simple IPFRR - Node Failure 344 Node S needs the use of four repair paths to address the failure of 345 node E, one repair to each of E's neighbours for which E is on the 346 path to that neighbour. In Figure 3 there are three of these next- 347 next-hop repairs, noted as Repair S-Sx in the figure. In addition a 348 repair to E (Repair S->E) using a path other than along the path S-E> 349 should be installed for traffic to E on the basis that the problem 350 may be a failure of link S->E rather than a failure of the node. 352 The three repair paths to the next-next-hops of E can be installed as 353 PPR path S-Sx with a PPR-ID of sx'. The link repair for E a PPR path 354 to E which avoids link S-E with a PPR-ID of e'. 356 4.3. Shared Risk Link Groups 358 A shared risk link group (SRLG) is a set of links that are believed 359 to have some systematic connection such that when one fails there is 360 a high probability of all of them failing. This occurs, for example, 361 where all of the members of the group run in a common cable duct. 362 Where this relationship is known, and the simultaneous failure does 363 not partition the network,PPR can install paths such that all members 364 of the SRLG are avoided. pLFA has fewer constraints than other 365 methods in constructing arbitrary repair paths in the network. 366 [RFC6981] Section 6.1 describes the SRLG problem as it applies to 367 IPFRR. pLFA can address all of the cases described in [RFC6981]. 369 SRLG avoiding IPFRR paths can be complex. Since a packet can be 370 attracted towards the failure whenever it is released from a strict 371 path, the repair path may need a number of segments to steer it 372 safely into Q-space. If this is done in the data-plane this can 373 stress the MTU. pLFA creates the path in the control plane and its 374 encapsulation is invariant with respect to the complexity of the 375 path. Furthermore, if the need to reduce the data-plane 376 encapsulation side means that the repair path needs to use a sequence 377 of loose hops it is necessary to determine the behaviour of each 378 router on the chosen path. This contrasts with pLFA which can 379 determine the path using whatever metrics and policy is appropriate, 380 and then simply impose it without any data-plane overhead beyond that 381 needed for a simple repair. 383 4.4. Local Area Networks 385 LANs are a special type of SRLG and are solved using the SRLG 386 mechanisms outlined above. With all SRLGs, there is a trade-off 387 between the sophistication of the fault detection and the size of the 388 SRLG. [RFC6981] Section 6.2 describes the LAN problem as it applies 389 to IPFRR. pLFA can address all of the cases described in [RFC6981]. 391 4.5. Multiple Independent Failures 393 The Multiple Independent Failure cases described in [RFC6981] 394 Section 6.3 will be analyzed in a future version of this document. 396 4.6. Multi-homed Prefixes 398 The Multi-Homed Prefix (MHP) problem is described in [RFC5286] 399 Section 6.1, [RFC6981] Section 5.3 and [RFC8518]. MHP will be 400 addressed in a future version of this document. 402 4.7. ECMP 404 Equal Cost Multi-Path (ECMP) is a consideration in any IPFRR method 405 that does not use strict paths, and can be both an opportunity and 406 threat. It is an opportunity in that it allows for the repair 407 traffic to be distributed over a number of alternative paths to 408 minimize congestion. If a loose pLFA path is injected into the 409 network, then any available ECMP paths that fulfill the PPR path 410 constraints can be installed following the same procedure used in 411 normal IGP path computation. 413 However, care must be taken that a packet is not in a position where 414 it is released from a repair at an ECMP point such that one of the 415 ECMP paths is back via the failure. This can never happen if the 416 correct definition of Q-space [RFC7490] is used in calculating the 417 repair path. 419 5. Repair To A Traffic Engineered Alternate Path 421 In this approach there are two traffic engineered paths from A to D 422 (Figure 4. 424 d' 425 A-??-B--??--C--??-D 426 | | | | 427 E----F------G-----+ 429 Figure 4: Traffic Engineered IPFRR Using pLFA 431 The primary path A->B->C->D is protected by a traffic engineered path 432 A->F->G->D (PPR-ID d') with traffic engineered connectors from B 433 (B->F) and C (C->G). The path A->F->G->D and its connectors can be 434 created and injected by any node with access to the IGP, but it is 435 more likely to be created by a traffic engineering controller. 437 If link B->C fails, B re-routes packets destined for D to the traffic 438 engineered path A->F->G->D via connector B->F. It does this by 439 encapsulating the packet with a PPR-ID of d'. 441 Clearly there is nothing special needed to get the packet from B to F 442 as they are adjacent but if there is a node say X on the path from B 443 to F an explicit path needs to be created from B to F via X. 444 Normally the repair would be created as a single PPR path (i.e. 445 B->F->G->D) with a PPR-ID of d'. In this approach the repair from A 446 would be A->F->G->D with a PPR-ID of d' also. Similarly C-G-D would 447 again share the PPR-ID d'. 449 If preferred the repair path could also be constructed using double 450 encapsulation or using an SR approach in which the first segment was 451 B-F with a PPR-ID/SID f' and the second segment was F-D with PPR-ID 452 of d'. 454 In the example shown in Figure 4 the proposed B-//->C protection path 455 was B->F->G->D. This is node protecting on C since the repair path 456 avoids C. Although link failures tend to be more common than node 457 failures some critical applications would prefer node protection 458 where possible. Node avoidance may not be possible within the 459 network, and may come at a cost of increased path repair path length. 460 However, whether to include node protection and as what cost to 461 accept its inclusion is a matter of network operator policy. 463 The repair constructed in this section required the inclusion of a 464 set of PPR defined links to construct the repair. PPR has the 465 ability to construct graphs [I-D.ce-lsr-ppr-graph] which can simplify 466 the specification of the required repair topology. This is discussed 467 in Section 6. 469 6. Use of a Repair Graph 471 PPR has the ability to inject graphs into a network as well as linear 472 paths [I-D.ce-lsr-ppr-graph]. PPR graphs specify the paths from a 473 set of nodes to a single node, and are a compact method of 474 representing a set of paths to that destination with shared 475 properties. 477 6.1. Single Repair Graph 479 In [I-D.ce-lsr-ppr-graph] the S bit in the PPR Path Description 480 Element (PDE) specifies that a a network node is a Source and a D bit 481 specifies that it is a destination. A graph with all S bits set on 482 the leaves and a D bit on the root is a unidirectional tree. 484 d' 485 S S S D 486 A-??-B--??--C--??-D 487 | | | | 488 E----F------G-----+ 490 Figure 5: pLFA using PPR Graphs 492 Consider the network fragment shown in Figure 5. A graph with a PPR- 493 ID d' is constructed attaching each of the nodes A, B, and C to D. 494 Should any of the nodes A, B or C fail the packet can be forwarded on 495 the PPR graph to D with the PPR-ID of d'. In the unidirectional 496 repair graph A, B, and C are all sources (signaled with the S bit 497 set), and D is the only destination (signaled with the D bit set. 499 6.2. Multiple Disjoint Graphs 501 Consider Figure 1 from [RFC7812] which illustrates the problem of 502 IPFRR in a network that is 2-connected. 504 [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| 505 | | | | ^ | | | 506 | | | V | | V V 507 [R] [F] [C] r'[R] [F] [C] r''[R] [F] [C] 508 | | | ^ ^ ^ | | 509 | | | | | | V | 510 [A]---[B]---| [A]-->[B]---| [A]<--[B]<--| 512 (a) (b) (c) 513 a 2-connected graph Blue Tree towards R Red Tree towards R 515 Figure 6: A 2-Connected Network 517 Figure 6(a) is the full network, and Figure 6(b) and (b) are two 518 corresponding redundant trees from [RFC7812]. Using the Red and Blue 519 trees towards R every node has at least two paths to R. We give R a 520 PPR-ID of r' in the Blue tree and a PPR-ID of r'' in the Red tree. R 521 is the only destination in the PPR graph (D bit set), but all other 522 nodes are sources (S bit set). For clarity this bit setting is not 523 shown in Figure 6. 525 It is worth noting what happens at nodes B and D in Figure 6(b). B 526 is an ECMP to D via F and C. What happens at node B is a matter of 527 implementation and operator preference. Either B can choose one of 528 the next-hops, or it use them as an ECMP pair. It can also use the 529 availability of the pair to protect against B->F or B->C being an 530 unexpected SRLG with respect to link A->R. D is a merge point for 531 traffic destined for r' arriving from F and from C. It simply 532 forwards the traffic to r' as normal. Similarly in Figure 6(c) D can 533 sent traffic to r'' via F or C. 535 Whilst in this example the Red and Blue trees use exactly the same 536 links and nodes used by the main topology, a repair graph could use 537 available nodes and links outside this network fragment. 539 Now consider Figure 2 from [RFC7812] which illustrates the problem of 540 IPFRR in a network that is not 2-connected. 542 [E]---[D]---| |---[J] 543 | | | | | 544 | | | | | 545 [R] [F] [C]---[G] | 546 | | | | | 547 | | | | | 548 [A]---[B]---| |---[H] 550 (a) a graph that is not 2-connected 552 [E]<--[D]<--| [J] [E]-->[D]---| |---[J] 553 | ^ | | | | | ^ 554 V | | | r'' V V V | 555 [R] [F] [C]<--[G] | [R] [F] [C]<--[G] | 556 r' ^ ^ ^ | ^ | | | 557 | | | V | V | | 558 [A]-->[B]---| |---[H] [A]<--[B]<--| [H] 560 (b) Blue Tree towards R (c) Red Tree towards R 562 Figure 7: A Network That Is Not 2-Connected 564 Again there are two paths (with PPR-IDs r' and r'') to R from all 565 nodes except that G, J and H all depend on link G->C and node C which 566 is a single point of failure in the network. 568 Again note that B in the Blue tree and D in the Red tree has two 569 paths to r' and r'' respectively that it may use according to 570 configuration or preference. 572 7. Centralized and Decentralized Approaches 574 pLFA paths can be established through both centralized and 575 decentralized approaches. 577 A centralized system has a more holistic view of the network and its 578 policies, its resource constraints and resource usage. A 579 decentralized system is inherently more resilient to failure and is a 580 good fit where the network is a simple best effort network as is 581 commonly deployed. 583 A centralized system gathers the network state, just as any SDN 584 system does, and computes the FRR paths needed. However, unlike 585 normal SDN operation where the controller needs to individually 586 instruct every entity on the path for every path, in a PPR network it 587 is only necessary to inject the PPR path at one point. In practice, 588 for reliability, it would inject the PPR paths in a small number of 589 places, and the naturally reliability of the IGP would ensure the 590 complete distribution of the paths. Furthermore, the system 591 collecting the network state would naturally send the PPR LSPs back 592 to the SDN controller providing quality assurance that the FRR paths 593 had been distributed. 595 In a decentralized approach the pLFA path is computed within the 596 network, normally by the PLR. Further details of this approach will 597 be provided in a future version of this document. 599 8. Independence of operation 601 Each PPR path is independent of all other paths in the network. This 602 means that there is no constraint on how the path is calculated, and 603 a different algorithm can be used on every path. Some of the other 604 FRR approaches have this property, but not all. For example LFA is 605 constrained by the properties of the base IGP as to a large degree is 606 RLFA. PPR can incorporate best effort segments if required, but from 607 a data-plane perspective there is no advantage in doing so. In this 608 case there is a dependence on the path choice in the base routing 609 protocol. 611 MRT and Not-Via can use any algorithm to calculate the repair, but it 612 needs to be common across the network, although the expectation in 613 the case of Not-Via is that the algorithm would be a Dijkstra based 614 SPF calculation. In both these cases to change the algorithm would 615 require turning off FRR for the whole network, re-configuring and 616 then restarting FRR. 618 RSVP-TE based FRR can specify any path, but at the cost of 619 maintaining the soft-state. 621 A PLR in a TI-LFA or any SR based approach can also compute paths 622 independent of each other, but they tend to need to do this as a 623 concatenation of a series of shortest paths in order to reduce the 624 number of SIDs they need to form the path. TI-LFA is thus highly 625 dependent on the underlying best effort paths. 627 pLFA can be used as a method of converting classic LFA or RLFA to 628 full coverage by providing the paths that these methods are unable to 629 support, or to provide any the sub-paths needed to reduce the number 630 of TI-LFA SIDs. 632 9. Data-plane Considerations 634 This section is a survey of a number of data-planes in each case 635 considering how a PPR-ID could added to map the packet to required 636 FRR path. 638 9.1. Traditional IP 640 Where the data-plane is "traditional" IP the user packet needs to be 641 encapsulated such that the outer IP address is the PPR-ID. Any 642 preferred encapsulation can be used such as: IP in IP, IP in GRE, or 643 IP in UDP. 645 The tunnel capabilities of a node can be advertised using the method 646 described in [I-D.xu-isis-encapsulation-cap] allowing different 647 tunnel types to be used for different PPR paths, depending on the 648 capability of the various nodes in the network. 650 A common operational issue with this type of encapsulation for IPFRR 651 has been the shortage of IP addresses. However this is not an issue 652 in an IPv6 network. 654 9.2. Segment Routing over an IPv6 Data Plane (SRv6) 656 Where the data-plane is SRv6 [RFC8754] pLFA would be used to steer a 657 packet towards the next segment end-point. Clearly an extra level of 658 IP encapsulation could be used Section 9.1, but that expands the 659 packet by adding at least 36 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., Contreras, L. M., 775 Tantsura, J., and Y. Qu, "Preferred Path Routing (PPR) in 776 IS-IS", draft-chunduri-lsr-isis-preferred-path-routing-07 777 (work in progress), November 2021. 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-rtgwg-segment-routing-ti-lfa] 787 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 788 Decraene, B., and D. Voyer, "Topology Independent Fast 789 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 790 routing-ti-lfa-07 (work in progress), June 2021. 792 [I-D.xu-isis-encapsulation-cap] 793 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 794 L. M., and L. Jalil, "Advertising Tunnelling Capability in 795 IS-IS", draft-xu-isis-encapsulation-cap-07 (work in 796 progress), October 2016. 798 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 799 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 800 DOI 10.17487/RFC3936, October 2004, 801 . 803 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 804 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 805 DOI 10.17487/RFC4090, May 2005, 806 . 808 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 809 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 810 DOI 10.17487/RFC5286, September 2008, 811 . 813 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 814 RFC 5714, DOI 10.17487/RFC5714, January 2010, 815 . 817 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 818 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 819 2010, . 821 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 822 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 823 . 825 [RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP 826 and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, 827 DOI 10.17487/RFC6981, August 2013, 828 . 830 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 831 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 832 RFC 7490, DOI 10.17487/RFC7490, April 2015, 833 . 835 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 836 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 837 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 838 . 840 [RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P. 841 Francois, "Micro-loop Prevention by Introducing a Local 842 Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 843 2018, . 845 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 846 Decraene, B., Litkowski, S., and R. Shakir, "Segment 847 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 848 July 2018, . 850 [RFC8518] Sarkar, P., Ed., Chunduri, U., Ed., Hegde, S., Tantsura, 851 J., and H. Gredler, "Selection of Loop-Free Alternates for 852 Multi-Homed Prefixes", RFC 8518, DOI 10.17487/RFC8518, 853 March 2019, . 855 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 856 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 857 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 858 . 860 Authors' Addresses 862 Stewart Bryant 863 University of Surrey 865 Email: sb@stewartbryant.com 867 Uma Chunduri 868 Intel 870 Email: umac.ietf@gmail.com 871 Toerless Eckert 872 Futurewei Technologies Inc 874 Email: tte+ietf@cs.fau.de