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