idnits 2.17.1 draft-bryant-rtgwg-plfa-00.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 (July 02, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R' is mentioned on line 553, but not defined == Missing Reference: 'F' is mentioned on line 553, but not defined == Missing Reference: 'C' is mentioned on line 553, but not defined == Missing Reference: 'G' is mentioned on line 553, but not defined == Missing Reference: 'E' is mentioned on line 550, but not defined == Missing Reference: 'D' is mentioned on line 550, but not defined == Missing Reference: 'J' is mentioned on line 550, but not defined == Missing Reference: 'A' is mentioned on line 556, but not defined == Missing Reference: 'B' is mentioned on line 556, but not defined == Missing Reference: 'H' is mentioned on line 556, but not defined == Outdated reference: A later version (-04) exists of draft-ce-lsr-ppr-graph-02 == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 Summary: 0 errors (**), 0 flaws (~~), 15 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 U. Chunduri 4 Intended status: Informational T. Eckert 5 Expires: January 3, 2020 Futurewei Technologies Inc 6 July 02, 2019 8 Preferred Path Loop-Free Alternate (pLFA) 9 draft-bryant-rtgwg-plfa-00 11 Abstract 13 Fast re-route (FRR) is a technique that allows productive forwarding 14 to continue in a network after a failure has occurred, but before the 15 network has has time to re-converge. This is achieved by forwarding 16 a packet on an alternate path that will not result in the packet 17 looping. Preferred Path Routing (PPR) provides a method of injecting 18 explicit paths into the routing protocol. The use of PPR to support 19 FRR has a number of advantages. This document describes the 20 advantages of using PPR to provide a loop-free alternate FRR path, 21 and provides a framework for its use in this application. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 3, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. A Note on the term IPFRR . . . . . . . . . . . . . . . . 3 59 2. PPR Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Preferred Path LFA (pLFA) Deployment Advantages . . . . . . . 4 61 4. Simple Repair Using pLFA . . . . . . . . . . . . . . . . . . 6 62 4.1. Link Repair . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Node Repair . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . 8 65 4.4. Local Area Networks . . . . . . . . . . . . . . . . . . . 9 66 4.5. Multiple Independent Failures . . . . . . . . . . . . . . 9 67 4.6. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . 9 68 4.7. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Repair To A Traffic Engineered Alternate Path . . . . . . . . 10 70 6. Use of a Repair Graph . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Single Repair Graph . . . . . . . . . . . . . . . . . . . 11 72 6.2. Multiple Disjoint Graphs . . . . . . . . . . . . . . . . 11 73 7. Centralized and Decentralized Approaches . . . . . . . . . . 13 74 8. Independence of operation . . . . . . . . . . . . . . . . . . 14 75 9. Data-plane Considerations . . . . . . . . . . . . . . . . . . 14 76 9.1. Traditional IP . . . . . . . . . . . . . . . . . . . . . 15 77 9.2. Segment Routing over an IPv6 Data Plane (SRv6) . . . . . 15 78 9.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. Loop Free Convergence . . . . . . . . . . . . . . . . . . . . 16 80 11. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 15.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Preferred Path Routing (PPR) 92 [I-D.chunduri-lsr-isis-preferred-path-routing] is a method of 93 introducing explicit paths to a network. Such a path may be any 94 loop-free path between two points in the network that satisfies the 95 need for which the path was created. The PPR path is not constrained 96 to be the shortest path between any points in the network, although 97 the use of shortest path segments is provided for in order to 98 compress the size of the path description flooded by the routing 99 protocol. The advantages of PPR over alternate methods of creating 100 such paths is described in 101 [I-D.chunduri-lsr-isis-preferred-path-routing]. 103 A packet is carried over the network in an appropriate form using the 104 Preferred Path Routing Identifier (PPR-ID) as the data plane 105 identifier to map the packet to the PPR path, and hence the resources 106 and next-hop (NH). One way of adding a PPR-ID to a packet would be 107 to encapsulate it, but PPR does not restrict the user to the use of 108 encapsulation. How the PPR-ID is carried in the general case is 109 outside the scope of this document. Various methods of adding the 110 PPR-ID to a packet for the purposes of Fast-Reroute (FRR) are 111 described in Section 9. 113 IP Fast Re-route (IPFRR) Section 1.1 and the methods known at the 114 time of its writing is described in [RFC5714]. A number of later 115 methods are described in [RFC6981], [RFC7490], [RFC7812] and 116 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. 118 This document is a framework describing various methods whereby PPR 119 can be used to provide IP Fast Reroute (IPFRR) paths. PPR can 120 provide IPFRR in a number of ways. 122 o Signaling pre-computed preferred alternatives for the primary path 123 o Signaling individual segments on the repair path. o Selective 124 overriding of locally computed Loop Free Alternates (LFA) for the NH 125 failure. o Local repair to a Traffic Engineered paths avoiding the 126 need for multi-hop Bidirectional Forwarding Detection (BFD) 127 [RFC5880]. o Micro-loop elimination [RFC5715]. 129 These are described in more detail within this memo. 131 1.1. A Note on the term IPFRR 133 The term IP fast re-route (IPFRR) was adopted by the IETF as the 134 general name for best-effort Fast Re-route (FRR) in best effort IP 135 and MPLS networks. This was to distinguish this new work from the 136 then established FRR as described in [RFC4090] which uses RSVP 137 Traffic Engineered (RSVP-TE) MPLS paths [RFC3936]. 139 Within this document the terms IPFRR and FRR are used 140 interchangeably. 142 2. PPR Overview 144 PPR works by injecting into the network a path or a graph and a 145 corresponding forwarding identifier (PPR-ID). A node examines each 146 PPR path description and if it is on the path it inserts into the 147 Forwarding Information Database (FIB) an entry for the PPR-ID with 148 the next hop as either the next entry along the PPR path, or if a 149 loose path is specified, the next hop on the shortest path to the 150 next hop along the PPR path. This is described in 151 [I-D.chunduri-lsr-isis-preferred-path-routing]. 153 PPR also has the ability to inject into a network a tree rooted at a 154 node identified a PPR-ID. This is described in 155 [I-D.ce-lsr-ppr-graph]. This graph mechanism provides a compact 156 representation of a set of paths to a given PPR-ID. This works in a 157 similar manner to the linear path case, in which a node on the graph 158 inserts a FIB entry for the PPR-ID with the next hop as either the 159 next node in the graph, or the next hop on the shortest path to the 160 next node in the graph. Clearly the graph needs to be a spanning 161 tree and must not contain a cycle. 163 In the description of the FRR methods provided in the text, the term 164 encapsulation (and decapsulation) is frequently used in connection 165 with the addition (and removal) of a PPR-ID to be used by the 166 forwarding later to identify to the forwarders the PPR path that the 167 packet needs to traverse to be follow the repair path. Encapsulation 168 is only one of a number of methods that can be used and is used in 169 this memo as a convenience without loss of generality. For more 170 information see Section 9. 172 3. Preferred Path LFA (pLFA) Deployment Advantages 174 PPR allows the construction of arbitrary engineered backup paths. In 175 this respect it is like similar to RSVP-TE and Topology Independent 176 Loop-Free Alternates (TI-LFA) 177 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. However, unlike those 178 approaches PPR is applicable to any forwarding plane. For example, 179 it is possible to support MPLS, both IPv4 and IPv6 and Ethernet. 181 Like Segment Routing (SR) [RFC8402], PPR uses extensions to the 182 existing IGP, however, unlike SR, PPR requires no extension to the 183 data plane. Again, unlike SR, which requires a Segment Identifier 184 (SID) in the network layer header for every non-shortest path 185 forwarding instruction, an arbitrary path does not require expansion 186 of the user data packet beyond that needed for the initial insertion 187 of the PPR-ID. This mitigates the MTU stress that SR introduces to 188 the network. 190 PPR based IPFRR supports 100% failure coverage similar to RSVP-TE 191 [RFC4090], TI-LFA, Maximally Redundant Trees (MRT) [RFC7812] and Not- 192 Via [RFC6981]. It does not have the coverage restrictions that apply 193 to Loop-Free Alternate (LFA) [RFC5286] and Remote LFA (RLFA) 194 [RFC7490]. 196 Shared Risk Link Groups (SRLGs) make it more difficult find repairs 197 in LFA and RLFA reducing repair coverage. TI-LFA can address this, 198 but only at a cost of expanding the number of SIDs and hence the 199 packet size. 201 Supporting multiple concurrent failures is difficult in all of the 202 IPRFF approaches except MRT, which can repair two concurrent 203 failures. However unlike MRT, which is constrained by its network 204 wide algorithm, PPR allows individual, arbitrary repair paths to 205 instantiated, for any failure. 207 In the current TI-LFA design, priority is given to repairing 208 connectivity rather than conforming to the operator traffic policy. 209 A PPR based FFR approach can apply policy to the repaired traffic, 210 including, if required multiple policies to an individual failure. 212 One of the main advantages of TI-LFA compared to other IPFRR 213 approaches is that it creates repair paths that are congruent with 214 the post convergence path from the Point of Local Repair (PLR) 215 [RFC4090] to the destination. These paths, which may be longer than 216 strictly necessary to reach Q-space [I-D.bryant-ipfrr-tunnels], stop 217 micro-loops from forming along the repair path during re-convergence. 218 PPR can also create these congruent paths without the need to 219 introduce SR into the network. 221 One of the limitations in TI-LFA, RLFA and LFA is that they do not 222 have a method of selectively creating alternative next-hops or indeed 223 full repair paths based on policy, or traffic engineering information 224 known to the operator. PPR provides a simple way to inject arbitrary 225 paths. It may therefore be used to enhance an existing LFA/RLFA/TI- 226 LFA IPFRR enabled network by selectively injecting paths to provide a 227 repair for business critical links with a policy in the PLR that 228 where provided a PPR path should be preferred over a local calculated 229 LFA based paths. 231 PPR is applicable to both centralized and PLR computed repair paths 232 each of which has advantages in different circumstances. A centrally 233 computed repair path only requires interaction with one network node 234 which then floods the instruction. This differs from the normal SDN 235 approach which requires interaction with all of the nodes along the 236 path and RSVP-TE which requires interaction with at least one end- 237 point of every repair. 239 Like TI-LFA, pLFA is based on a small extension to the IGP. It uses 240 the IGP flooding mechanism and in-built state maintenance and 241 consistency checks. This contrasts with RSVP-TE which needs its own 242 separate Signaling and soft-state maintenance method. 244 The requirement that the pLFA solution addresses is thus the ability 245 to construct repair paths that conform to operator policy without 246 data-plane changes or significant MTU increase, and without 247 introducing any control plane changes other than a small addition to 248 the existing IGP. 250 A more detailed technical comparison between pLFA and the existing 251 solutions is provided in the technical description of pLFA that 252 follows. 254 4. Simple Repair Using pLFA 256 4.1. Link Repair 258 In this, the most basic, scenario Figure 1 we assume that we have a 259 path A-B-C-D that the packet must traverse. This may be a normal 260 best effort path or a traffic engineered path. 262 c' 263 A---B--//--C---D 264 | | 265 E---F--G 266 f' 268 Figure 1: Simple IPFRR Using pLFA 270 PPR is used to inject the repair path B->E->F->G->C into the network 271 with a PPR-ID of c'. B is monitoring the health of link B->C, for 272 example looking for loss-of-light, or using Bidirectional Forwarding 273 Detection (BFD) [RFC5880]. When B detects a failure it encapsulates 274 the packet to C by adding to the packet the PPR-ID for c' and sending 275 it to E. At C the packet is decapsulated and sent to D. The path 276 C->E->F->G->C may be a traffic engineered path or it may be a best 277 effort path. B may have at its disposal multiple paths to C with 278 different properties for different traffic classes. In this case 279 each path to be used would require its own PPR-ID (c', c'' etc). 281 In some circumstances, the repair path may be terminated at another 282 point in Q-space or at a node between C and D. For example, in 283 Figure 1 if all costs are 1, F is in Q-space with respect to a B->C 284 failure (F->G->C cost = 2, whilst F->E->B->C cost = 3) and thus the 285 packet can safely be encapsulated and send to F with a PPR-ID of f'. 286 Releasing the packet early in Q-space has two advantages, firstly the 287 packet can take a shorter path to its destination if one is available 288 rather than traveling to the far side of the failure and then back 289 tracking. 291 Releasing a packet in Q-space also reduces the size of the PPR path 292 that needs to be advertised, and potentially allows a repair path to 293 be shared among a number of failures. For example in Figure 2 G with 294 PPR-ID g' via B->E->F->G can be used to provide an IPFRR path for the 295 failure of both B->C and B->H. 297 c' 298 A---B--//--C---D 299 |\ | 300 | H--+ | 301 | \| 302 E---F--G 303 g' 305 Figure 2: Simple IPFRR Using pLFA With Shared Repair 307 Shared paths are useful in reducing the number of PPR paths that need 308 to be flooded to support FRR. 310 Note that where the packet takes the shortest path to the point in 311 Q-space that is closest to the destination, it will be taking a path 312 that is congruent with the post convergence path from the PLR to the 313 destination. This is the path that TI-LFA chooses to avoid its loop- 314 free convergence. However this is not the only loop-free strategy 315 available to a pLFA based solution. 317 4.2. Node Repair 319 Consider the network fragment shown in Figure 3 taken from 320 [I-D.bryant-ipfrr-tunnels], and consider that node A needs to deal 321 with the possible failure of node E. 323 Repair S-E 324 +----------------+ 325 | | 326 | Repair S-S s1'| 327 |+---------->[S1]| 328 || | / 329 || | / 330 || |/e' s2' 331 ----->[S]----//-----[E]---------[S2] 332 || | ^ 333 || | | 334 ||Repair S-S3 | | 335 |+---------->[S3] | 336 | s3' | 337 +-------------------------+ 338 Repair S-S2 340 Figure 3: Simple IPFRR - Node Failure 342 Node S needs the use of four repair paths to address the failure of 343 node E, one repair to each of E's neighbours for which E is on the 344 path to that neighbour. In Figure 3 there are three of these next- 345 next-hop repairs, noted as Repair S-Sx in the figure. In addition a 346 repair to E (Repair S->E) using a path other than along the path S-E> 347 should be installed for traffic to E on the basis that the problem 348 may be a failure of link S->E rather than a failure of the node. 350 The three repair paths to the next-next-hops of E can be installed as 351 PPR path S-Sx with a PPR-ID of sx'. The link repair for E a PPR path 352 to E which avoids link S-E with a PPR-ID of e'. 354 4.3. Shared Risk Link Groups 356 A shared risk link group (SRLG) is a set of links that are believed 357 to have some systematic connection such that when one fails there is 358 a high probability of all of them failing. This occurs, for example, 359 where all of the members of the group run in a common cable duct. 360 Where this relationship is known, and the simultaneous failure does 361 not partition the network,PPR can install paths such that all members 362 of the SRLG are avoided. pLFA has fewer constraints than other 363 methods in constructing arbitrary repair paths in the network. 364 [RFC6981] Section 6.1 describes the SRLG problem as it applies to 365 IPFRR. pLFA can address all of the cases described in [RFC6981]. 367 SRLG avoiding IPFRR paths can be complex. Since a packet can be 368 attracted towards the failure whenever it is released from a strict 369 path, the repair path may need a number of segments to steer it 370 safely into Q-space. If this is done in the data-plane this can 371 stress the MTU. pLFA creates the path in the control plane and its 372 encapsulation is invariant with respect to the complexity of the 373 path. Furthermore, if the need to reduce the data-plane 374 encapsulation side means that the repair path needs to use a sequence 375 of loose hops it is necessary to determine the behaviour of each 376 router on the chosen path. This contrasts with pLFA which can 377 determine the path using whatever metrics and policy is appropriate, 378 and then simply impose it without any data-plane overhead beyond that 379 needed for a simple repair. 381 4.4. Local Area Networks 383 LANs are a special type of SRLG and are solved using the SRLG 384 mechanisms outlined above. With all SRLGs, there is a trade-off 385 between the sophistication of the fault detection and the size of the 386 SRLG. [RFC6981] Section 6.2 describes the LAN problem as it applies 387 to IPFRR. pLFA can address all of the cases described in [RFC6981]. 389 4.5. Multiple Independent Failures 391 The Multiple Independent Failure cases described in [RFC6981] 392 Section 6.3 will be analyzed in a future version of this document. 394 4.6. Multi-homed Prefixes 396 The Multi-Homed Prefix (MHP) problem is described in [RFC5286] 397 Section 6.1, [RFC6981] Section 5.3 and [RFC8518]. MHP will be 398 addressed in a future version of this document. 400 4.7. ECMP 402 Equal Cost Multi-Path (ECMP) is a consideration in any IPFRR method 403 that does not use strict paths, and can be both an opportunity and 404 threat. It is an opportunity in that it allows for the repair 405 traffic to be distributed over a number of alternative paths to 406 minimize congestion. If a loose pLFA path is injected into the 407 network, then any available ECMP paths that fulfill the PPR path 408 constraints can be installed following the same procedure used in 409 normal IGP path computation. 411 However, care must be taken that a packet is not in a position where 412 it is released from a repair at an ECMP point such that one of the 413 ECMP paths is back via the failure. This can never happen if the 414 correct definition of Q-space [RFC7490] is used in calculating the 415 repair path. 417 5. Repair To A Traffic Engineered Alternate Path 419 In this approach there are two traffic engineered paths from A to D 420 (Figure 4. 422 d' 423 A-??-B--??--C--??-D 424 | | | | 425 E----F------G-----+ 427 Figure 4: Traffic Engineered IPFRR Using pLFA 429 The primary path A->B->C->D is protected by a traffic engineered path 430 A->F->G->D (PPR-ID d') with traffic engineered connectors from B 431 (B->F) and C (C->G). The path A->F->G->D and its connectors can be 432 created and injected by any node with access to the IGP, but it is 433 more likely to be created by a traffic engineering controller. 435 If link B->C fails, B re-routes packets destined for D to the traffic 436 engineered path A->F->G->D via connector B->F. It does this by 437 encapsulating the packet with a PPR-ID of d'. 439 Clearly there is nothing special needed to get the packet from B to F 440 as they are adjacent but if there is a node say X on the path from B 441 to F an explicit path needs to be created from B to F via X. 442 Normally the repair would be created as a single PPR path (i.e. 443 B->F->G->D) with a PPR-ID of d'. In this approach the repair from A 444 would be A->F->G->D with a PPR-ID of d' also. Similarly C-G-D would 445 again share the PPR-ID d'. 447 If preferred the repair path could also be constructed using double 448 encapsulation or using an SR approach in which the first segment was 449 B-F with a PPR-ID/SID f' and the second segment was F-D with PPR-ID 450 of d'. 452 In the example shown in Figure 4 the proposed B-//->C protection path 453 was B->F->G->D. This is node protecting on C since the repair path 454 avoids C. Although link failures tend to be more common than node 455 failures some critical applications would prefer node protection 456 where possible. Node avoidance may not be possible within the 457 network, and may come at a cost of increased path repair path length. 458 However, whether to include node protection and as what cost to 459 accept its inclusion is a matter of network operator policy. 461 The repair constructed in this section required the inclusion of a 462 set of PPR defined links to construct the repair. PPR has the 463 ability to construct graphs [I-D.ce-lsr-ppr-graph] which can simplify 464 the specification of the required repair topology. This is discussed 465 in Section 6. 467 6. Use of a Repair Graph 469 PPR has the ability to inject graphs into a network as well as linear 470 paths [I-D.ce-lsr-ppr-graph]. PPR graphs specify the paths from a 471 set of nodes to a single node, and are a compact method of 472 representing a set of paths to that destination with shared 473 properties. 475 6.1. Single Repair Graph 477 In [I-D.ce-lsr-ppr-graph] the S bit in the PPR Path Description 478 Element (PDE) specifies that a a network node is a Source and a D bit 479 specifies that it is a destination. A graph with all S bits set on 480 the leaves and a D bit on the root is a unidirectional tree. 482 d' 483 S S S D 484 A-??-B--??--C--??-D 485 | | | | 486 E----F------G-----+ 488 Figure 5: pLFA using PPR Graphs 490 Consider the network fragment shown in Figure 5. A graph with a PPR- 491 ID d' is constructed attaching each of the nodes A, B, and C to D. 492 Should any of the nodes A, B or C fail the packet can be forwarded on 493 the PPR graph to D with the PPR-ID of d'. In the unidirectional 494 repair graph A, B, and C are all sources (signaled with the S bit 495 set), and D is the only destination (signaled with the D bit set. 497 6.2. Multiple Disjoint Graphs 499 Consider Figure 1 from [RFC7812] which illustrates the problem of 500 IPFRR in a network that is 2-connected. 502 [E]---[D]---| [E]<--[D]<--| [E]-->[D]---| 503 | | | | ^ | | | 504 | | | V | | V V 505 [R] [F] [C] r'[R] [F] [C] r''[R] [F] [C] 506 | | | ^ ^ ^ | | 507 | | | | | | V | 508 [A]---[B]---| [A]-->[B]---| [A]<--[B]<--| 510 (a) (b) (c) 511 a 2-connected graph Blue Tree towards R Red Tree towards R 513 Figure 6: A 2-Connected Network 515 Figure 6(a) is the full network, and Figure 6(b) and (b) are two 516 corresponding redundant trees from [RFC7812]. Using the Red and Blue 517 trees towards R every node has at least two paths to R. We give R a 518 PPR-ID of r' in the Blue tree and a PPR-ID of r'' in the Red tree. R 519 is the only destination in the PPR graph (D bit set), but all other 520 nodes are sources (S bit set). For clarity this bit setting is not 521 shown in Figure 6. 523 It is worth noting what happens at nodes B and D in Figure 6(b). B 524 is an ECMP to D via F and C. What happens at node B is a matter of 525 implementation and operator preference. Either B can choose one of 526 the next-hops, or it use them as an ECMP pair. It can also use the 527 availability of the pair to protect against B->F or B->C being an 528 unexpected SRLG with respect to link A->R. D is a merge point for 529 traffic destined for r' arriving from F and from C. It simply 530 forwards the traffic to r' as normal. Similarly in Figure 6(c) D can 531 sent traffic to r'' via F or C. 533 Whilst in this example the Red and Blue trees use exactly the same 534 links and nodes used by the main topology, a repair graph could use 535 available nodes and links outside this network fragment. 537 Now consider Figure 2 from [RFC7812] which illustrates the problem of 538 IPFRR in a network that is not 2-connected. 540 [E]---[D]---| |---[J] 541 | | | | | 542 | | | | | 543 [R] [F] [C]---[G] | 544 | | | | | 545 | | | | | 546 [A]---[B]---| |---[H] 548 (a) a graph that is not 2-connected 550 [E]<--[D]<--| [J] [E]-->[D]---| |---[J] 551 | ^ | | | | | ^ 552 V | | | r'' V V V | 553 [R] [F] [C]<--[G] | [R] [F] [C]<--[G] | 554 r' ^ ^ ^ | ^ | | | 555 | | | V | V | | 556 [A]-->[B]---| |---[H] [A]<--[B]<--| [H] 558 (b) Blue Tree towards R (c) Red Tree towards R 560 Figure 7: A Network That Is Not 2-Connected 562 Again there are two paths (with PPR-IDs r' and r'') to R from all 563 nodes except that G, J and H all depend on link G->C and node C which 564 is a single point of failure in the network. 566 Again note that B in the Blue tree and D in the Red tree has two 567 paths to r' and r'' respectively that it may use according to 568 configuration or preference. 570 7. Centralized and Decentralized Approaches 572 pLFA paths can be established through both centralized and 573 decentralized approaches. 575 A centralized system has a more holistic view of the network and its 576 policies, its resource constraints and resource usage. A 577 decentralized system is inherently more resilient to failure and is a 578 good fit where the network is a simple best effort network as is 579 commonly deployed. 581 A centralized system gathers the network state, just as any SDN 582 system does, and computes the FRR paths needed. However, unlike 583 normal SDN operation where the controller needs to individually 584 instruct every entity on the path for every path, in a PPR network it 585 is only necessary to inject the PPR path at one point. In practice, 586 for reliability, it would inject the PPR paths in a small number of 587 places, and the naturally reliability of the IGP would ensure the 588 complete distribution of the paths. Furthermore, the system 589 collecting the network state would naturally send the PPR LSPs back 590 to the SDN controller providing quality assurance that the FRR paths 591 had been distributed. 593 In a decentralized approach the pLFA path is computed within the 594 network, normally by the PLR. Further details of this approach will 595 be provided in a future version of this document. 597 8. Independence of operation 599 Each PPR path is independent of all other paths in the network. This 600 means that there is no constraint on how the path is calculated, and 601 a different algorithm can be used on every path. Some of the other 602 FRR approaches have this property, but not all. For example LFA is 603 constrained by the properties of the base IGP as to a large degree is 604 RLFA. PPR can incorporate best effort segments if required, but from 605 a data-plane perspective there is no advantage in doing so. In this 606 case there is a dependence on the path choice in the base routing 607 protocol. 609 MRT and Not-Via can use any algorithm to calculate the repair, but it 610 needs to be common across the network, although the expectation in 611 the case of Not-Via is that the algorithm would be a Dijkstra based 612 SPF calculation. In both these cases to change the algorithm would 613 require turning off FRR for the whole network, re-configuring and 614 then restarting FRR. 616 RSVP-TE based FRR can specify any path, but at the cost of 617 maintaining the soft-state. 619 A PLR in a TI-LFA or any SR based approach can also compute paths 620 independent of each other, but they tend to need to do this as a 621 concatenation of a series of shortest paths in order to reduce the 622 number of SIDs they need to form the path. TI-LFA is thus highly 623 dependent on the underlying best effort paths. 625 pLFA can be used as a method of converting classic LFA or RLFA to 626 full coverage by providing the paths that these methods are unable to 627 support, or to provide any the sub-paths needed to reduce the number 628 of TI-LFA SIDs. 630 9. Data-plane Considerations 632 This section is a survey of a number of data-planes in each case 633 considering how a PPR-ID could added to map the packet to required 634 FRR path. 636 9.1. Traditional IP 638 Where the data-plane is "traditional" IP the user packet needs to be 639 encapsulated such that the outer IP address is the PPR-ID. Any 640 preferred encapsulation can be used such as: IP in IP, IP in GRE, or 641 IP in UDP. 643 The tunnel capabilities of a node can be advertised using the method 644 described in [I-D.xu-isis-encapsulation-cap] allowing different 645 tunnel types to be used for different PPR paths, depending on the 646 capability of the various nodes in the network. 648 A common operational issue with this type of encapsulation for IPFRR 649 has been the shortage of IP addresses. However this is not an issue 650 in an IPv6 network. 652 9.2. Segment Routing over an IPv6 Data Plane (SRv6) 654 Where the data-plane is SRv6 [I-D.ietf-6man-segment-routing-header] 655 pLFA would be used to steer a packet towards the next segment end- 656 point. Clearly an extra level of IP encapsulation could be used 657 Section 9.1, but that expands the packet by adding at least 36 658 octets. 660 Where the packet is a "traditional" IP packet, and the repair end- 661 point is SRv6 capable, an alternative to the methods described in 662 Section 9.1 is to insert an SRH into the IP packet setting the SID in 663 the SRH to the original packet DA and replacing the outer DA with the 664 PPR-ID. If this method is used the semantics of the PPR-ID must 665 include the reconstruction of the packet, by replacing the DA with 666 the original DA retrieved from the SRH and the removal of the SRH. 668 9.3. MPLS 670 Where the data-plane is MPLS any encapsulation needed is tiny (a 671 label push), but the exact action depends on the repair strategy, and 672 there is the usual FRR problem of the setting of the new value for 673 the top label prior to pushing the PPR-ID label. 675 Where the FRR path terminates at an MPLS node other than the network 676 egress provider edge (PE) in the type of pLFA repair described in 677 Section 4, the original top label needed to be set to the label the 678 node was expecting. 680 Consider the network fragment shown in Figure 1. This is straight 681 forward case because node B swaps the top label the label it would 682 have used without the failure and then pushes the label that 683 corresponds to c'. If the repair strategy had been to exit Q-space 684 at the earliest opportunity for example at F, then B would have 685 needed to know what label F required to reach the destination. A 686 very similar problem occurs when a node repair is undertaken 687 Figure 3, where S needs to know the label that the next-next-hops 688 (S1, S2 and S3) need to reach the destination. 690 Where the traffic is being moved to a new path terminating at the 691 egress PE as shown in Figure 4, the problem much simpler and only 692 requires the swapping of the top label with the label that represents 693 d'. 695 10. Loop Free Convergence 697 Whilst IPFRR puts in place a temporary network repair, eventually the 698 network needs to re-converge around the surviving network components. 699 During this phase there is a danger that micro-loops will form and 700 disrupt the traffic flowing across the network. A similar problem 701 can occur when the failed component returns to service, or when a new 702 component is introduced into the network. [RFC5715] describes the 703 problem of loop-free convergence in detail and examines the methods 704 known at the time of its writing. Since that time [RFC8333] has 705 proposed a timer based loop mitigation (but not elimination) process, 706 and [I-D.ietf-rtgwg-segment-routing-ti-lfa] has proposed that by 707 making the IPFRR path congruent with the post convergence path loops 708 can be eliminated along the repair path. However whilst these 709 mitigation techniques address component failure, neither are targeted 710 at the repair/new component case. 712 These problems only effect best effort paths and path segments, fully 713 defined paths do not have this problem. 715 A network using pLFA is compatible with all of the know loop-free 716 convergence and loop mitigation approaches. 718 11. OAM Considerations 720 PPR may also be used in a way that provides an alternative to running 721 multi-hop BFD from ingress on a traffic engineered (TE) path with 722 reducing the complexities that arise from echo reply false alarms. 723 In this use case pLFA works by locally detecting the failure and 724 transferring the traffic to preferred TE backups which are in time 725 replaced by the newly computed TE paths to the same PPR-ID. 727 12. Privacy Considerations 729 As noted in Section 13 pLFA paths are constrained by the routing 730 domain and thus the traffic will be no more subject to observation 731 than it would in normal operation. Indeed PPR has the capability to 732 constrain the path of the traffic more tightly than other IPFRR 733 approaches. pLFA therefore does not reduce the privacy of user 734 traffic on the network. 736 13. Security Considerations 738 The security considerations of PPR are discussed in 739 [I-D.chunduri-lsr-isis-preferred-path-routing] which in turn refers 740 the reader to the security considerations of the underlying routing 741 protocol and the data-plane in use. The pLFA application of PPR to 742 IPFRR introduces no additional security regarding PPR itself. 744 General IPFRR security considerations are discussed in [RFC5714] and 745 these apply to this solution. 747 One further consideration, is the whether policy that applied to the 748 original path needs to be applied to the repair path. The decision 749 is operator and application specific, however pLFA is better than 750 some other IPFRR solution in that it is possible to precisely choose 751 the repair path. 753 IPFRR is deployed within the scope of the routing protocol that 754 underpins it which limits the security vulnerability. Furthermore it 755 is unlikely that IPFRR would be deployed outside a well managed 756 network. These restrictions in-turn significantly mitigate any 757 security threat. 759 14. IANA Considerations 761 This document makes no IANA requests. 763 15. References 765 15.1. Normative References 767 [I-D.ce-lsr-ppr-graph] 768 Chunduri, U. and T. Eckert, "Preferred Path Route Graph 769 Structure", draft-ce-lsr-ppr-graph-02 (work in progress), 770 May 2019. 772 [I-D.chunduri-lsr-isis-preferred-path-routing] 773 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 774 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 775 draft-chunduri-lsr-isis-preferred-path-routing-03 (work in 776 progress), May 2019. 778 15.2. Informative References 780 [I-D.bryant-ipfrr-tunnels] 781 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 782 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 783 (work in progress), November 2007. 785 [I-D.ietf-6man-segment-routing-header] 786 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 787 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 788 Routing Header (SRH)", draft-ietf-6man-segment-routing- 789 header-21 (work in progress), June 2019. 791 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 792 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 793 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 794 Camarillo, "Topology Independent Fast Reroute using 795 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 796 lfa-01 (work in progress), March 2019. 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, . 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, . 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, . 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, . 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 Uma Chunduri 869 Futurewei Technologies Inc 871 Email: uchundur@futurewei.com 872 Toerless Eckert 873 Futurewei Technologies Inc 875 Email: tte+ietf@cs.fau.de