idnits 2.17.1 draft-hegde-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 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 date (March 20, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.minto-rsvp-lsp-egress-fast-protection' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'ISO10589' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 520, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-00 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-rlfa-node-protection-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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: September 21, 2016 March 20, 2016 7 Node Protection for SR-TE Paths 8 draft-hegde-spring-node-protection-for-sr-te-paths-00 10 Abstract 12 Segment routing supports the creation of explicit paths using 13 adjacency-sids, node-sids, and binding-sids. It is important to 14 provide fast reroute (FRR) mechanisms to respond to failures of links 15 and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A 16 point of local repair (PLR) can provide FRR protection against the 17 failure of a link in an SR-TE path by examining only the first (top) 18 label in the SR label stack. In order to protect against the failure 19 of a node, a PLR may need to examine the second label in the stack as 20 well in order to determine SR-TE path beyond the failed node. This 21 document specifies how a PLR can use the first and second label in 22 the label stack describing an SR-TE path to provide protection 23 against node failures. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 September 21, 2016. 48 Copyright Notice 50 Copyright (c) 2016 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 (http://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 adj-sid explicit paths . . . . . . . 4 69 2.3. Node-protection of binding-sid explicit paths . . . . . . 5 70 3. Detailed Solution using Context Tables . . . . . . . . . . . 5 71 3.1. Building Context Tables . . . . . . . . . . . . . . . . . 5 72 3.2. Building node protecting paths for node-sids . . . . . . 5 73 3.2.1. Building node protecting paths for adjacency-sids . . 7 74 3.3. Node protection for binding sids . . . . . . . . . . . . 8 75 3.4. Node protection for edge nodes . . . . . . . . . . . . . 10 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 7.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 It is possible for a routing device to completely go out of service 87 abruptly due to power failure, hardware failure or software crashes. 88 Node protection is an important property of the Fast Reroute 89 mechanism. It provides protection against a node failure by 90 rerouting traffic around the failed node. For example, the 91 mechanisms described in Loop Free Alternates [RFC5286] and Remote 92 loop free alternates [I-D.ietf-rtgwg-rlfa-node-protection] can be 93 used to provide node protection to ensure minimal traffic loss after 94 a node failure. The solutions to provide node protection in this 95 draft use SPF based local protection mechanisms. 97 Section 2 describes problems with SR-TE paths and need for a 98 specialized mechanism to provide node protection for the SR-TE paths. 99 Section 3 describes the solution applied to paths built using 100 adjacency-sids, node-sids and binding-sids. Section 3.4 describes 101 the solution applied to egress node protection. 103 2. Node Failures Along SR-TE Paths 105 sid:1 sid:2 sid:3 sid:4 sid:5 106 1000-2000 1000-2000 1000-2000 1000-2000 1000-2000 107 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 108 | R1 |----| R2 |----| R3 |----- | R4 |-- | R5 | 109 +----+ +----+ +----+ +----+ +----+ 110 \ \ / 111 \ 10 \ 100 / 60 112 \ \ / 113 \ +----+ +----+ 114 +--| R7 |---------| R8 | 115 +----+ 30 +----+ 116 / sid:7 sid:8 Packet Header: 117 / 1000-2000 3000-4000 +------------+ 118 / 10 | 1008 | 119 +----+ +------------+ 120 | R6 | | 3005 | 121 +----+ +------------+ 122 sid:6 123 1000-2000 125 Figure 1: Sample Network 127 The topology shown in Figure 1. illustrates a sample network topology 128 with SPRING enabled on each node. The SRGB and the segment index 129 corresponding to each node is described in the topology diagram. 131 2.1. Node protection for node-sid explicit paths 133 Consider an explicit path from R1->R5 via R1->R7->R8->R4->R5. This 134 path can be built using R1->R8 and R8->R5 shortest paths. The label 135 stack contains two node-sids 1008 and 3005. The 1008 label would 136 take the packet to R8 and get popped. The next label in the stack 137 3005 would take the packet to the destination R5. If the node R8 138 goes down, it is not possible for R7 to perform FRR without examining 139 the second label in the incoming label stack (3005). R7 does not 140 need to understand the meaning of label 3005 in order to perform 141 normal forwarding in the absence of a failure. However, in order to 142 support node protection, R7 will need to understand the meaning of 143 label 3005 in order to determine where the packet is headed after R8. 145 Anycast addresses are in general advertised by more than one node and 146 if per-prefix LFA calculation [RFC5286] is used node protecting paths 147 can be found for the anycast sids. If a node protecting path is 148 available for the anycast sid then the context table lookup mechanism 149 would not be required. Otherwise, the anycast label has to be popped 150 and next label looked up to find where the packet should be 151 forwarded. 153 2.2. Node-protection for adj-sid explicit paths 155 R1-R2: R2-R3: R3-R8: R4-R5: 156 1024 1034 1044 1064 157 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 158 | R1 |----| R2 |----| R3 |-------| R4 |------| R5 | 159 +----+ +----+ +----+ +----+ +----+ 160 \ \ / 161 \ 10 \ 100 / 60 162 \ \ / 163 \ +----+ +----+ R8-R5: Label stack 164 +--| R7 |---------| R8 | 1054 for explicit 165 +----+ 30 +----+ R8-R7: path from 166 / 1074 R1->R5: 167 / +------------+ 168 / 10 | 1034 | 169 +----+ +------------+ 170 | R6 | | 1044 | 171 +----+ +------------+ 172 | 1054 | 173 +------------+ 174 | 1064 | 175 +------------+ 177 Figure 2: Explicit path using adjacency sids 179 Consider an explicit path from R1->R5 via R1->R2->R3->R8->R4->R5. 180 This path can be built using adjacency sids, as shown in Figure 2. 181 The diagram shows the adjacency sids advertised by each node required 182 to realize this path, as well as the complete label stack. When a 183 packet leaving R1 with this label stack reaches R3, the top of stack 184 contains the label 1044 which will take the packet to R8. The next- 185 next-hop in the path is R4. To provide protection for the failure of 186 node R8, R3 would need to send the the packet to R4 without going 187 through R8. However, the only way R3 can learn that the packet needs 188 to go to the R4 is to examine the next label in the stack, label 189 1054. 191 2.3. Node-protection of binding-sid explicit paths 193 Binding sids (defined in SR architecture 194 [I-D.ietf-spring-segment-routing]) allow the SR-TE path to be built 195 using a hierarchy of sub-paths. The binding sid provides a single 196 label to represent a set of nodes and links. If the node advertising 197 the binding sid goes down, the traffic needs to be protected. The 198 label stack involving the binding-sid contains next label in the 199 stack which corresponds to the end point represented by the binding- 200 sid. The penultimate node of the binding-sid advertiser cannot know 201 the meaning of the next label in the stack. 203 3. Detailed Solution using Context Tables 205 3.1. Building Context Tables 207 [RFC5331] introduced the concept of Context Specific Label Spaces and 208 there are various applications making use of this concept.A context 209 label table on a router represents the Label Information Base (LIB) 210 from the point of view of a particular neighbor . Context tables are 211 built by constructing incoming label mappings advertised by the 212 neighbor and the actions corresponding to those labels. The labels 213 advertised by each node are local to the node and may not be unique 214 across the segment routing domain. The context tables are separate 215 tables built on a per-neighbor basis on every node to ensure they 216 represent LIBs of a particular neighbor. 218 When a node learns the node-sid, SRGB, and adjacency-sids or binding- 219 sids from a neighbor, the label mapping is added to the context table 220 corresponding to that neighbor. The output actions for the label 221 mapping are derived based on the actions that the neighbor would 222 perform on receipt of the label. 224 The following section illustrates how the context table is 225 constructed to allow the PLR to provide node-protecting paths for the 226 next-next hops in the previous examples 228 3.2. Building node protecting paths for node-sids 229 R7's Transit Routing table 230 +=============+=================+ 231 |in-label | Out label | 232 +===========+=================+ 233 | 1001 | Fwd to R1, | 234 +=============+=================+ 235 | 1002 | swap 1002, Fwd | 236 | | to R1 | 237 +=============+=================+ 238 | 1003 | swap 1003, Fwd | 239 | | to R1 | 240 +=============+=================+ 241 | 1004 | swap 1004, | 242 | | Fwd to R1 | 243 +=============+=================+ 244 | 1005, | swap 1005, | 245 | | Fwd to R1 | 246 +=============+=================+ 247 | 1008, | pop, fwd to r8 | 248 | | *pop,lookup | 249 | | context.r8 | 250 +=============+=================+ 251 * - Indicates backup path. 253 R7's Context Table for R8 254 +=============+=================+ 255 |in-label | Out label | 256 +=============+=================+ 257 | 3001 | Fwd to R1, | 258 +=============+=================+ 259 | 3002 | swap 1002, Fwd | 260 | | to R1 | 261 +=============+=================+ 262 | 3003 | swap 1003, Fwd | 263 | | to R1 | 264 +=============+=================+ 265 | 3004 | swap 1004, | 266 | | Fwd to R1 | 267 +=============+=================+ 268 | 3005, | swap 1005, | 269 | | Fwd to R1 | 270 +=============+=================+ 272 Figure 3: Transit routing table and Context Table at R7 274 The above Figure 3 shows the transit routing table and the context 275 table of neighbor R8 built at R7 for the example network shown in 276 Figure 1. When the adjacency with R8 comes up, R7 builds the context 277 table for R8 and adds the label mappings to the context table by 278 adding the node-sid index of all the nodes to the SRGB advertised by 279 R8. The output action is constructed by looking into the R7's SPF 280 and backup SPF computations for the next-nexthop. The backup SPF 281 computations as defined in LFA [RFC5286] are applicable here. The 282 R7's SPF and backup SPF computations for the next-nexthop may provide 283 multiple loop free primary or backup paths. A loop free path that 284 does not include the failure node (R8 in this example) is chosen and 285 downloaded to the context table. 287 R7's routing table entry for R8's sid i.e label 1008 will have a pop 288 and forward action and the backup path SHOULD have action pop and 289 lookup into the context table of R8. When the node R7 detects R8 290 goes down, R7's forwarding plane does a local repair and points to 291 the backup path. When a packet whose top label is 1008 arrives at 292 R7, the top label is popped, and the next label is looked up in the 293 context table for R8. As shown in Figure 3, if the next label is 294 3005, the packet will be directed to R5 along a path that avoids R8. 296 3.2.1. Building node protecting paths for adjacency-sids 297 R3's Transit Routing table (partial) 298 +=============+=================+ 299 |in-label | Out label | 300 +=============+=================+ 301 | 1044 | pop,Fwd to R8, | 302 | |*pop, lookup | 303 | |context.r8 | 304 +=============+=================+ 305 | 1004 | pop, Fwd to R4 | 306 | | *push 3004, | 307 | | fwd to R8 | 308 +=============+=================+ 310 * - Indicates backup path. 312 R3's Context Table for R8 (partial) 313 +=============+=================+ 314 |in-label | Out label | 315 +=============+=================+ 316 | 1054 | pop,Fwd to R4, | 317 +=============+=================+ 318 | 1074 | swap 1007, Fwd | 319 | | to R2 | 320 +=============+=================+ 322 Figure 4: Context Table at R3 324 The processing for the packet is similar to mechanism explained for 325 node sids in section Section 3.2. 327 Figure 4 shows the context table constructed at R3 corresponding to 328 R8 for the sample network shown in Figure 2. Adjacency sids are 329 attached to the link advertisements in IGPs and the link 330 advertisements contain the node information of the remote end. When 331 R3 learns adjacency sids from R8, it builds context table for R8 332 which contains the adjacency labels advertised by R8 and the output 333 action is built by looking at R3's own SPF and backup SPF 334 computations for the remote end point of the link. Among the 335 multiple primary/backup paths to the remote end of the link, a loop 336 free path that does not pass through R8 is chosen. 338 3.3. Node protection for binding sids 339 sid:1 sid:2 sid:3 sid:4 sid:5 340 1000-2000 1000-2000 1000-2000 1000-2000 1000-2000 341 R1-R2: R2-R3: R3-R8: R4-R5: 342 1024 1034 1044 1064 343 R4:2014 ========================= 344 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 345 | R1 |----| R2 |----| R3 |-------| R4 |-- | R5 | 346 +----+ +----+ +----+ +----+ +----+ 347 \ \ / 348 \ 10 \ 100 / 60 349 \ \ / 350 \ +----+ +----+ 351 +--| R7 |---------| R8 | R8-R4:1054 352 +----+ 30 +----+ R8-R7:1074 353 / sid:7 sid:8 354 / 1000-2000 3000-4000 355 / 10 356 +----+ 357 | R6 | Explicit path from R1->R5: 358 +----+ +------------+ 359 sid:6 | 2014 | 360 1000-2000 +------------+ 361 | 1064 | 362 +------------+ 364 Figure 5: Node Protection for Binding SID 366 Figure Section 3.3 describes a sample network where R2 advertises a 367 binding sid 2014 for the path R2->R3->R4. This mechanism is very 368 useful in compressing the label stack depth as a sub-path can be 369 represented using a single label. The explicit path 370 R1->R2->R3->R4->R5 can be represented by 2 label stack as shown in 371 above figure. If the node that advertises the binding-sid goes down, 372 protection mechanisms are needed for the binding sid that the node 373 advertised. A receiving node that programs a forwarding path for the 374 binding sid should find a node protecting path to the last node of 375 the path represented by the binding sid. In the above sample 376 network, R1 programs a backup path for binding sid 2014 with the node 377 protecting R-LFA path to R4 which consists of two labels [1008, 378 1004]. When the packet reached R4, it has the label 1064 in the 379 label stack and can recognize this label and forward to R5. The node 380 protecting path could be computed using various FRR technologies like 381 LFA [RFC5286], Remote-LFA [RFC7490] , TI-LFA 382 [I-D.francois-rtgwg-segment-routing-ti-lfa] etc. 384 3.4. Node protection for edge nodes 386 sid:1 sid:2 sid:3 sid:4 sid:5 387 1000-2000 1000-2000 1000-2000 1000-2000 1000-2000 388 R2:1024 R3:1034 R8:1044 R5:1064 389 R4:2014 ========================= 390 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ 391 | PE1|----| R2 |----| R3 |-------| R4 |-- | PE2| context 1.1.1.1: sid 10 392 +----+ +----+ +----+ +----+ +----+\ 393 \ \ / \+-----+ 394 \ 10 \ 100 / 60 /| CE1 | 395 \ \ / / +-----+ 396 \ +----+ +----+ R4:1054 +-----+ 397 +--| R7 |---------| R8 | --------| PE3 |context 1.1.1.1 398 +----+ 30 +----+ +-----+sid 10 399 / sid:7 sid:8 400 / 1000-2000 3000-4000 401 / 10 402 +----+ 403 | R6 | 404 +----+ 405 sid:6 406 1000-2000 408 Figure 6: Node Protection for edge nodes 410 The node protection mechanisms that are described in previous 411 sections depend on the assumption that the label below the top label 412 in the label stack are understood in the IGP domain. If the edge 413 node goes down, the label below the top label representing the edge 414 node could be BGP service label or labels representing other 415 applications. Service mirroring use case is described in 416 [I-D.filsfils-spring-segment-routing-use-cases] The Customer edges 417 are multi-homed to provider edges and one of the PE's acts in primary 418 role and the other in protector role. The two PEs advertise a 419 context ip address for each customer site and attaches a prefix-sid 420 to the context. The protector PE advertises a binding sid with M bit 421 set which implies mirroring capability for the context. Protector PE 422 builds the context table for the BGP service labels advertised by the 423 primary PE for the same context. The BGP service is built using 424 stack of labels with context-sid at the bottom of the label 425 stack.when the label ranges advertised by the PE2 and the penultimate 426 node, Penultimate node does not understand the bottom label which is 427 advertised by the node PE2. Any penultimate node of PE2 builds a 428 context table for PE2 as explained in the section Section 3.1. This 429 context table contains the sid for the context-id and output action 430 is to pop the top label and replace with the binding sid that the 431 protector PE advertised for the context 1.1.1.1. The binding sid 432 directs the protector PE to lookup the context table of Primary PE 433 for the BGP service labels. The node protection mechanisms described 434 in this document also ensure the edge node protection when uniform 435 label range is not assigned across the entire IGP domain. 437 4. Security Considerations 439 TBD 441 5. IANA Considerations 443 6. Acknowledgments 445 Thanks to Eric Rosen for valuable inputs on the document and 446 Chandrasekar Ramachandran for discussions on the topic. 448 7. References 450 7.1. Normative References 452 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 453 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 454 DOI 10.17487/RFC5286, September 2008, 455 . 457 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 458 Label Assignment and Context-Specific Label Space", 459 RFC 5331, DOI 10.17487/RFC5331, August 2008, 460 . 462 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 463 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 464 RFC 7490, DOI 10.17487/RFC7490, April 2015, 465 . 467 7.2. Informative References 469 [I-D.filsfils-spring-segment-routing-use-cases] 470 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 471 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 472 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 473 Crabbe, "Segment Routing Use Cases", draft-filsfils- 474 spring-segment-routing-use-cases-01 (work in progress), 475 October 2014. 477 [I-D.francois-rtgwg-segment-routing-ti-lfa] 478 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 479 "Topology Independent Fast Reroute using Segment Routing", 480 draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in 481 progress), August 2015. 483 [I-D.ietf-rtgwg-rlfa-node-protection] 484 Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S. 485 Litkowski, "Remote-LFA Node Protection and Manageability", 486 draft-ietf-rtgwg-rlfa-node-protection-05 (work in 487 progress), December 2015. 489 [I-D.ietf-spring-segment-routing] 490 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 491 and R. Shakir, "Segment Routing Architecture", draft-ietf- 492 spring-segment-routing-07 (work in progress), December 493 2015. 495 [I-D.minto-rsvp-lsp-egress-fast-protection] 496 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 497 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 498 protection-03 (work in progress), November 2013. 500 [ISO10589] 501 "Intermediate system to Intermediate system intra-domain 502 routeing information exchange protocol for use in 503 conjunction with the protocol for providing the 504 connectionless-mode Network Service (ISO 8473), ISO/IEC 505 10589:2002, Second Edition.", Nov 2002. 507 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 508 dual environments", RFC 1195, DOI 10.17487/RFC1195, 509 December 1990, . 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 517 DOI 10.17487/RFC2328, April 1998, 518 . 520 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 521 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 522 . 524 Authors' Addresses 526 Shraddha Hegde 527 Juniper Networks, Inc. 528 Exora Business Park 529 Bangalore, KA 560103 530 India 532 Email: shraddha@juniper.net 534 Chris Bowers 535 Juniper Networks, Inc. 537 Email: cbowers@juniper.net