idnits 2.17.1 draft-hegde-spring-node-protection-for-sr-te-paths-04.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 (October 17, 2018) is 1990 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1000-2000' is mentioned on line 232, but not defined == Missing Reference: '3000-4000' is mentioned on line 232, but not defined -- Looks like a reference, but probably isn't: '1100' on line 187 -- Looks like a reference, but probably isn't: '1005' on line 187 == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 465, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-egress-protection-framework-02 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: April 20, 2019 S. Litkowski 6 Orange 7 X. Xu 8 Alibaba Inc. 9 F. Xu 10 Tencent 11 October 17, 2018 13 Node Protection for SR-TE Paths 14 draft-hegde-spring-node-protection-for-sr-te-paths-04 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 April 20, 2019. 54 Copyright Notice 56 Copyright (c) 2018 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. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 7.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 It is possible for a routing device to completely go out of service 92 abruptly due to power failure, hardware failure or software crashes. 93 Node protection is an important property of the Fast Reroute 94 mechanism. It provides protection against a node failure by 95 rerouting traffic around the failed node. For example, the 96 mechanisms described in Loop Free Alternates ([RFC5286]), Remote Loop 97 Free Alternates ([RFC8102]), and 98 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] can be used to provide 99 node protection to ensure minimal traffic loss after a node failure. 101 Section 2 describes problems with SR-TE paths and the need for a 102 specialized mechanism to provide node protection for SR-TE paths. 103 Section 3 describes the solution applied to paths built using 104 adjacency-sids and node-sids. 106 2. Node Failures Along SR-TE Paths 108 The topology shown in Figure 1. illustrates a example network 109 topology with SPRING enabled on each node. 111 Node Node Node Node Node 112 sid:1 sid:2 sid:3 sid:4 sid:5 113 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 114 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 115 +----+ +----+ +----+ +----+ +----+ 116 \ \ / 117 \ 10 \ 100 / 60 118 \ \ / 119 \ +----+ +----+ 120 +--| R7 |------------------| R8 | 121 +----+ 30 +----+ 122 / Node Node Label stack: 123 / sid:7 sid:8 +------------+ 124 +----+ SRGB: | 1008 (top)| 125 | R6 | 3000-4000 +------------+ 126 +----+ | 3005 | 127 Node +------------+ 128 sid:6 130 Figure 1: Example topology. The segment index for each node is shown 131 in the diagram. All nodes have SRGB = [1000-2000], except for R8 132 which has SRGB = [3000-4000]. A label stack that represents the path 133 R1->R7->R8->R4->R5 is shown as well. 135 2.1. Node protection for node-sid explicit paths 137 Consider an explicit path in the topology in Figure 1 from R1->R5 via 138 R1->R7->R8->R4->R5. This path can be built using the shortest paths 139 from R1-to-R8 and R8-to-R5. The label stack to instantiate this path 140 contains two node-sids 1008 and 3005. The 1008 label will take the 141 packet from R1 to R8 via R7 and get popped. The next label in the 142 stack 3005 will take the packet from R8 to the destination R5 via R4. 143 If the node R8 goes down, it is not possible for R7 to perform FRR 144 without examining the second label in the incoming label stack 145 (3005). 147 Note that in the absence of a failure, R7 does not need to understand 148 the meaning of the second label (3005) in order to perform normal 149 forwarding. However, in order to support node protection, R7 will 150 need to understand the meaning of label 3005 in order to determine 151 where the packet is headed after R8. 153 2.2. Node-Protection for Anycast-SIDs 155 A prefix segment advertised as a node SID may only be advertised by 156 one node in the network. Instead, an anycast prefix segment may be 157 advertised by more than one node. In some situations, one can use 158 anycast SIDs to construct SR-TE paths that are protected against node 159 failure, without the need for the mechanism described in this 160 document. 162 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 163 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 164 +----+ +----+ +----+ +----+ +----+ 165 \ \ / | 166 \ 10 \100 60/ | 167 \ \ / | 168 \ +----+ 30 +----+ | 169 +--| R7 |------------------| R8 | | 170 +----+ +----+ | 171 / \ Anycast + 172 / \ sid:100 / 173 +----+ \ / 174 | R6 | \ 40 +----+ /60 175 +----+ +---------------| R9 |+ Label stack: 176 +----+ +------------+ 177 Anycast | 1100 (top)| 178 sid:100 +------------+ 179 | 1005 | 180 +------------+ 182 Figure 2: Topology illustrating use of anycast-sids to protect 183 against node failures. All nodes have SRGB = [1000-2000]. 185 An example of this is shown in Figure 2. In this example, R8 and R9 186 advertise an anycast SID of 100. The label stack in this example = 187 [1100, 1005];. The top label (1100) corresponds to the anycast SID 188 advertised by both R8 and R9. In the absence of a failure, the 189 packet sent by R1 with this label stack will follow the path from 190 R1->R5 along R1->R7->R8->R4->R5. 192 If R7 is performing a per-prefix LFA calculation [RFC5286], then R7 193 will install a backup next-hop to R9 for this anycast SID, protecting 194 against the failure of the primary next-hop to R8. This backup path 195 does not pass through R8, so it is would not be affected by a 196 complete failure of node R8. As illustrated by this example, for 197 some topologies node-protecting SR-TE paths can constructed through 198 the use of anycast SIDs, as opposed to the mechanism described in 199 this document. 201 2.3. Node-protection for adj-sid explicit paths 203 Adj-sid: 204 R3-R8:9044 206 Node Node Node Node Node 207 sid:1 sid:2 sid:3 sid:4 sid:5 208 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 209 | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | 210 +----+ +----+ +----+ +----+ +----+ 211 \ \ / | 212 \ 10 \ 100 / 60 | 10 213 \ \ / | 214 \ +----+ +----+ +----+ 215 +--| R7 |------------------| R8 |---------------| R9 | 216 +----+ 30 +----+ 10 +----+ 217 / Node Node Node 218 / sid:7 sid:8 sid:9 219 +----+ SRGB: 220 | R6 | 3000-4000 Label stack: 221 +----+ +------------+ 222 Node Adj-sids: | 1003 (top)| 223 sid:6 R8-R4:9054 +------------+ 224 | 9044 | 225 +------------+ 226 | 9054 | 227 +------------+ 228 | 1005 | 229 +------------+ 231 Figure 3: Explicit path using an adjacency sid. All nodes have SRGB 232 = [1000-2000], except for R8 which has SRGB = [3000-4000]. 234 Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5. 235 This path can be built using a combination of node sids and adjacency 236 sids, as shown in Figure 3. The diagram shows the label stack needed 237 to instantiate this path, as well as several adjacency sids 238 advertised by nodes involved in this path. When a packet leaving R1 239 with this label stack reaches R3, the top label is 9044, which will 240 take the packet to R8. The next-next-hop in the path is R4. To 241 provide protection for the failure of node R8, R3 would need to send 242 the the packet to R4 without going through R8. However, the only way 243 R3 can learn that the packet needs to go to the R4 is to examine the 244 next label in the stack, label 9054. Since R3 knows that R8 has 245 advertised label 9054 as the adjacency segment for the link from R8 246 to R4, R3 knows that a backup path can merge back into the original 247 explicit path at R4. 249 3. Detailed Solution using Context Tables 251 This section provides a detailed description of how to construct 252 node-protecting backup paths for SR-TE paths using context tables. 253 The end result of this description is externally visible forwarding 254 behavior that can be specified as a packet arriving at a PLR with a 255 particular incoming label stack and leaving the PLR on a particular 256 outgoing interface with a particular outgoing label stack. There may 257 be other methods of arriving at the same externally visible 258 forwarding behavior as described in draft 259 [I-D.bashandy-rtgwg-segment-routing-ti-lfa]. It is not the intent of 260 this document to exclude other methods, as long as the externally 261 visible forwarding behavior is the same as produced by this method. 263 3.1. Building Context Tables 265 [RFC5331] introduced the concept of Context Specific Label Spaces and 266 there are various applications making use of this concept.A context 267 label table on a router represents the Label Forwarding Information 268 Base (LFIB) from the point of view of a particular neighbor . Context 269 tables are built by constructing incoming label mappings advertised 270 by the neighbor and the actions corresponding to those labels. The 271 labels advertised by each node are local to the node and may not be 272 unique across the segment routing domain. The context tables are 273 separate tables built on a per-neighbor basis on every node to ensure 274 they represent LFIBs of a particular neighbor. 276 When a PLR needs to protect an SR-TE path against the failure of a 277 neighbor N, it creates a context table associated with N. This 278 context table is populated with the following segment routing 279 forwarding entries: 281 - All the Prefix-SIDs of the network. The programmed incoming 282 label map uses the SRGB of N to compute the input label value. 283 The NHLFE (Next Hop Label Forwarding Entry) is then constructed by 284 looking into all the nexthops for the prefix-SID and choosing a 285 loop-free path as explained in Section 3.2 286 - All the Adjacency SIDs advertised by N. The NHLFE is 287 constructed as explained in Section 3.3 289 The following section illustrates how the context table is 290 constructed to allow the PLR to provide node-protecting paths for the 291 next-next hops in the topology shown in Figure 1 and Figure 3. 293 3.2. Node protection for node SIDs 295 Figure 4 shows the routing table entries on R7 corresponding to the 296 node SIDs to reach R1 and R8 for the topology in Figure 1. In the 297 absence of a failure, a packet with a label stack whose top label is 298 1008 will have its top label popped by R7 (assuming PHP behavior), 299 and R7 will forward the packet to R8. When the interface to R8 is 300 down, the backup next-hop entry is used. R7 will pop the top label 301 of 1008, and use the context table that R7 computed for R8 to 302 evaluate the next label on the stack. 304 R7's Routing Table (partial) 305 Transits routes for Node SIDs for R1 and R8 306 +=============+=============================================+ 307 | In label | Outgoing label action | 308 +=============+=============================================+ 309 | 1001 | Primary: pop, fwd to R1 | 310 | | Backup: pop, lookup context.r1 | 311 +-------------+---------------------------------------------+ 312 | 1008 | Primary: pop, fwd to R8 | 313 | | Backup: pop, lookup context.r8 | 314 +-------------+---------------------------------------------+ 316 R7's Context Table for R8 (context.r8, partial) 317 +=============+=============================================+ 318 | In label | Outgoing label action | 319 +=============+=============================================+ 320 | 3004 | swap 1004, fwd to R1 | 321 +-------------+---------------------------------------------+ 322 | 3005 | swap 1005, fwd to R1 | 323 +-------------+---------------------------------------------+ 324 | 3008 | drop | 325 +-------------+---------------------------------------------+ 327 Figure 4: Building node-protecting backup paths for SR-TE paths 328 involving node SIDs 330 R7 builds context table for R8 using the following process. R7 331 computes the mapping of incoming label to node-sid that R8 expects to 332 see based on the SRGB advertised by R8. In the example in Figure 1, 333 R7 can determine that R8 interprets in incoming label of 3005 as 334 mapping to the the node SID for R5. 336 R7 then computes a loop-free backup path to reach R5 which is node- 337 protecting with respect to the failure of R8. In this example, the 338 backup path computed by R7 to reach R5 without passing through R8 can 339 be achieved forwarding the packet to R1 with a top label of 1005, 340 corresponding to the node SID for R5 in the context of R1's SRGB. 341 The loop-free path computation may be based on a mechanism such as 342 LFA, R-LFA, TI-LFA, or constraint based SPF avoiding failure. To 343 populate the context table for R8, R7 maps the out label actions 344 corresponding to the backup path to R5 to the incoming label 3005. 345 This results in the entry for label 3005 showin in context.r8 in 346 Figure 4. 348 Therefore, when a packet arrives at R7 with label stack = [1008, 349 3005], and the link from R7 to R8 has recently failed, R7 will use 350 backup next-hop entry for label 1008 in its main routing table. 351 Based on this entry, R7 will pop label 1008, and use context.r8 to 352 lookup the new top label = 3005. R7 will swap label 3005 for 1005 353 and forward the packet to R1. This will get the packet to R5 on a 354 node protecting backup path. 356 Note that R7 activates the node-protecting backup path when it 357 detects that the link to R8 has failed. R7 does not know that node 358 R8 has actually failed. However, the node-protecting backup path is 359 computed assuming that the failure of the link to R8 implies that R8 360 has failed. 362 3.3. Node protection for adjacency SIDs 364 This section gives an example of how to constuct node-protecting 365 backup paths when the SR-TE path uses adjacency SIDs. Figure 5 shows 366 some of the routing table entries for R3 corresponding to the sample 367 network shown in Figure 3. When the top label of the label stack is 368 an adjacency SID, the PLR needs to recognize that in order to provide 369 a node-protecting backup path, it needs to pop the top label and 370 examine the next label in the context of the next-hop router 371 identified by the top label adjacency SID. In this example, when R3 372 is constructing its routing table, it recognizes that label 9044 373 corresponds to a next-hop of R8, so it installs a backup entry, 374 corresponding to the failure of the link to R8, when pops label 9044, 375 and then examines the new top label in the context of R8. 377 R3's Routing Table (partial) 378 Transit route for Adj SID 379 +=============+=============================================+ 380 | In label | Outgoing label action | 381 +=============+=============================================+ 382 | 9044 | Primary: pop, fwd to R8 | 383 | | Backup: pop, lookup context.r8 | 384 +-------------+---------------------------------------------+ 386 R3's Context Table for R8 (context.r8, partial) 387 +=============+=============================================+ 388 | In label | Outgoing label action | 389 +=============+=============================================+ 390 | 3005 | swap 1005, fwd to R4 | 391 +-------------+---------------------------------------------+ 392 | 9054 | pop, fwd to R4 | 393 +-------------+---------------------------------------------+ 395 Figure 5: Building node-protecting backup paths for SR-TE paths 396 involving adjacency SIDs 398 R3 constructs its context table for R8 by determining which labels R8 399 expects to receive to accomplish different forwarding actions. The 400 entry for incoming label 3005 in context.r8 in Figure 5 corresponds 401 to a node SID. This entry is computed using the methods described in 402 Section 3.2 404 The entry for incoming label 9054 in context.r8 corresponds to an 405 adjacency SID. R3 recognizes that R8 has advertised this adjacency 406 SID for the link from R8 to R4 in Figure 3. So R3 determines the 407 outgoing label action needed to reach R4 without passing through R8. 408 This can be accomplished by popping the label 9054, and forwarding 409 the packet directly on the link from R3 to R4. 411 3.4. Node protection for edge nodes 413 The node protection mechanism described in the previous sections 414 depends on the assumption that the label immediately below the top 415 label in the label stack is understood in the IGP domain. When the 416 provider edge routers exchange service labels via BGP or some other 417 non-IGP mechanism the bottom label is not understood in the IGP 418 domain. 420 The egress node protection mechanisms described in the draft 421 [I-D.ietf-mpls-egress-protection-framework] is applicable to this 422 usecase and no additional changes will be required for SR based 423 networks 425 4. Security Considerations 427 TBD 429 5. IANA Considerations 431 6. Acknowledgments 433 The authors would like to thank Peter Psenak and Bruno Decreane for 434 their review and suggestions. 436 7. References 438 7.1. Normative References 440 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 441 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 442 DOI 10.17487/RFC5286, September 2008, 443 . 445 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 446 Label Assignment and Context-Specific Label Space", 447 RFC 5331, DOI 10.17487/RFC5331, August 2008, 448 . 450 7.2. Informative References 452 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 453 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 454 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 455 Camarillo, "Topology Independent Fast Reroute using 456 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 457 lfa-05 (work in progress), October 2018. 459 [I-D.ietf-mpls-egress-protection-framework] 460 Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., 461 Michel, C., Chen, H., and Y. Jiang, "MPLS Egress 462 Protection Framework", draft-ietf-mpls-egress-protection- 463 framework-02 (work in progress), July 2018. 465 [I-D.ietf-spring-segment-routing] 466 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 467 Litkowski, S., and R. Shakir, "Segment Routing 468 Architecture", draft-ietf-spring-segment-routing-15 (work 469 in progress), January 2018. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 [RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and 477 S. Litkowski, "Remote-LFA Node Protection and 478 Manageability", RFC 8102, DOI 10.17487/RFC8102, March 479 2017, . 481 Authors' Addresses 483 Shraddha Hegde 484 Juniper Networks Inc. 485 Exora Business Park 486 Bangalore, KA 560103 487 India 489 Email: shraddha@juniper.net 491 Chris Bowers 492 Juniper Networks Inc. 494 Email: cbowers@juniper.net 496 Stephane Litkowski 497 Orange 499 Email: stephane.litkowski@orange.com 501 Xiaohu Xu 502 Alibaba Inc. 503 Beijing 504 China 506 Email: xiaohu.xxh@alibaba-inc.com 508 Feng Xu 509 Tencent 510 China 512 Email: oliverxu@tencent.com