idnits 2.17.1 draft-ietf-spring-node-protection-for-sr-te-paths-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 (September 21, 2020) is 1310 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1000-2000' is mentioned on line 236, but not defined == Missing Reference: '3000-4000' is mentioned on line 236, but not defined -- Looks like a reference, but probably isn't: '1100' on line 191 -- Looks like a reference, but probably isn't: '1005' on line 191 == Unused Reference: 'RFC2119' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft C. Bowers 4 Intended status: Informational Juniper Networks Inc. 5 Expires: March 25, 2021 S. Litkowski 6 Cisco Systems 7 X. Xu 8 Alibaba Inc. 9 F. Xu 10 Tencent 11 September 21, 2020 13 Node Protection for SR-TE Paths 14 draft-ietf-spring-node-protection-for-sr-te-paths-00 16 Abstract 18 Segment routing supports the creation of explicit paths using 19 adjacency-sids, node-sids, and binding-sids. It is important to 20 provide fast reroute (FRR) mechanisms to respond to failures of links 21 and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A 22 point of local repair (PLR) can provide FRR protection against the 23 failure of a link in an SR-TE path by examining only the first (top) 24 label in the SR label stack. In order to protect against the failure 25 of a node, a PLR may need to examine the second label in the stack as 26 well, in order to determine SR-TE path beyond the failed node. This 27 document specifies how a PLR can use the first and second label in 28 the label stack describing an SR-TE path to provide protection 29 against node failures. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 25, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3 67 2.1. Node protection for node-sid explicit paths . . . . . . . 3 68 2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4 69 2.3. Node-protection for adj-sid explicit paths . . . . . . . 5 70 3. Detailed Solution using Context Tables . . . . . . . . . . . 6 71 3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6 72 3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7 73 3.3. Node protection for adjacency SIDs . . . . . . . . . . . 8 74 3.4. Node protection for edge nodes . . . . . . . . . . . . . 9 75 4. Hold timers for Node-SID/Prefix-SIDs and Adjacency-SIDs . . . 10 76 4.1. Interaction with micro-loop avoidance . . . . . . . . . . 10 77 5. Optimization Considerations . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 It is possible for a routing device to completely go out of service 89 abruptly due to power failure, hardware failure or software crashes. 90 Node protection is an important property of the Fast Reroute 91 mechanism. It provides protection against a node failure by 92 rerouting traffic around the failed node. For example, the 93 mechanisms described in Loop Free Alternates ([RFC5286]), Remote Loop 94 Free Alternates ([RFC8102]), and 96 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] can be used to provide 97 node protection to ensure minimal traffic loss after a node failure. 99 Section 2 describes problems with SR-TE paths and the need for a 100 specialized mechanism to provide node protection for SR-TE paths. 101 Section 3 describes the solution applied to paths built using 102 adjacency-sids and node-sids. 104 2. Node Failures Along SR-TE Paths 106 The topology shown in Figure 1. illustrates a example network 107 topology with SPRING enabled on each node. 109 Node Node Node Node Node 110 sid:1 sid:2 sid:3 sid:4 sid:5 111 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 112 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 113 +----+ +----+ +----+ +----+ +----+ 114 \ \ / 115 \ 10 \ 100 / 60 116 \ \ / 117 \ +----+ +----+ 118 +--| R7 |------------------| R8 | 119 +----+ 30 +----+ 120 / Node Node Label stack: 121 / sid:7 sid:8 +------------+ 122 +----+ SRGB: | 1008 (top)| 123 | R6 | 3000-4000 +------------+ 124 +----+ | 3005 | 125 Node +------------+ 126 sid:6 128 Figure 1: Example topology. The segment index for each node is shown 129 in the diagram. All nodes have SRGB = [1000-2000], except for R8 130 which has SRGB = [3000-4000]. A label stack that represents the path 131 R1->R7->R8->R4->R5 is shown as well. 133 2.1. Node protection for node-sid explicit paths 135 Consider an explicit path in the topology in Figure 1 from R1->R5 via 136 R1->R7->R8->R4->R5. This path can be built using the shortest paths 137 from R1-to-R8 and R8-to-R5. The label stack to instantiate this path 138 contains two node-sids 1008 and 3005. The 1008 label will take the 139 packet from R1 to R8 via R7 and get popped. The next label in the 140 stack 3005 will take the packet from R8 to the destination R5 via R4. 141 If the node R8 goes down, it is not possible for R7 to perform FRR 142 without examining the second label in the incoming label stack 143 (3005). 145 Note that in the absence of a failure, R7 does not need to understand 146 the meaning of the second label (3005) in order to perform normal 147 forwarding. However, in order to support node protection, R7 will 148 need to understand the meaning of label 3005 in order to determine 149 where the packet is headed after R8. 151 The mechanisms used to detect whether a node failed or a link failed, 152 is outside the scope of this document. The possible options for node 153 failure detection capabilities of a device and resultant forwarding 154 state is described in section 5.2 in [RFC8679] are applicable to this 155 draft as well. 157 2.2. Node-Protection for Anycast-SIDs 159 A prefix segment advertised as a node SID may only be advertised by 160 one node in the network. Instead, an anycast prefix segment may be 161 advertised by more than one node. In some situations, one can use 162 anycast SIDs to construct SR-TE paths that are protected against node 163 failure, without the need for the mechanism described in this 164 document. 166 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 167 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 168 +----+ +----+ +----+ +----+ +----+ 169 \ \ / | 170 \ 10 \100 60/ | 171 \ \ / | 172 \ +----+ 30 +----+ | 173 +--| R7 |------------------| R8 | | 174 +----+ +----+ | 175 / \ Anycast + 176 / \ sid:100 / 177 +----+ \ / 178 | R6 | \ 40 +----+ /60 179 +----+ +---------------| R9 |+ Label stack: 180 +----+ +------------+ 181 Anycast | 1100 (top)| 182 sid:100 +------------+ 183 | 1005 | 184 +------------+ 186 Figure 2: Topology illustrating use of anycast-sids to protect 187 against node failures. All nodes have SRGB = [1000-2000]. 189 An example of this is shown in Figure 2. In this example, R8 and R9 190 advertise an anycast SID of 100. The label stack in this example = 191 [1100, 1005];. The top label (1100) corresponds to the anycast SID 192 advertised by both R8 and R9. In the absence of a failure, the 193 packet sent by R1 with this label stack will follow the path from 194 R1->R5 along R1->R7->R8->R4->R5. 196 If R7 is performing a per-prefix LFA calculation [RFC5286], then R7 197 will install a backup next-hop to R9 for this anycast SID, protecting 198 against the failure of the primary next-hop to R8. This backup path 199 does not pass through R8, so it is would not be affected by a 200 complete failure of node R8. As illustrated by this example, for 201 some topologies node-protecting SR-TE paths can be constructed 202 through the use of anycast SIDs, as opposed to the mechanism 203 described in this document. 205 2.3. Node-protection for adj-sid explicit paths 207 Adj-sid: 208 R3-R8:9044 210 Node Node Node Node Node 211 sid:1 sid:2 sid:3 sid:4 sid:5 212 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 213 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 214 +----+ +----+ +----+ +----+ +----+ 215 \ \ / | 216 \ 10 \ 100 / 60 | 10 217 \ \ / | 218 \ +----+ +----+ +----+ 219 +--| R7 |------------------| R8 |---------------| R9 | 220 +----+ 30 +----+ 10 +----+ 221 / Node Node Node 222 / sid:7 sid:8 sid:9 223 +----+ SRGB: 224 | R6 | 3000-4000 Label stack: 225 +----+ +------------+ 226 Node Adj-sids: | 1003 (top)| 227 sid:6 R8-R4:9054 +------------+ 228 | 9044 | 229 +------------+ 230 | 9054 | 231 +------------+ 232 | 1005 | 233 +------------+ 235 Figure 3: Explicit path using an adjacency sid. All nodes have SRGB 236 = [1000-2000], except for R8 which has SRGB = [3000-4000]. 238 Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5. 239 This path can be built using a combination of node sids and adjacency 240 sids, as shown in Figure 3. The diagram shows the label stack needed 241 to instantiate this path, as well as several adjacency sids 242 advertised by nodes involved in this path. When a packet leaving R1 243 with this label stack reaches R3, the top label is 9044, which will 244 take the packet to R8. The next-next-hop in the path is R4. To 245 provide protection for the failure of node R8, R3 would need to send 246 the the packet to R4 without going through R8. However, the only way 247 R3 can learn that the packet needs to go to the R4 is to examine the 248 next label in the stack, label 9054. Since R3 knows that R8 has 249 advertised label 9054 as the adjacency segment for the link from R8 250 to R4, R3 knows that a backup path can merge back into the original 251 explicit path at R4. 253 3. Detailed Solution using Context Tables 255 This section provides a detailed description of how to construct 256 node-protecting backup paths for SR-TE paths using context tables. 257 The end result of this description is externally visible forwarding 258 behavior that can be specified as a packet arriving at a PLR with a 259 particular incoming label stack and leaving the PLR on a particular 260 outgoing interface with a particular outgoing label stack. There may 261 be other methods of arriving at the same externally visible 262 forwarding behavior as described in draft 263 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. It is not the intent of 264 this document to exclude other methods, as long as the externally 265 visible forwarding behavior is the same as produced by this method. 267 3.1. Building Context Tables 269 [RFC5331] introduced the concept of Context Specific Label Spaces and 270 there are various applications making use of this concept.A context 271 label table on a router represents the Label Forwarding Information 272 Base (LFIB) from the point of view of a particular neighbor . Context 273 tables are built by constructing incoming label mappings advertised 274 by the neighbor and the actions corresponding to those labels. The 275 labels advertised by each node are local to the node and may not be 276 unique across the segment routing domain. The context tables are 277 separate tables built on a per-neighbor basis on every node to ensure 278 they represent LFIBs of a particular neighbor. 280 When a PLR needs to protect an SR-TE path against the failure of a 281 neighbor N, it creates a context table associated with N. This 282 context table is populated with the following segment routing 283 forwarding entries: 285 - All the Prefix-SIDs of the network. The programmed incoming 286 label map uses the SRGB of N to compute the input label value. 287 The NHLFE (Next Hop Label Forwarding Entry) is then constructed by 288 looking into all the nexthops for the prefix-SID and choosing a 289 loop-free path as explained in Section 3.2 291 - All the Adjacency SIDs advertised by N. The NHLFE is 292 constructed as explained in Section 3.3 294 The following section illustrates how the context table is 295 constructed to allow the PLR to provide node-protecting paths for the 296 next-next hops in the topology shown in Figure 1 and Figure 3. 298 3.2. Node protection for node SIDs 300 Figure 4 shows the routing table entries on R7 corresponding to the 301 node SIDs to reach R1 and R8 for the topology in Figure 1. In the 302 absence of a failure, a packet with a label stack whose top label is 303 1008 will have its top label popped by R7 (assuming PHP behavior), 304 and R7 will forward the packet to R8. When the interface to R8 is 305 down, the backup next-hop entry is used. R7 will pop the top label 306 of 1008, and use the context table that R7 computed for R8 to 307 evaluate the next label on the stack. 309 R7's Routing Table (partial) 310 Transits routes for Node SIDs for R1 and R8 311 +=============+=============================================+ 312 | In label | Outgoing label action | 313 +=============+=============================================+ 314 | 1001 | Primary: pop, fwd to R1 | 315 | | Backup: pop, lookup context.r1 | 316 +-------------+---------------------------------------------+ 317 | 1008 | Primary: pop, fwd to R8 | 318 | | Backup: pop, lookup context.r8 | 319 +-------------+---------------------------------------------+ 321 R7's Context Table for R8 (context.r8, partial) 322 +=============+=============================================+ 323 | In label | Outgoing label action | 324 +=============+=============================================+ 325 | 3004 | swap 1004, fwd to R1 | 326 +-------------+---------------------------------------------+ 327 | 3005 | swap 1005, fwd to R1 | 328 +-------------+---------------------------------------------+ 329 | 3008 | drop | 330 +-------------+---------------------------------------------+ 332 Figure 4: Building node-protecting backup paths for SR-TE paths 333 involving node SIDs 335 R7 builds context table for R8 using the following process. R7 336 computes the mapping of incoming label to node-sid that R8 expects to 337 see based on the SRGB advertised by R8. In the example in Figure 1, 338 R7 can determine that R8 interprets in incoming label of 3005 as 339 mapping to the the node SID for R5. 341 R7 then computes a loop-free backup path to reach R5 which is node- 342 protecting with respect to the failure of R8. In this example, the 343 backup path computed by R7 to reach R5 without passing through R8 can 344 be achieved forwarding the packet to R1 with a top label of 1005, 345 corresponding to the node SID for R5 in the context of R1's SRGB. 346 The loop-free path computation may be based on a mechanism such as 347 LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure. To 348 populate the context table for R8, R7 maps the out label actions 349 corresponding to the backup path to R5 to the incoming label 3005. 350 This results in the entry for label 3005 showin in context.r8 in 351 Figure 4. 353 Therefore, when a packet arrives at R7 with label stack = [1008, 354 3005], and the link from R7 to R8 has recently failed, R7 will use 355 backup next-hop entry for label 1008 in its main routing table. 356 Based on this entry, R7 will pop label 1008, and use context.r8 to 357 lookup the new top label = 3005. R7 will swap label 3005 for 1005 358 and forward the packet to R1. This will get the packet to R5 on a 359 node protecting backup path. 361 Note that R7 activates the node-protecting backup path when it 362 detects that the link to R8 has failed. R7 does not know that node 363 R8 has actually failed. However, the node-protecting backup path is 364 computed assuming that the failure of the link to R8 implies that R8 365 has failed. 367 3.3. Node protection for adjacency SIDs 369 This section gives an example of how to constuct node-protecting 370 backup paths when the SR-TE path uses adjacency SIDs. Figure 5 shows 371 some of the routing table entries for R3 corresponding to the sample 372 network shown in Figure 3. When the top label of the label stack is 373 an adjacency SID, the PLR needs to recognize that in order to provide 374 a node-protecting backup path, it needs to pop the top label and 375 examine the next label in the context of the next-hop router 376 identified by the top label adjacency SID. In this example, when R3 377 is constructing its routing table, it recognizes that label 9044 378 corresponds to a next-hop of R8, so it installs a backup entry, 379 corresponding to the failure of the link to R8, when pops label 9044, 380 and then examines the new top label in the context of R8. 382 R3's Routing Table (partial) 383 Transit route for Adj SID 384 +=============+=============================================+ 385 | In label | Outgoing label action | 386 +=============+=============================================+ 387 | 9044 | Primary: pop, fwd to R8 | 388 | | Backup: pop, lookup context.r8 | 389 +-------------+---------------------------------------------+ 391 R3's Context Table for R8 (context.r8, partial) 392 +=============+=============================================+ 393 | In label | Outgoing label action | 394 +=============+=============================================+ 395 | 3005 | swap 1005, fwd to R4 | 396 +-------------+---------------------------------------------+ 397 | 9054 | pop, fwd to R4 | 398 +-------------+---------------------------------------------+ 400 Figure 5: Building node-protecting backup paths for SR-TE paths 401 involving adjacency SIDs 403 R3 constructs its context table for R8 by determining which labels R8 404 expects to receive to accomplish different forwarding actions. The 405 entry for incoming label 3005 in context.r8 in Figure 5 corresponds 406 to a node SID. This entry is computed using the methods described in 407 Section 3.2 409 The entry for incoming label 9054 in context.r8 corresponds to an 410 adjacency SID. R3 recognizes that R8 has advertised this adjacency 411 SID for the link from R8 to R4 in Figure 3. So R3 determines the 412 outgoing label action needed to reach R4 without passing through R8. 413 This can be accomplished by popping the label 9054, and forwarding 414 the packet directly on the link from R3 to R4. 416 3.4. Node protection for edge nodes 418 The node protection mechanism described in the previous sections 419 depends on the assumption that the label immediately below the top 420 label in the label stack is understood in the IGP domain. When the 421 provider edge routers exchange service labels via BGP or some other 422 non-IGP mechanism the bottom label is not understood in the IGP 423 domain. 425 The egress node protection mechanisms described in the draft 426 [RFC8679] is applicable to this usecase and no additional changes 427 will be required for SR based networks 429 4. Hold timers for Node-SID/Prefix-SIDs and Adjacency-SIDs 431 SR-TE paths may be computed by a controller or by the head-end 432 router. When there is a node failure in the network, the controller 433 or head-end router has to learn about the failure, recompute the 434 label stacks of any affected SR-TE paths, and get the new label 435 stacks programmed into the forwarding plane of the head-end router. 436 This process may be slow compared to the speed with which routers in 437 the network react to the event. After learning about a node failure, 438 the non-PLR routers in the network will no longer be able to compute 439 a path to reach the failed node. If no special precautions are 440 taken, these non-PLR routers will remove the forwarding entries 441 corresponding the Node-SID and Prefix-SIDs advertised by the failed 442 node. If the head-end router is still sending traffic with that 443 Node-sid/prefix-sid in the stack, traffic can be blackholed at a non- 444 PLR router. In this case, the node-protection FRR mechanisms do not 445 bring full benefit. 447 In order to solve the above problem, hold timers are recommended. 448 The hold-timer corresponds to the maximum time that a combination of 449 controller and head-end router or a head-end router alone takes to 450 compute and install label stacks corresponding to a new SR-TE paths 451 in the event of a node failure. The hold times should be applied to 452 forwarding entries for Node-SIDs and Prefix-SIDs that are advertised 453 by single node in the network. If the Node-SID or Prefix-SID becomes 454 unreachable, the event and resulting forwarding changes should not 455 communicated to the forwarding planes on all configured routers 456 (including PLRs for the failed node) until the hold-timer expires. 457 The traffic will continue to follow the previous path and get FRR 458 protection on the PLR. 460 A route corresponding to a global adjacency SID advertised by a node 461 that becomes unreachable should also be left in the forwarding table 462 for the duration of the hold-timer. 464 The node-protecting backup forwarding entry on the PLR corresponding 465 to the local adjacency-SID from the PLR to the failed node should 466 also be left in the forwarding table for the duration of the hold- 467 timer. 469 4.1. Interaction with micro-loop avoidance 471 During network convergence, the micro-loop avoidance mechansims as 472 described in [I-D.bashandy-rtgwg-segment-routing-uloop] may be 473 applied.For the failed node, all the nodes in the network should 474 consistently detect the failure and maintain the pre-failure shortest 475 path in the forwarding plane so that the traffic can follow pre- 476 failure shortest path and take the node-protecting backup path at the 477 PLR of the failed node. 479 5. Optimization Considerations 481 The solution described in this document requires that a PLR build a 482 context table for each neighbor for which node-protection is desired. 483 The context table for each protected neighbor needs to contain route 484 entries for all of the prefix-SIDs in the network, as well as the 485 route entries corresponding to the adjacency SIDs advertised by the 486 protected neighbor. This may result in considerable additional 487 memory consumption. It is possible to take advantage of an 488 optimization that allows the PLR to avoid creating context-tables 489 when all of the nodes in the network advertise the same SRGB and all 490 adjacency SIDs in the network are advertised as global adjacency 491 SIDs. In this case, all labels in the stack representing an SR-TE 492 path are globally unique. Protection for node failure cases in such 493 a deployment can be achieved by doing a lookup of the first label and 494 potentially a second lookup of the second label using a common route 495 table with primary and backup entries for all prefix-SIDs as well as 496 for all of the global adj-SIDs. 498 The primary route entries for global adj-SIDs not advertised by the 499 PLR will be the shortest path to the node advertising the global adj- 500 SID. The backup route entries for these global adj-SIDs will 501 generally correspond to the node-protecting backup path to the node 502 advertising the global adj-SID. However, for a global adj-SID 503 advertised by the direct neighbor of the PLR the node-protecting 504 backup route entry will correspond to the backup path to the node on 505 the far end of the adj-SID. 507 With the common route table constructed in this manner, when the PLR 508 receives a packet whose first label is a global adj-SID advertised by 509 the failed neighbor of the PLR, the lookup of the first label will 510 produce the correct backup path directly. When the PLR receives a 511 packet whose first label is the node-SID of the failed neighbor, or 512 an adj-SID advertised by the PLR corresponding to the failed 513 neighbor, the route entry will instruct the PLR to lookup the second 514 label using the common route table. Finally, when the PLR receives a 515 packet whose first label is a global adj-SID or a node-SID advertised 516 by a node which is neither the PLR nor the failed neighbor, then the 517 usual link-protecting backup path will be produced based on a lookup 518 of the first label only. 520 6. Security Considerations 522 The procedures described in this document will in most common cases 523 be deployed inside a single ownership IGP domain. No new security 524 risks are exposed due to the procedures described in this document. 525 The security procedures applicable to IGP protocols will provide the 526 desired protection. 528 7. IANA Considerations 530 8. Acknowledgments 532 The authors would like to thank Peter Psenak, Bruno Decraene, 533 Alexander Vainshtein and Huzibo for their review and suggestions. 535 9. References 537 9.1. Normative References 539 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 540 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 541 DOI 10.17487/RFC5286, September 2008, 542 . 544 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 545 Label Assignment and Context-Specific Label Space", 546 RFC 5331, DOI 10.17487/RFC5331, August 2008, 547 . 549 9.2. Informative References 551 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 552 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 553 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 554 Camarillo, "Topology Independent Fast Reroute using 555 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 556 lfa-05 (work in progress), October 2018. 558 [I-D.bashandy-rtgwg-segment-routing-uloop] 559 Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., 560 Francois, P., and P. Psenak, "Loop avoidance using Segment 561 Routing", draft-bashandy-rtgwg-segment-routing-uloop-09 562 (work in progress), June 2020. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 [RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and 570 S. Litkowski, "Remote-LFA Node Protection and 571 Manageability", RFC 8102, DOI 10.17487/RFC8102, March 572 2017, . 574 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 575 Michel, C., and H. Chen, "MPLS Egress Protection 576 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 577 . 579 Authors' Addresses 581 Shraddha Hegde 582 Juniper Networks Inc. 583 Exora Business Park 584 Bangalore, KA 560103 585 India 587 Email: shraddha@juniper.net 589 Chris Bowers 590 Juniper Networks Inc. 592 Email: cbowers@juniper.net 594 Stephane Litkowski 595 Cisco Systems 597 Email: slitkows.ietf@gmail.com 599 Xiaohu Xu 600 Alibaba Inc. 601 Beijing 602 China 604 Email: xiaohu.xxh@alibaba-inc.com 606 Feng Xu 607 Tencent 608 China 610 Email: oliverxu@tencent.com