idnits 2.17.1 draft-ietf-rtgwg-segment-routing-ti-lfa-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 (March 5, 2019) is 1879 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Adjacency' is mentioned on line 548, but not defined == Missing Reference: 'Node' is mentioned on line 548, but not defined == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-04 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Litkowski 3 Internet-Draft Orange 4 Intended status: Standards Track A. Bashandy 5 Expires: September 6, 2019 Individual 6 C. Filsfils 7 Cisco Systems 8 B. Decraene 9 Orange 10 P. Francois 11 INSA Lyon 12 D. Voyer 13 Bell Canada 14 F. Clad 15 P. Camarillo 16 Cisco Systems 17 March 5, 2019 19 Topology Independent Fast Reroute using Segment Routing 20 draft-ietf-rtgwg-segment-routing-ti-lfa-01 22 Abstract 24 This document presents Topology Independent Loop-free Alternate Fast 25 Re-route (TI-LFA), aimed at providing protection of node and 26 adjacency segments within the Segment Routing (SR) framework. This 27 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 28 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 29 (DLFA). It extends these concepts to provide guaranteed coverage in 30 any IGP network. A key aspect of TI-LFA is the FRR path selection 31 approach establishing protection over the expected post-convergence 32 paths from the point of local repair, dramatically reducing the 33 operational need to control the tie-breaks among various FRR options. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 6, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Conventions used in this document . . . . . . . . . . . . 7 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Intersecting P-Space and Q-Space with post-convergence paths 8 72 3.1. P-Space property computation for a resource X . . . . . . 8 73 3.2. Q-Space property computation for a link S-F, over post- 74 convergence paths . . . . . . . . . . . . . . . . . . . . 8 75 3.3. Q-Space property computation for a set of links adjacent 76 to S, over post-convergence paths . . . . . . . . . . . 9 77 3.4. Q-Space property computation for a node F, over post- 78 convergence paths . . . . . . . . . . . . . . . . . . . . 9 79 3.5. Scaling considerations when computing Q-Space . . . . . . 9 80 4. TI-LFA Repair Tunnel . . . . . . . . . . . . . . . . . . . . 9 81 4.1. FRR path using a direct neighbor . . . . . . . . . . . . 10 82 4.2. FRR path using a PQ node . . . . . . . . . . . . . . . . 10 83 4.3. FRR path using a P node and Q node that are adjacent . . 10 84 4.4. Connecting distant P and Q nodes along post-convergence 85 paths . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5. Protecting segments . . . . . . . . . . . . . . . . . . . . . 10 87 5.1. The active segment is a node segment . . . . . . . . . . 11 88 5.2. The active segment is an adjacency segment . . . . . . . 11 89 5.2.1. Protecting [Adjacency, Adjacency] segment lists . . . 11 90 5.2.2. Protecting [Adjacency, Node] segment lists . . . . . 12 91 5.3. Protecting SR policy midpoints against node failure . . . 13 92 5.3.1. Protecting {F, T, D} or {S->F, T, D} . . . . . . . . 13 93 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} . . . . . 14 94 6. TI-LFA and SR algorithms . . . . . . . . . . . . . . . . . . 15 95 7. Usage of Adjacency segments in the repair list . . . . . . . 16 96 8. Measurements on Real Networks . . . . . . . . . . . . . . . . 16 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 103 13.2. Informative References . . . . . . . . . . . . . . . . . 22 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 Segment Routing aims at supporting services with tight SLA guarantees 109 [RFC8402]. By relying on SR this document provides a local repair 110 mechanism for standard IGP shortest path capable of restoring end-to- 111 end connectivity in the case of a sudden directly connected failure 112 of a network component. Non-SR mechanisms for local repair are 113 beyond the scope of this document. Non-local failures are addressed 114 in a separate document [I-D.bashandy-rtgwg-segment-routing-uloop]. 116 The term topology independent (TI) refers to the ability to provide a 117 loop free backup path irrespective of the topologies used in the 118 network. This provides a major improvment compared to LFA 119 ([RFC5286]) and remote LFA ([RFC7490]) which cannot be applicable in 120 some topologies ([RFC6571]). 122 For each destination in the network, TI-LFA pre-installs a backup 123 forwarding entry for each protected destination ready to be activated 124 upon detection of the failure of a link used to reach the 125 destination. TI-LFA provides protection in the event of any one of 126 the following: single link failure, single node failure, or single 127 SRLG failure. In link failure mode, the destination is protected 128 assuming the failure of the link. In node protection mode, the 129 destination is protected assuming that the neighbor connected to the 130 primary link has failed. In SRLG protecting mode, the destination is 131 protected assuming that a configured set of links sharing fate with 132 the primary link has failed (e.g. a linecard or a set of links 133 sharing a common transmission pipe). 135 Protection techniques outlined in this document are limited to 136 protecting links, nodes, and SRLGs that are within a routing domain. 137 Protecting domain exit routers and/or links attached to another 138 routing domains are beyond the scope of this document 140 Thanks to SR, TI-LFA does not require the establishment of TLDP 141 sessions with remote nodes in order to take advantage of the 142 applicability of remote LFAs (RLFA) [RFC7490][RFC7916] or remote LFAs 143 with directed forwarding (DLFA)[RFC5714]. All the Segment 144 Identifiers (SIDs) are available in the link state database (LSDB) of 145 the IGP. As a result, preferring LFAs over RLFAs or DLFAs, as well 146 as minimizing the number of RLFA or DLFA repair nodes is not required 147 anymore. 149 Thanks to SR, there is no need to create state in the network in 150 order to enforce an explicit FRR path. This relieves the nodes 151 themselves from having to maintain extra state , and it relieves the 152 operator from having to deploy an extra protocol or extra protocol 153 sessions just to enhance the protection coverage. 155 [RFC7916] raised several operational considerations when using LFA or 156 remote LFA. [RFC7916] Section 3 presents a case where a high 157 bandwidth link between two core routers is protected through a PE 158 router connected with low bandwidth links. In such a case, 159 congestion may happen when the FRR backup path is activated. 160 [RFC7916] introduces a local policy framework to let the operator 161 tuning manually the best alternate election based on its own 162 requirements. 164 From a network capacity planning point of view, it is often assumed 165 that if a link L fails on a particular node X, the bandwidth consumed 166 on L will be spread over some of the remaining links of X. The 167 remaining links to be used are determined by the IGP routing 168 considering that the link L has failed (we assume that the traffic 169 uses the post-convergence path starting from the node X). In 170 Figure 1, we consider a network with all metrics equal to 1 except 171 the metrics on links used by PE1, PE2 and PE3 which are 1000. An 172 easy network capacity planning method is to consider that if the link 173 L (X-B) fails, the traffic actually flowing through L will be spread 174 over the remaining links of X (X-H, X-D, X-A). Considering the IGP 175 metrics, only X-H and X-D can only be used in reality to carry the 176 traffic flowing through the link L. As a consequence, the bandwidth 177 of links X-H and X-D is sized according to this rule. We should 178 observe that this capacity planning policy works, however it is not 179 fully accurate. 181 In Figure 1, considering that the source of traffic is only from PE1 182 and PE4, when the link L fails, depending on the convergence speed of 183 the nodes, X may reroute its forwarding entries to the remote PEs 184 onto X-H or X-D; however in a similar timeframe, PE1 will also 185 reroute a subset of its traffic (the subset destined to PE2) out of 186 its nominal path reducing the quantity of traffic received by X. The 187 capacity planning rule presented previously has the drawback of 188 oversizing the network, however it allows to prevent any transient 189 congestion (when for example X reroutes traffic before PE1 does). 191 H --- I --- J 192 | | \ 193 PE4 | | PE3 194 \ | (L) | / 195 A --- X --- B --- G 196 / | | \ 197 PE1 | | PE2 198 \ | | / 199 C --- D --- E --- F 201 Figure 1 203 Based on this assumption, in order to facilitate the operation of 204 FRR, and limit the implementation of local FRR policies, it looks 205 interesting to steer the traffic onto the post-convergence path from 206 the PLR point of view during the FRR phasis. In our example, when 207 link L fails, X switches the traffic destined to PE3 and PE2 on the 208 post-convergence paths. This is perfectly inline with the capacity 209 planning rule that was presented before and also inline with the fact 210 X may converge before PE1 (or any other upstream router) and may 211 spread the X-B traffic onto the post-convergence paths rooted at X. 213 It should be noted, that some networks may have a different capacity 214 planning rule, leading to an allocation of less bandwidth on X-H and 215 X-D links. In such a case, using the post-convergence paths rooted 216 at X during FRR may introduce some congestion on X-H and X-D links. 217 However it is important to note, that a transient congestion may 218 possibly happen, even without FRR activated, for instance when X 219 converges before the upstream routers. Operators are still free to 220 use the policy framework defined in [RFC7916] if the usage of the 221 post-convergence paths rooted at the PLR is not suitable. 223 Readers should be aware that FRR protection is pre-computing a backup 224 path to protect against a particular type of failure (link, node, 225 SRLG). When using the post-convergence path as FRR backup path, the 226 computed post-convergence path is the one considering the failure we 227 are protecting against. This means that FRR is using an expected 228 post-convergence path, and this expected post-convergence path may be 229 actually different from the post-convergence path used if the failure 230 that happened is different from the failure FRR was protecting 231 against. As an example, if the operator has implemented a protection 232 against a node failure, the expected post-convergence path used 233 during FRR will be the one considering that the node has failed. 234 However, even if a single link is failing or a set of links is 235 failing (instead of the full node), the node-protecting post- 236 convergence path will be used. The consequence is that the path used 237 during FRR is not optimal with respect to the failure that has 238 actually occured. 240 Another consideration to take into account is: while using the 241 expected post-convergence path for SR traffic using node segments 242 only (for instance, PE to PE traffic using shortest path) has some 243 advantages, these advantages reduce when SR policies 244 ([I-D.ietf-spring-segment-routing-policy]) are involved. A segment- 245 list used in an SR policy is computed to obey a set of path 246 constraints defined locally at the head-end or centrally in a 247 controller. TI-LFA cannot be aware of such path constraints and 248 there is no reason to expect the TI-LFA backup path protecting one 249 the segments in that segment list to obey those constraints. When SR 250 policies are used and the operator wants to have a backup path which 251 still follows the policy requirements, this backup path should be 252 computed as part of the SR policy in the ingress node (or central 253 controller) and the SR policy should not rely on local protection. 254 Another option could be to use FlexAlgo ([I-D.ietf-lsr-flex-algo]) to 255 express the set of constraints and use a single node segment 256 associated with a FlexAlgo to reach the destination. When using a 257 node segment associated with a FlexAlgo, TI-LFA keeps providing an 258 optimal backup by applying the appropriate set of constraints. The 259 relationship between TI-LFA and the SR-algorithm is detailled in 260 Section 6. 262 Thanks to SR and the combination of Adjacency segments and Node 263 segments, the expression of the expected post-convergence path rooted 264 at the PLR is facilitated and does not create any additional state on 265 intermediate nodes. The easiest way to express the expected post- 266 convergence path in a loop-free manner is to encode it as a list of 267 adjacency segments. However, in an MPLS world, this may create a 268 long stack of labels to be pushed that some hardware may not be able 269 to push. One of the challenges of TI-LFA is to encode the expected 270 post-convergence path by combining adjacency segments and node 271 segments. Each implementation will be free to have its own path 272 compression optimization algorithm. This document details the basic 273 concepts that could be used to build the SR backup path as well as 274 the associated dataplane procedures. 276 L ____ 277 S----F--{____}----D 278 /\ | / 279 | | | _______ / 280 |__}---Q{_______} 282 Figure 2: TI-LFA Protection 284 We use Figure 2 to illustrate the TI-LFA approach. 286 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 287 node) that is capable of safely forwarding the traffic to a 288 destination D affected by the failure of the protected link L, a set 289 of links including L (SRLG), or the node F itself. The PLR also 290 needs to find a way to reach Q without being affected by the 291 convergence state of the nodes over the paths it wants to use to 292 reach Q: the PLR needs a loop-free path to reach Q. 294 Section 2 defines the main notations used in the document. They are 295 in line with [RFC5714]. 297 Section 3 suggests to compute the P-Space and Q-Space properties 298 defined in Section 2, for the specific case of nodes lying over the 299 post-convergence paths towards the protected destinations. 301 Using the properties defined in Section 3, Section 4 describes how to 302 compute protection lists that encode a loop-free post- convergence 303 path towards the destination. 305 Section 5 defines the segment operations to be applied by the PLR to 306 ensure consistency with the forwarding state of the repair node. 308 By applying the algorithms specified in this document to actual 309 service providers and large enterprise networks, we provide real life 310 measurements for the number of SIDs used by repair paths. Section 8 311 summarizes these measurements. 313 1.1. Conventions used in this document 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 317 "OPTIONAL" in this document are to be interpreted as described in BCP 318 14 [RFC2119] [RFC8174] when, and only when, they appear in all 319 capitals, as shown here. 321 2. Terminology 323 We define the main notations used in this document as the following. 325 We refer to "old" and "new" topologies as the LSDB state before and 326 after the considered failure. 328 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 329 state of the network. 331 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the state 332 of the network after the resource X has failed. 334 PLR stands for "Point of Local Repair". It is the router that 335 applies fast traffic restoration after detecting failure in a 336 directly attached link, set of links, and/or node. 338 Similar to [RFC7490], we use the concept of P-Space and Q-Space for 339 TI- LFA. 341 The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, 342 a node F, or a SRLG) is the set of nodes that are reachable from R 343 without passing through X. It is the set of nodes that are not 344 downstream of X in SPT_old(R). 346 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 347 set of nodes that are reachable from R or a neighbor of R, without 348 passing through X. 350 The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is the 351 set of nodes which do not use X to reach D in the initial state of 352 the network. In other words, it is the set of nodes which have D in 353 their P-Space w.r.t. S-F, F, or a set of links adjacent to S). 355 A symmetric network is a network such that the IGP metric of each 356 link is the same in both directions of the link. 358 3. Intersecting P-Space and Q-Space with post-convergence paths 360 One of the challenges of defining an SR path following the expected 361 post-convergence path is to reduce the size of the segment list. In 362 order to reduce this segment list, an implementation MAY determine 363 the P-Space/Extended P-Space and Q-Space properties (defined in 364 [RFC7490]) of the nodes along the expected post-convergence path from 365 the PLR to the protected destination and compute an SR-based explicit 366 path from P to Q when they are not adjacent. Such properties will be 367 used in Section 4 to compute the TI-LFA repair list. 369 3.1. P-Space property computation for a resource X 371 A node N is in P(R, X) if it is not downstream of X in SPT_old(R). X 372 can be a link, a node, or a set of links adjacent to the PLR. A node 373 N is in P'(R,X) if it is not downstream of X in SPT_old(N), for at 374 least one neighbor N of R. 376 3.2. Q-Space property computation for a link S-F, over post-convergence 377 paths 379 We want to determine which nodes on the post-convergence path from 380 the PLR to the destination D are in the Q-Space of destination D 381 w.r.t. link S-F. 383 This can be found by intersecting the post-convergence path to D, 384 assuming the failure of S-F, with Q(D, S-F). 386 3.3. Q-Space property computation for a set of links adjacent to S, 387 over post-convergence paths 389 We want to determine which nodes on the post-convergence path from 390 the PLR to the destination D are in the Q-Space of destination D 391 w.r.t. a set of links adjacent to S (S being the PLR). That is, we 392 aim to find the set of nodes on the post-convergence path that use 393 none of the members of the protected set of links, to reach D. 395 This can be found by intersecting the post-convergence path to D, 396 assuming the failure of the set of links, with the intersection among 397 Q(D, S->X) for all S->X belonging to the set of links. 399 3.4. Q-Space property computation for a node F, over post-convergence 400 paths 402 We want to determine which nodes on the post-convergence from the PLR 403 to the destination D are in the Q-Space of destination D w.r.t. node 404 F. 406 This can be found by intersecting the post-convergence path to D, 407 assuming the failure of F, with Q(D, F). 409 3.5. Scaling considerations when computing Q-Space 411 [RFC7490] raises scaling concerns about computing a Q-Space per 412 destination. Similar concerns may affect TI-LFA computation if an 413 implementation tries to compute a reverse SPT for every destination 414 in the network to determine the Q-Space. It will be up to each 415 implementation to determine the good tradeoff between scaling and 416 accuracy of the optimization. 418 4. TI-LFA Repair Tunnel 420 The TI-LFA repair tunnel consists of an outgoing interface and a list 421 of segments (repair list) to insert on the SR header. The repair 422 list encodes the explicit post-convergence path to the destination, 423 which avoids the protected resource X and, at the same time, is 424 guaranteed to be loop-free irrespective of the state of FIBs along 425 the nodes belonging to the explicit path. Thus there is no need for 426 any co-ordination or message exchange between the PLR and any other 427 router in the network. 429 The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) 430 with the post-convergence path to D and computing the explicit SR- 431 based path EP(P, Q) from P to Q when these nodes are not adjacent 432 along the post convergence path. The TI-LFA repair list is expressed 433 generally as (Node_SID(P), EP(P, Q)). 435 Most often, the TI-LFA repair list has a simpler form, as described 436 in the following sections. Section 8 provides statistics for the 437 number of SIDs in the explicit path to protect against various 438 failures. 440 4.1. FRR path using a direct neighbor 442 When a direct neighbor is in P(S,X) and Q(D,x) and on the post- 443 convergence path, the outgoing interface is set to that neighbor and 444 the repair segment list MUST be empty. 446 This is comparable to a post-convergence LFA FRR repair. 448 4.2. FRR path using a PQ node 450 When a remote node R is in P(S,X) and Q(D,x) and on the post- 451 convergence path, the repair list MUST be made of a single node 452 segment to R and the outgoing interface MUST be set to the outgoing 453 interface used to reach R. 455 This is comparable to a post-convergence RLFA repair tunnel. 457 4.3. FRR path using a P node and Q node that are adjacent 459 When a node P is in P(S,X) and a node Q is in Q(D,x) and both are on 460 the post-convergence path and both are adjacent to each other, the 461 repair list MUST be made of two segments: A node segment to P (to be 462 processed first), followed by an adjacency segment from P to Q. 464 This is comparable to a post-convergence DLFA repair tunnel. 466 4.4. Connecting distant P and Q nodes along post-convergence paths 468 In some cases, there is no adjacent P and Q node along the post- 469 convergence path. However, the PLR can perform additional 470 computations to compute a list of segments that represent a loop-free 471 path from P to Q. How these computations are done is out of scope of 472 this document. 474 5. Protecting segments 476 In this section, we explain how a protecting router S processes the 477 active segment of a packet upon the failure of its primary outgoing 478 interface for the packet, S-F. 480 The behavior depends on the type of active segment to be protected. 482 5.1. The active segment is a node segment 484 The active segment MUST be kept on the SR header unchanged and the 485 repair list MUST be inserted at the head of the list. The active 486 segment becomes the first segment of the inserted repair list. 488 This behavior is slightly modified when SR-MPLS is used: 490 o If the repair list ends with an adjacency segment terminating on 491 the tail-end of the active segment, and if the active segment has 492 been signalled with penultimate hop popping, the active segment 493 MUST be popped before pushing the repair list. 495 o If the SRGB at the Q node is different from the SRGB at the PLR, 496 then the active segment (before the insertion of the repair list) 497 MUST be updated to fit the SRGB of the Q node. 499 In Section 5.3, we describe the node protection behavior of PLR S, 500 for the specific case where the active segment is a prefix segment 501 for the neighbor F itself. 503 5.2. The active segment is an adjacency segment 505 We define hereafter the FRR behavior applied by S for any packet 506 received with an active adjacency segment S-F for which protection 507 was enabled. As protection has been enabled for the segment S-F and 508 signalled in the IGP, any SR policy using this segment knows that it 509 may be transiently rerouted out of S-F in case of S-F failure. 511 We distinguish the case where this active segment is followed by 512 another adjacency segment from the case where it is followed by a 513 node segment. 515 5.2.1. Protecting [Adjacency, Adjacency] segment lists 517 If the next segment in the list is an Adjacency segment, then the 518 packet has to be conveyed to F. 520 To do so, S MUST apply a "NEXT" operation on Adj(S-F) and then two 521 consecutive "PUSH" operations: first it pushes a node segment for F, 522 and then it pushes a repair list allowing to reach F while bypassing 523 S-F. For details on the "NEXT" and "PUSH" operations, refer to 524 [RFC8402]. 526 Upon failure of S-F, a packet reaching S with a segment list matching 527 [adj(S-F),adj(F-M),...] will thus leave S with a segment list 528 matching [RT(F),node(F),adj(F-M)], where RT(F) is the repair tunnel 529 for destination F. 531 This behavior is slightly modified when SR-MPLS is used: 533 o If the repair list ends with an adjacency segment terminating on 534 F, and if the node segment of F has been signalled with 535 penultimate hop popping, the implementation MUST pop Adj(S-F) and 536 then push the repair list (the node segment of F is not pushed). 537 The packet will leave S with a segment list matching 538 [RT(F),adj(F-M)]. 540 o If the SRGB at the Q node is different from the SRGB at the PLR, 541 then MPLS label representing node(F) MUST be calculated as per the 542 SRGB of the Q node. 544 In Section 5.3.2, we describe the TI-LFA behavior of PLR S when node 545 protection is applied and the two first segments are Adjacency 546 Segments. 548 5.2.2. Protecting [Adjacency, Node] segment lists 550 If the next segment in the stack is a node segment, say for node T, 551 the segment list on the packet matches [adj(S-F),node(T),...]. 553 A first solution would consist in steering the packet back to F while 554 avoiding S-F. To do so, S MUST apply a "NEXT" operation on Adj(S-F) 555 and then two consecutive "PUSH" operations: first it pushes a node 556 segment for F, and then it pushes a repair list allowing to reach F 557 while bypassing S-F. 559 Upon failure of S-F, a packet reaching S with a segment list matching 560 [adj(S-F),node(T),...] will thus leave S with a segment list matching 561 [RT(F),node(F),node(T)]. 563 This behavior is slightly modified when SR-MPLS is used: 565 o If the repair list ends with an adjacency segment terminating on 566 F, and if the node segment of F has been signalled with 567 penultimate hop popping, the implementation MUST pop Adj(S-F) and 568 then push the repair list (the node segment of F is not pushed). 569 The packet will leave S with a segment list matching 570 [RT(F),node(T)]. 572 o If the SRGB at the Q node is different from the SRGB at the PLR, 573 then MPLS label representing node(F) MUST be calculated as per the 574 SRGB of the Q node. 576 Another solution is to not steer the packet back via F but rather 577 follow the new shortest path to T. In this case, S MUST apply a 578 "NEXT" operation on the Adjacency segment related to S-F, followed by 579 a "PUSH" of a repair list redirecting the traffic to a node Q, whose 580 path to node segment T is not affected by the failure. 582 Upon failure of S-F, packets reaching S with a segment list matching 583 [adj(S-F), node(T), ...], would leave S with a segment list matching 584 [RT(Q),node(T), ...]. Note that this second behavior is the one 585 followed for node protection, as described in Section 5.3.1. 587 This behavior is slightly modified when SR-MPLS is used: 589 o If the repair list ends with an adjacency segment terminating on T 590 (T being the Q node), and if the node segment of T has been 591 signalled with penultimate hop popping, the implementation MUST 592 pop Adj(S-F) and then push the repair list (the node segment of T 593 is not pushed). The packet will leave S with a segment list 594 matching [RT(Q=T), ...]. 596 o If the SRGB at the Q node is different from the SRGB at the PLR, 597 then the MPLS label representing node(T) MUST be calculated as per 598 the SRGB of the Q node. 600 The first proposal which merges back the traffic at the remote end of 601 the adjacency segment has the advantage of keeping as much as 602 possible the traffic on the existing path. As stated in Section 1, 603 when SR policies are involved and a strict compliance of the policy 604 is required, an end-to-end protection should be preferred over a 605 local repair mechanism. 607 5.3. Protecting SR policy midpoints against node failure 609 In this section, we describe the behavior of a node S configured to 610 interpret the failure of link S->F as the node failure of F, in the 611 specific case where the active segment of the packet received by S is 612 a Prefix SID of F represented as "F"), or an Adjacency SID for the 613 link S-F (represented as "S->F"). 615 5.3.1. Protecting {F, T, D} or {S->F, T, D} 617 This section describes the protection behavior of S when all of the 618 following conditions are true: 620 1. the active segment is a prefix SID for a neighbor F, or an 621 adjacency segment S->F 623 2. the primary interface used to forward the packet failed 624 3. the segment following the active segment is a prefix SID (for 625 node T) 627 4. node protection is active for that interface. 629 In such a case, the PLR MUST: 631 1. apply a NEXT operation; the segment F or S->F is removed 633 2. Confirm that the next segment is in the SRGB of F, meaning that 634 the next segment is a prefix segment, e.g. for node T 636 3. Retrieve the segment ID of T (as per the SRGB of F) 638 4. Apply a NEXT operation followed by a PUSH operation of T's 639 segment based on the SRGB of node S. 641 5. Look up T's segment (based on the updated label value) and 642 forward accordingly. 644 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 646 This section describes the protection behavior of S when all of the 647 following conditions are true: 649 1. the active segment is a prefix SID for a neighbor F, or an 650 adjacency segment S->F 652 2. the primary interface used to forward the packet failed 654 3. the segment following the active segment is an adjacency SID (F- 655 >T) 657 4. node protection is active for that interface. 659 In such a case, the PLR MUST: 661 1. Apply a NEXT operation; the segment F or S->F is removed 663 2. Confirm that the next segment is an adjacency SID of F, say F->T 665 3. Retrieve the node segment ID associated to T (as per the set of 666 Adjacency Segments of F) 668 4. Apply a NEXT operation on the next segment followed by a PUSH of 669 T's segment based on the SRGB of the node S. 671 5. Look up T's segment (based on the updated label value) and 672 forward accordingly. 674 It is noteworthy to mention that node "S" in the procedures described 675 in Sections 5.3.1 and 5.3.2 can always determine whether the segment 676 after popping the top segment is an adjacency SID or a prefix-SID of 677 the next-hop "F" as follows: 679 1. In a link state environment, the node "S" knows the SRGB and the 680 adj-SIDs of the neighboring node "F" 682 2. If the new segment after popping the top segment is within the 683 SRGB or the adj-SIDs of "F", then node "S" is certain that the 684 failure of node "F" is a midpoint failure and hence node "S" 685 applies the procedures specified in Sections 5.3.1 or 5.3.2, 686 respectively. 688 3. Otherwise the failure is not a midpoint failure and hence the 689 node "S" may apply other protection techniques that are beyond 690 the scope of this document or simply drop the packet and wait for 691 normal protocol convergence. 693 6. TI-LFA and SR algorithms 695 SR allows an operator to bind an algorithm to a prefix SID (as 696 defined in [RFC8402]. The algorithm value dictates how the path to 697 the prefix is computed. The SR default algorithm is known has the 698 "Shortest Path" algorithm. The SR default algorithm allows an 699 operator to override the IGP shortest path by using local policies. 700 When TI-LFA uses Node-SIDs associated with the default algorithm, 701 there is no guarantee that the path will be loop-free as a local 702 policy may have overriden the expected IGP path. As the local 703 policies are defined by the operator, it becomes the responsibility 704 of this operator to ensure that the deployed policies do not affect 705 the TI-LFA deployment. It should be noted that such situation can 706 already happen today with existing mechanisms as remote LFA. 708 When a Node-SID is associated with the SR default algorithm, 709 enforcing TI-LFA to use Node-SIDs associated with a strict SPF 710 algorithm is a definitive solution to this problem. 712 [I-D.ietf-lsr-flex-algo] defines a flexible algorithm (FlexAlgo) 713 framework to be associated with Prefix SIDs. FlexAlgo allows a user 714 to associate a constrained path to a Prefix SID rather than using the 715 regular IGP shortest path. An implementation MAY support TI-LFA to 716 protect Node-SIDs associated to a FlexAlgo. In such a case, rather 717 than computing the expected post-convergence path based on the 718 regular SPF, an implementation SHOULD use the constrained SPF 719 algorithm bound to the FlexAlgo instead of the regular Dijkstra in 720 all the SPF/rSPF computations that are occurring during the TI-LFA 721 computation. This includes the computation of the P-Space and 722 Q-Space as well as the post-convergence path. 724 7. Usage of Adjacency segments in the repair list 726 The repair list of segments computed by TI-LFA may contain one or 727 more adjacency segments. An adjacency segment may be protected or 728 not protected. 730 S --- R2 --- R3 --- R4 --- R5 --- D 731 \ | \ / 732 R7 -- R8 733 | | 734 R9 -- R10 736 Figure 3 738 In Figure 3, all the metrics are equal to 1 except 739 R2-R7,R7-R8,R8-R4,R7-R9 which have a metric of 1000. Considering R2 740 as a PLR to protect against the failure of node R3 for the traffic 741 S->D, the repair list computed by R2 will be [adj(R7-R8),adj(R8-R4)] 742 and the outgoing interface will be to R7. If R3 fails, R2 pushes the 743 repair list onto the incoming packet to D. During the FRR, if R7-R8 744 fails and if TI-LFA has picked a protected adjacency segment for 745 adj(R7-R8), R7 will push an additional repair list onto the packet 746 following the procedures defined in Section 5. 748 To avoid the possibility of this double FRR, an implementation of TI- 749 LFA MAY pick only non protected adjacency segments when building the 750 repair list. 752 8. Measurements on Real Networks 754 This section presents measurements performed on real service provider 755 and large enterprise networks. The objective of the measurements is 756 to assess the number of SIDs required in an explicit path when the 757 mechanism described in this document are used to protect against the 758 failure scenarios within the scope of this document. The number of 759 segments described in this section are applicable to instantiating 760 segment routing over the MPLS forwarding plane. 762 The measurements below indicate that for link and local SRLG 763 protection, a 1 SID repair path delivers more than 99% coverage. For 764 node protection a 2 SIDs repair path yields 99% coverage. 766 Table 1 below lists the characteristics of the networks used in our 767 measurements. The measurements are carried out as follows 769 o For each network, the algorithms described in this document are 770 applied to protect all prefixes against link, node, and local SRLG 771 failure 773 o For each prefix, the number of SIDs used by the repair path is 774 recored 776 o The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, 777 and 4A/B 779 The measurements listed in the tables indicate that for link and 780 local SRLG protection, 1 SID repair paths are sufficient to protect 781 more than 99% of the prefix in almost all cases. For node protection 782 2 SIDs repair paths yield 99% coverage. 784 +-------------+------------+------------+------------+------------+ 785 | Network | Nodes | Circuits |Node-to-Link| SRLG info? | 786 | | | | Ratio | | 787 +-------------+------------+------------+------------+------------+ 788 | T1 | 408 | 665 | 1 : 63 | Yes | 789 +-------------+------------+------------+------------+------------+ 790 | T2 | 587 | 1083 | 1 : 84 | No | 791 +-------------+------------+------------+------------+------------+ 792 | T3 | 93 | 401 | 4 : 31 | Yes | 793 +-------------+------------+------------+------------+------------+ 794 | T4 | 247 | 393 | 1 : 59 | Yes | 795 +-------------+------------+------------+------------+------------+ 796 | T5 | 34 | 96 | 2 : 82 | Yes | 797 +-------------+------------+------------+------------+------------+ 798 | T6 | 50 | 78 | 1 : 56 | No | 799 +-------------+------------+------------+------------+------------+ 800 | T7 | 82 | 293 | 3 : 57 | No | 801 +-------------+------------+------------+------------+------------+ 802 | T8 | 35 | 41 | 1 : 17 | Yes | 803 +-------------+------------+------------+------------+------------+ 804 | T9 | 177 | 1371 | 7 : 74 | Yes | 805 +-------------+------------+------------+------------+------------+ 806 Table 1: Data Set Definition 808 The rest of this section presents the measurements done on the actual 809 topologies. The convention that we use is as follows 811 o 0 SIDs: the calculated repair path starts with a directly 812 connected neighbor that is also a loop free alternate, in which 813 case there is no need to explicitly route the traffic using 814 additional SIDs. This scenario is described in Section 4.1. 816 o 1 SIDs: the repair node is a PQ node, in which case only 1 SID is 817 needed to guarantee loop-freeness. This scenario is covered in 818 Section 4.2. 820 o 2 or more SIDs: The repair path consists of 2 or more SIDs as 821 described in Sections 4.3 and 4.4. We do not cover the case for 2 822 SIDs (Section 4.3) separately because there was no granularity in 823 the result. Also we treat the node-SID+adj-SID and node-SID + 824 node-SID the same because they do not differ from the data plane 825 point of view. 827 Table 2A and 2B below summarize the measurements on the number of 828 SIDs needed for link protection 830 +-------------+------------+------------+------------+------------+ 831 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 832 +-------------+------------+------------+------------+------------+ 833 | T1 | 74.227% | 25.256% | 0.517% | 0.001% | 834 +-------------+------------+------------+------------+------------+ 835 | T2 | 81.097% | 18.738% | 0.165% | 0.0% | 836 +-------------+------------+------------+------------+------------+ 837 | T3 | 95.878% | 4.067% | 0.056% | 0.0% | 838 +-------------+------------+------------+------------+------------+ 839 | T4 | 62.547% | 35.666% | 1.788% | 0.0% | 840 +-------------+------------+------------+------------+------------+ 841 | T5 | 85.733% | 14.267% | 0.0% | 0.0% | 842 +-------------+------------+------------+------------+------------+ 843 | T6 | 81.252% | 18.714% | 0.033% | 0.0% | 844 +-------------+------------+------------+------------+------------+ 845 | T7 | 98,857% | 1.143% | 0.0% | 0.0% | 846 +-------------+------------+------------+------------+------------+ 847 | T8 | 94,118% | 5.882% | 0.0% | 0.0% | 848 +-------------+------------+------------+------------+------------+ 849 | T9 | 98.950% | 1.050% | 0.0% | 0.0% | 850 +-------------+------------+------------+------------+------------+ 851 Table 2A: Link protection (repair size distribution) 853 +-------------+------------+------------+------------+------------+ 854 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 855 +-------------+------------+------------+------------+------------+ 856 | T1 | 74.227% | 99.482% | 99.999% | 100.0% | 857 +-------------+------------+------------+------------+------------+ 858 | T2 | 81.097% | 99.835% | 100.0% | 100.0% | 859 +-------------+------------+------------+------------+------------+ 860 | T3 | 95.878% | 99.944% | 100.0% | 100.0% | 861 +-------------+------------+------------+------------+------------+ 862 | T4 | 62.547% | 98.212% | 100.0% | 100.0% | 863 +-------------+------------+------------+------------+------------+ 864 | T5 | 85.733% | 100.000% | 100.0% | 100.0% | 865 +-------------+------------+------------+------------+------------+ 866 | T6 | 81.252% | 99.967% | 100.0% | 100.0% | 867 +-------------+------------+------------+------------+------------+ 868 | T7 | 98,857% | 100.000% | 100.0% | 100.0% | 869 +-------------+------------+------------+------------+------------+ 870 | T8 | 94,118% | 100.000% | 100.0% | 100.0% | 871 +-------------+------------+------------+------------+------------+ 872 | T9 | 98,950% | 100.000% | 100.0% | 100.0% | 873 +-------------+------------+------------+------------+------------+ 874 Table 2B: Link protection repair size cumulative distribution 875 Table 3A and 3B summarize the measurements on the number of SIDs 876 needed for local SRLG protection. 878 +-------------+------------+------------+------------+------------+ 879 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 880 +-------------+------------+------------+------------+------------+ 881 | T1 | 74.177% | 25.306% | 0.517% | 0.001% | 882 +-------------+------------+------------+------------+------------+ 883 | T2 | No SRLG Information | 884 +-------------+------------+------------+------------+------------+ 885 | T3 | 93.650% | 6.301% | 0.049% | 0.0% | 886 +-------------+------------+------------+------------+------------+ 887 | T4 | 62,547% | 35.666% | 1.788% | 0.0% | 888 +-------------+------------+------------+------------+------------+ 889 | T5 | 83.139% | 16.861% | 0.0% | 0.0% | 890 +-------------+------------+------------+------------+------------+ 891 | T6 | No SRLG Information | 892 +-------------+---------------------------------------------------+ 893 | T7 | No SRLG Information | 894 +-------------+------------+------------+------------+------------+ 895 | T8 | 85.185% | 14.815% | 0.0% | 0.0% | 896 +-------------+------------+------------+------------+------------+ 897 | T9 | 98,940% | 1.060% | 0.0% | 0.0% | 898 +-------------+------------+------------+------------+------------+ 899 Table 3A: Local SRLG protection repair size distribution 901 +-------------+------------+------------+------------+------------+ 902 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 903 +-------------+------------+------------+------------+------------+ 904 | T1 | 74.177% | 99.482% | 99.999% | 100.001% | 905 +-------------+------------+------------+------------+------------+ 906 | T2 | No SRLG Information | 907 +-------------+------------+------------+------------+------------+ 908 | T3 | 93.650% | 99.951% | 100.000% | 0.0% | 909 +-------------+------------+------------+------------+------------+ 910 | T4 | 62,547% | 98.212% | 100.000% | 100.0% | 911 +-------------+------------+------------+------------+------------+ 912 | T5 | 83.139% | 100.000% | 100.0% | 100.0% | 913 +-------------+------------+------------+------------+------------+ 914 | T6 | No SRLG Information | 915 +-------------+---------------------------------------------------+ 916 | T7 | No SRLG Information | 917 +-------------+------------+------------+------------+------------+ 918 | T8 | 85.185% | 100,000% | 100.000% | 100.0% | 919 +-------------+------------+------------+------------+------------+ 920 | T9 | 98,940% | 100,000% | 100.000% | 100.0% | 921 +-------------+------------+------------+------------+------------+ 922 Table 3B: Local SRLG protection repair size Cumulative distribution 923 The remaining two tables summarize the measurements on the number of 924 SIDs needed for node protection. 926 +---------+----------+----------+----------+----------+----------+ 927 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 928 +---------+----------+----------+----------+----------+----------+ 929 | T1 | 49.771% | 47.902% | 2.156% | 0.148% | 0.023% | 930 +---------+----------+----------+----------+----------+----------+ 931 | T2 | 36,528% | 59.625% | 3.628% | 0.194% | 0.025% | 932 +---------+----------+----------+----------+----------+----------+ 933 | T3 | 73,287% | 25,574% | 1,128% | 0.010% | 0% | 934 +---------+----------+----------+----------+----------+----------+ 935 | T4 | 36.112% | 57.350% | 6.329% | 0.199% | 0.010% | 936 +---------+----------+----------+----------+----------+----------+ 937 | T5 | 73.185% | 26.815% | 0% | 0% | 0% | 938 +---------+----------+----------+----------+----------+----------+ 939 | T6 | 78.362% | 21.320% | 0.318% | 0% | 0% | 940 +---------+----------+----------+----------+----------+----------+ 941 | T7 | 66.106% | 32.813% | 1.082% | 0% | 0% | 942 +---------+----------+----------+----------+----------+----------+ 943 | T8 | 59.712% | 40.288% | 0% | 0% | 0% | 944 +---------+----------+----------+----------+----------+----------+ 945 | T9 | 98.950% | 1.050% | 0% | 0% | 0% | 946 +---------+----------+----------+----------+----------+----------+ 947 Table 4A: Node protection (repair size distribution) 949 +---------+----------+----------+----------+----------+----------+ 950 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 951 +---------+----------+----------+----------+----------+----------+ 952 | T1 | 49.771% | 97.673% | 99.829% | 99.977% | 100% | 953 +---------+----------+----------+----------+----------+----------+ 954 | T2 | 36,528% | 96.153% | 99.781% | 99.975% | 100% | 955 +---------+----------+----------+----------+----------+----------+ 956 | T3 | 73,287% | 98.862% | 99.990% |100.0% | 100% | 957 +---------+----------+----------+----------+----------+----------+ 958 | T4 | 36.112% | 93.461% | 99.791% | 99.990% | 100% | 959 +---------+----------+----------+----------+----------+----------+ 960 | T5 | 73.185% | 100.0% | 100.0% |100.0% | 100% | 961 +---------+----------+----------+----------+----------+----------+ 962 | T6 | 78.362% | 99.682% | 100.0% |100.0% | 100% | 963 +---------+----------+----------+----------+----------+----------+ 964 | T7 | 66.106% | 98,918% | 100.0% |100.0% | 100% | 965 +---------+----------+----------+----------+----------+----------+ 966 | T8 | 59.712% | 100.0% | 100.0% |100.0% | 100% | 967 +---------+----------+----------+----------+----------+----------+ 968 | T9 | 98.950% | 100.0% | 100.0% |100.0% | 100% | 969 +---------+----------+----------+----------+----------+----------+ 970 Table 4B: Node protection (repair size cumulative distribution) 972 9. Security Considerations 974 The techniques described in this document are internal 975 functionalities to a router that result in the ability to guarantee 976 an upper bound on the time taken to restore traffic flow upon the 977 failure of a directly connected link or node. As these techniques 978 steer traffic to the post-convergence path as quickly as possible, 979 this serves to minimize the disruption associated with a local 980 failure which can be seen as a modest security enhancement. The 981 protection mechanisms does not protect external destinations, but 982 rather provides quick restoration for destination that are internal 983 to a routing domain. 985 10. IANA Considerations 987 No requirements for IANA 989 11. Conclusions 991 This document proposes a mechanism that is able to pre-calculate a 992 backup path for every primary path so as to be able to protect 993 against the failure of a directly connected link, node, or SRLG. The 994 mechanism is able to calculate the backup path irrespective of the 995 topology as long as the topology is sufficiently redundant. 997 12. Acknowledgments 999 We would like to thank Les Ginsberg, Stewart Bryant, Alexander 1000 Vainsthein, Chris Bowers for their valuable comments. 1002 13. References 1004 13.1. Normative References 1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1007 Requirement Levels", BCP 14, RFC 2119, 1008 DOI 10.17487/RFC2119, March 1997, 1009 . 1011 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 1012 Horneffer, M., and P. Sarkar, "Operational Management of 1013 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 1014 July 2016, . 1016 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1017 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1018 May 2017, . 1020 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1021 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1022 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1023 July 2018, . 1025 13.2. Informative References 1027 [I-D.bashandy-rtgwg-segment-routing-uloop] 1028 Bashandy, A., Filsfils, C., Litkowski, S., and P. 1029 Francois, "Loop avoidance using Segment Routing", draft- 1030 bashandy-rtgwg-segment-routing-uloop-04 (work in 1031 progress), September 2018. 1033 [I-D.ietf-lsr-flex-algo] 1034 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1035 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1036 algo-01 (work in progress), November 2018. 1038 [I-D.ietf-spring-segment-routing-policy] 1039 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1040 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1041 Policy Architecture", draft-ietf-spring-segment-routing- 1042 policy-02 (work in progress), October 2018. 1044 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1045 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1046 DOI 10.17487/RFC5286, September 2008, 1047 . 1049 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1050 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1051 . 1053 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 1054 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 1055 Alternate (LFA) Applicability in Service Provider (SP) 1056 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 1057 . 1059 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1060 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 1061 RFC 7490, DOI 10.17487/RFC7490, April 2015, 1062 . 1064 Authors' Addresses 1066 Stephane Litkowski 1067 Orange 1068 France 1070 Email: stephane.litkowski@orange.com 1072 Ahmed Bashandy 1073 Individual 1075 Email: abashandy.ietf@gmail.com 1077 Clarence Filsfils 1078 Cisco Systems 1079 Brussels 1080 Belgium 1082 Email: cfilsfil@cisco.com 1084 Bruno Decraene 1085 Orange 1086 Issy-les-Moulineaux 1087 France 1089 Email: bruno.decraene@orange.com 1090 Pierre Francois 1091 INSA Lyon 1093 Email: pierre.francois@insa-lyon.fr 1095 Daniel Voyer 1096 Bell Canada 1097 Canada 1099 Email: daniel.voyer@bell.ca 1101 Francois Clad 1102 Cisco Systems 1104 Email: fclad@cisco.com 1106 Pablo Camarillo 1107 Cisco Systems 1109 Email: pcamaril@cisco.com