idnits 2.17.1 draft-hegde-spring-node-protection-for-sr-te-paths-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1000-2000' is mentioned on line 454, but not defined == Missing Reference: '3000-4000' is mentioned on line 230, but not defined -- Looks like a reference, but probably isn't: '1100' on line 185 -- Looks like a reference, but probably isn't: '1005' on line 456 -- Looks like a reference, but probably isn't: '70099' on line 498 -- Looks like a reference, but probably isn't: '1201' on line 494 -- Looks like a reference, but probably isn't: '40001' on line 495 == Outdated reference: A later version (-05) exists of draft-bashandy-rtgwg-segment-routing-ti-lfa-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 6 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 3, 2019 S. Litkowski 6 Orange 7 X. Xu 8 Alibaba Inc. 9 July 2, 2018 11 Node Protection for SR-TE Paths 12 draft-hegde-spring-node-protection-for-sr-te-paths-03 14 Abstract 16 Segment routing supports the creation of explicit paths using 17 adjacency-sids, node-sids, and binding-sids. It is important to 18 provide fast reroute (FRR) mechanisms to respond to failures of links 19 and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A 20 point of local repair (PLR) can provide FRR protection against the 21 failure of a link in an SR-TE path by examining only the first (top) 22 label in the SR label stack. In order to protect against the failure 23 of a node, a PLR may need to examine the second label in the stack as 24 well in order to determine SR-TE path beyond the failed node. This 25 document specifies how a PLR can use the first and second label in 26 the label stack describing an SR-TE path to provide protection 27 against node failures. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 January 3, 2019. 51 Copyright Notice 53 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Node Failures Along SR-TE Paths . . . . . . . . . . . . . . . 3 70 2.1. Node protection for node-sid explicit paths . . . . . . . 3 71 2.2. Node-Protection for Anycast-SIDs . . . . . . . . . . . . 4 72 2.3. Node-protection for adj-sid explicit paths . . . . . . . 5 73 3. Detailed Solution using Context Tables . . . . . . . . . . . 6 74 3.1. Building Context Tables . . . . . . . . . . . . . . . . . 6 75 3.2. Node protection for node SIDs . . . . . . . . . . . . . . 7 76 3.3. Node protection for ajacency SIDs . . . . . . . . . . . . 8 77 3.4. Node protection for edge nodes . . . . . . . . . . . . . 9 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 7.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 95 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] can be used to provide 96 node protection to ensure minimal traffic loss after a node failure. 98 Section 2 describes problems with SR-TE paths and the need for a 99 specialized mechanism to provide node protection for SR-TE paths. 100 Section 3 describes the solution applied to paths built using 101 adjacency-sids and node-sids. Section 3.4 describes the solution 102 applied to egress node protection. 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 2.2. Node-Protection for Anycast-SIDs 153 A prefix segment advertised as a node SID may only be advertised by 154 one node in the network. Instead, an anycast prefix segment may be 155 advertised by more than one node. In some situations, one can use 156 anycast SIDs to construct SR-TE paths that are protected against node 157 failure, without the need for the mechanism described in this 158 document. 160 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 161 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 162 +----+ +----+ +----+ +----+ +----+ 163 \ \ / | 164 \ 10 \100 60/ | 165 \ \ / | 166 \ +----+ 30 +----+ | 167 +--| R7 |------------------| R8 | | 168 +----+ +----+ | 169 / \ Anycast + 170 / \ sid:100 / 171 +----+ \ / 172 | R6 | \ 40 +----+ /60 173 +----+ +---------------| R9 |+ Label stack: 174 +----+ +------------+ 175 Anycast | 1100 (top)| 176 sid:100 +------------+ 177 | 1005 | 178 +------------+ 180 Figure 2: Topology illustrating use of anycast-sids to protect 181 against node failures. All nodes have SRGB = [1000-2000]. 183 An example of this is shown in Figure 2. In this example, R8 and R9 184 advertise an anycast SID of 100. The label stack in this example = 185 [1100, 1005];. The top label (1100) corresponds to the anycast SID 186 advertised by both R8 and R9. In the absence of a failure, the 187 packet sent by R1 with this label stack will follow the path from 188 R1->R5 along R1->R7->R8->R4->R5. 190 If R7 is performing a per-prefix LFA calculation [RFC5286], then R7 191 will install a backup next-hop to R9 for this anycast SID, protecting 192 against the failure of the primary next-hop to R8. This backup path 193 does not pass through R8, so it is would not be affected by a 194 complete failure of node R8. As illustrated by this example, for 195 some topologies node-protecting SR-TE paths can constructed through 196 the use of anycast SIDs, as opposed to the mechanism described in 197 this document. 199 2.3. Node-protection for adj-sid explicit paths 201 Adj-sid: 202 R3-R8:9044 204 Node Node Node Node Node 205 sid:1 sid:2 sid:3 sid:4 sid:5 206 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 207 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 208 +----+ +----+ +----+ +----+ +----+ 209 \ \ / | 210 \ 10 \ 100 / 60 | 10 211 \ \ / | 212 \ +----+ +----+ +----+ 213 +--| R7 |------------------| R8 |---------------| R9 | 214 +----+ 30 +----+ 10 +----+ 215 / Node Node Node 216 / sid:7 sid:8 sid:9 217 +----+ SRGB: 218 | R6 | 3000-4000 Label stack: 219 +----+ +------------+ 220 Node Adj-sids: | 1003 (top)| 221 sid:6 R8-R4:9054 +------------+ 222 | 9044 | 223 +------------+ 224 | 9054 | 225 +------------+ 226 | 1005 | 227 +------------+ 229 Figure 3: Explicit path using an adjacency sid. All nodes have SRGB 230 = [1000-2000], except for R8 which has SRGB = [3000-4000]. 232 Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5. 233 This path can be built using a combination of node sids and adjacency 234 sids, as shown in Figure 3. The diagram shows shows the label stack 235 needed to instantiate this path, as well as several adjacency sids 236 advertised by nodes involved in this path. When a packet leaving R1 237 with this label stack reaches R3, the top label is 9044, which will 238 take the packet to R8. The next-next-hop in the path is R4. To 239 provide protection for the failure of node R8, R3 would need to send 240 the the packet to R4 without going through R8. However, the only way 241 R3 can learn that the packet needs to go to the R4 is to examine the 242 next label in the stack, label 9054. Since R3 knows that R8 has 243 advertised label 9054 as the adjacency segment for the link from R8 244 to R4, R3 knows that a backup path can merge back into the original 245 explicit path at R4. 247 3. Detailed Solution using Context Tables 249 This section provides a detailed description of how to construct 250 node-protecting backup paths for SR-TE paths using context tables. 251 The end result of this description is externally visible forwarding 252 behavior that can be specified as a packet arriving at a PLR with a 253 particular incoming label stack and leaving the PLR on a particular 254 outgoing interface with a particular outgoing label stack. There may 255 be other methods of arriving at the same externally visible 256 forwarding behavior. It is not the intent of this document to 257 exclude other methods, as long as the externally visible forwarding 258 behavior is the same as produced by this method. 260 3.1. Building Context Tables 262 [RFC5331] introduced the concept of Context Specific Label Spaces and 263 there are various applications making use of this concept.A context 264 label table on a router represents the Label Forwarding Information 265 Base (LFIB) from the point of view of a particular neighbor . Context 266 tables are built by constructing incoming label mappings advertised 267 by the neighbor and the actions corresponding to those labels. The 268 labels advertised by each node are local to the node and may not be 269 unique across the segment routing domain. The context tables are 270 separate tables built on a per-neighbor basis on every node to ensure 271 they represent LFIBs of a particular neighbor. 273 When a PLR needs to protect an SR-TE path against the failure of a 274 neighbor N, it creates a context table associated with N. This 275 context table is populated with the following segment routing 276 forwarding entries: 278 - All the Prefix-SIDs of the network which have N as the primary 279 nexthop. The programmed incoming label map uses the SRGB of N to 280 compute the input label value. The NHLFE (Next Hop Label 281 Forwarding Entry) is then constructed by looking into all the 282 nexthops for the prefix-SID and choosing a loop-free path as 283 explained in Section 3.2 285 - All the Adjacency SIDs advertised by N. The NHLFE is 286 constructed as explained in Section 3.3 288 The following section illustrates how the context table is 289 constructed to allow the PLR to provide node-protecting paths for the 290 next-next hops in the topology shown in Figure 1 and Figure 3. 292 3.2. Node protection for node SIDs 294 Figure 4 shows the routing table entries on R7 corresponding to the 295 node SIDs to reach R1 and R8 for the topology in Figure 1. In the 296 absence of a failure, a packet with a label stack whose top label is 297 1008 will have its top label popped by R7 (assuming PHP behavior), 298 and R7 will forward the packet to R8. When the interface to R8 is 299 down, the backup next-hop entry is used. R7 will pop the top label 300 of 1008, and use the context table that R7 computed for R8 to 301 evaluate the next label on the stack. 303 R7's Routing Table (partial) 304 Transits routes for Node SIDs for R1 and R8 305 +=============+=============================================+ 306 | In label | Outgoing label action | 307 +=============+=============================================+ 308 | 1001 | Primary: pop, fwd to R1 | 309 | | Backup: pop, lookup context.r1 | 310 +-------------+---------------------------------------------+ 311 | 1008 | Primary: pop, fwd to R8 | 312 | | Backup: pop, lookup context.r8 | 313 +-------------+---------------------------------------------+ 315 R7's Context Table for R8 (context.r8, partial) 316 +=============+=============================================+ 317 | In label | Outgoing label action | 318 +=============+=============================================+ 319 | 3004 | swap 1004, fwd to R1 | 320 +-------------+---------------------------------------------+ 321 | 3005 | swap 1005, fwd to R1 | 322 +-------------+---------------------------------------------+ 323 | 3008 | swap 1008, fwd to R1 | 324 +-------------+---------------------------------------------+ 326 Figure 4: Building node-protecting backup paths for SR-TE paths 327 involving node SIDs 329 R7 builds context table for R8 using the following process. R7 330 computes the mapping of incoming label to node-sid that R8 expects to 331 see based on the SRGB advertised by R8. In the example in Figure 1, 332 R7 can determine that R8 interprets in incoming label of 3005 as 333 mapping to the the node SID for R5. 335 R7 then computes a loop-free backup path to reach R5 which is node- 336 protecting with respect to the failure of R8. In this example, the 337 backup path computed by R7 to reach R5 without passing through R8 can 338 be achieved forwarding the packet to R1 with a top label of 1005, 339 corresponding to the node SID for R5 in the context of R1's SRGB. 340 The loop-free path computation may be based on a mechanism such as 341 LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure. To 342 populate the context table for R8, R7 maps the out label actions 343 corresponding to the backup path to R5 to the incoming label 3005. 344 This results in the entry for label 3005 showin in context.r8 in 345 Figure 4. 347 Therefore, when a packet arrives at R7 with label stack = [1008, 348 3005], and the link from R7 to R8 has recently failed, R7 will use 349 backup next-hop entry for label 1008 in its main routing table. 350 Based on this entry, R7 will pop label 1008, and use context.r8 to 351 lookup the new top label = 3005. R7 will swap label 3005 for 1005 352 and forward the packet to R1. This will get the packet to R5 on a 353 node protecting backup path. 355 Note that R7 activates the node-protecting backup path when it 356 detects that the link to R8 has failed. R7 does not know that node 357 R8 has actually failed. However, the node-protecting backup path is 358 computed assuming that the failure of the link to R8 implies that R8 359 has failed. 361 3.3. Node protection for ajacency SIDs 363 This section gives an example of how to constuct node-protecting 364 backup paths when the SR-TE path uses adjacency SIDs. Figure 5 shows 365 some of the routing table entries for R3 corresponding to the sample 366 network shown in Figure 3. When the top label of the label stack is 367 an adjacency SID, the PLR needs to recognize that in order to provide 368 a node-protecting backup path, it needs to pop the top label and 369 examine the next label in the context of the next-hop router 370 identified by the top label adjacency SID. In this example, when R3 371 is constructing its routing table, it recognizes that label 9044 372 corresponds to a next-hop of R8, so it installs a backup entry, 373 corresponding to the failure of the link to R8, when pops label 9044, 374 and then examines the new top label in the context of R8. 376 R3's Routing Table (partial) 377 Transit route for Adj SID 378 +=============+=============================================+ 379 | In label | Outgoing label action | 380 +=============+=============================================+ 381 | 9044 | Primary: pop, fwd to R8 | 382 | | Backup: pop, lookup context.r8 | 383 +-------------+---------------------------------------------+ 385 R3's Context Table for R8 (context.r8, partial) 386 +=============+=============================================+ 387 | In label | Outgoing label action | 388 +=============+=============================================+ 389 | 3005 | swap 1005, fwd to R4 | 390 +-------------+---------------------------------------------+ 391 | 9054 | pop, fwd to R4 | 392 +-------------+---------------------------------------------+ 394 Figure 5: Building node-protecting backup paths for SR-TE paths 395 involving adjacency SIDs 397 R3 constructs its context table for R8 by determining which labels R8 398 expects to receive to accomplish different forwarding actions. The 399 entry for incoming label 3005 in context.r8 in Figure 5 corresponds 400 to a node SID. This entry is computed using the methods described in 401 Section 3.2 403 The entry for incoming label 9054 in context.r8 corresponds to an 404 adjacency SID. R3 recognizes that R8 has advertised this adjacency 405 SID for the link from R8 to R4 in Figure 3. So R3 determines the 406 outgoing label action needed to reach R4 without passing through R8. 407 This can be accomplished by popping the label 9054, and forwarding 408 the packet directly on the link from R3 to R4. 410 3.4. Node protection for edge nodes 412 The node protection mechanism described in the previous sections 413 depends on the assumption that the label immediately below the top 414 label in the label stack is understood in the IGP domain. In the 415 example topology in Figure 6, CE-A and CE-B are customer edge routers 416 receiving services from provider edge routers. The provider edge 417 routers are exchanging service labels via BGP or some other non-IGP 418 mechanism. 420 Primary PE: 421 context 1.1.1.1 422 prefix sid: 201 424 Node Node Node Node Node 425 sid:1 sid:2 sid:3 sid:4 sid:5 426 +---+ 10 +----+ 10 +----+ 10 +----+ 10 +---+ +----+ 427 |PE1|--------| R2 |--------| R3 |--------| R4 |------|PE5|---|CE-A| 428 +---+ +----+ +----+ +----+ +---+ +----+ 429 \ \ / \ / 430 \ 10 \ 100 / 60 \/ 431 \ \ / /\ 432 \ +----+ +----+ +---+/ +----+ 433 +--| R7 |------------------| R8 |-------------|PE9+---|CE-B| 434 +----+ 30 +----+ 10 +---+ +----+ 435 / Node Node Node 436 / sid:7 sid:8 sid:9 437 +----+ 438 | R6 | Protector PE: 439 +----+ context 1.1.1.1/32 440 Node prefix sid: 201 441 sid:6 context label: 40001 443 Normal Protection 444 label stack label stack 445 +------------+ +------------+ 446 | 1201 (top)| | 1201 (top)| 447 +------------+ +------------+ 448 | 70099 | | 40001 | 449 +------------+ +------------+ 450 | 70099 | 451 +------------+ 453 Figure 6: Node Protection for edge nodes. All nodes have SRGB = 454 [1000-2000]. 456 A packet with label stack = [1005,70099] sent from PE1 out the 457 interface to R2 would be forwarded along the path 458 PE1->R2->R3->R4->PE5. Assuming PHP behavior, PE5 receives the packet 459 with the label stack = [70099]. PE5 uses the service label 70099 to 460 send the packet to CE-B with the appropriate service characteristics. 462 If PE5 fails, R4 can act as a PLR, redirecting the packet to PE9. 463 However, when PE9 receives the packet, it needs to be able to 464 understand the meaning of the meaning of the service label 70099. 465 The service mirroring use case described in 466 [I-D.ietf-spring-segment-routing] addresses this issue. The customer 467 edge (CE) routers are multi-homed to provider edge (PE) routers, and 468 one of the PE's acts in a primary role and the other in protector 469 role. The two PEs advertise a context IP address for each customer 470 site and attaches a prefix-sid to the context. In IS-IS, the 471 protector PE advertises a Label Binding TLV with the M-bit set which 472 associates a context-label with the context. The Protector PE builds 473 the context table for the BGP service labels using the BGP service 474 labels advertised by the primary PE for the same context. In order 475 for the Protector PE to know when to use the context table, packets 476 need to arrive at the Protector PE with the context-label exposed. 478 Each node acting as a PLR with respect to failure of the Primary PE 479 installs a backup routing entry that accomplishes two things. The 480 route gets the packet to the Protector PE. And it positions the 481 context-label immediately above the service label in the label stack, 482 so that the Protector PE is able to identify the correct context 483 table to interpret the service label. 485 We now continue with the example topology in Figure 6 using the 486 service mirroring mechansim. PE5 is the Primary PE, while PE9 is the 487 Protector PE. PE5 and PE9 both advertise the anycast prefix 488 1.1.1.1/32 with prefix-SID=201. In addition, PE9 advertises a 489 context-label of 40001 for the context identified by 1.1.1.1. PE9 490 builds a context table for the BGP service labels advertised by PE5 491 associated with 1.1.1.1. In the event of a failure of the link from 492 R4 to PE5, R4 makes sure that the packet originally destined for PE5 493 is forwarded on the interface to R8 with label stack = 494 [1201,40001,70099]. This gets the packet to PE9 with label stack = 495 [40001,70099] (assuming PHP behavior). PE9 then uses the context 496 label of 40001 to determine the context table corresponding to 497 1.1.1.1 on PE5. After popping the context label, PE9 is able to 498 process the top label [70099] using the context table where 70099 has 499 the appropriate meaning. 501 4. Security Considerations 503 TBD 505 5. IANA Considerations 507 6. Acknowledgments 509 The authors would like to thank Peter Psenak for his review and 510 suggestions. 512 7. References 514 7.1. Normative References 516 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 517 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 518 DOI 10.17487/RFC5286, September 2008, 519 . 521 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 522 Label Assignment and Context-Specific Label Space", 523 RFC 5331, DOI 10.17487/RFC5331, August 2008, 524 . 526 7.2. Informative References 528 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 529 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 530 Francois, P., and d. daniel.voyer@bell.ca, "Topology 531 Independent Fast Reroute using Segment Routing", draft- 532 bashandy-rtgwg-segment-routing-ti-lfa-04 (work in 533 progress), April 2018. 535 [I-D.ietf-spring-segment-routing] 536 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 537 Litkowski, S., and R. Shakir, "Segment Routing 538 Architecture", draft-ietf-spring-segment-routing-15 (work 539 in progress), January 2018. 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, 543 DOI 10.17487/RFC2119, March 1997, 544 . 546 [RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and 547 S. Litkowski, "Remote-LFA Node Protection and 548 Manageability", RFC 8102, DOI 10.17487/RFC8102, March 549 2017, . 551 Authors' Addresses 553 Shraddha Hegde 554 Juniper Networks Inc. 555 Exora Business Park 556 Bangalore, KA 560103 557 India 559 Email: shraddha@juniper.net 560 Chris Bowers 561 Juniper Networks Inc. 563 Email: cbowers@juniper.net 565 Stephane Litkowski 566 Orange 568 Email: stephane.litkowski@orange.com 570 Xiaohu Xu 571 Alibaba Inc. 572 Beijing 573 China 575 Email: xiaohu.xxh@alibaba-inc.com