idnits 2.17.1 draft-francois-rtgwg-segment-routing-ti-lfa-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 : ---------------------------------------------------------------------------- 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 has text resembling RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2016) is 2688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Adjacency' on line 390 -- Looks like a reference, but probably isn't: 'Node' on line 390 == Unused Reference: '3' is defined on line 511, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Pierre Francois 2 Internet Draft Individual Contributor 3 Intended status: Informational A. Bashandy 4 Expires: June 2017 C. Filsfils 5 Cisco Systems 6 Bruno Decraene 7 Stephane Litkowski 8 Orange 9 December 8, 2016 10 Topology Independent Fast Reroute using Segment Routing 11 draft-francois-rtgwg-segment-routing-ti-lfa-03 13 Abstract 15 This document presents Topology Independent Loop-free Alternate Fast 16 Re-route (TI-LFA), aimed at providing protection of node and 17 adjacency segments within the Segment Routing (SR) framework. This 18 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 19 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 20 (DLFA). It extends these concepts to provide guaranteed coverage in 21 any IGP network. A key aspect of TI-LFA is the FRR path selection 22 approach establishing protection over post-convergence paths from the 23 point of local repair, dramatically reducing the operational need to 24 control the tie-breaks among various FRR options. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or IETF 32 Contributions published or made publicly available before November 33 10, 2008. The person(s) controlling the copyright in some of this 34 material may not have granted the IETF Trust the right to allow 35 modifications of such material outside the IETF Standards Process. 36 Without obtaining an adequate license from the person(s) 37 controlling the copyright in such materials, this document may not 38 be modified outside the IETF Standards Process, and derivative 39 works of it may not be created outside the IETF Standards Process, 40 except to format it for publication as an RFC or to translate it 41 into languages other than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other 50 documents at any time. It is inappropriate to use Internet-Drafts 51 as reference material or to cite them other than as "work in 52 progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This Internet-Draft will expire on May 8, 2016. 62 Copyright Notice 64 Copyright (c) 2016 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with 72 respect to this document. Code Components extracted from this 73 document must include Simplified BSD License text as described in 74 Section 4.e of the Trust Legal Provisions and are provided without 75 warranty as described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction...................................................3 80 1.1. Conventions used in this document.........................5 81 2. Terminology....................................................5 82 3. Intersecting P-Space and Q-Space with post-convergence paths...6 83 3.1. P-Space property computation for a resource X.............6 84 3.2. Q-Space property computation for a link S-F, over post- 85 convergence paths..............................................6 86 3.3. Q-Space property computation for a set of links adjacent to 87 S, over post-convergence paths.................................6 88 3.4. Q-Space property computation for a node F, over post- 89 convergence paths..............................................7 90 4. TI-LFA Repair Tunnel...........................................7 91 4.1. The repair node is a direct neighbor......................7 92 4.2. The repair node is a PQ node..............................7 93 4.3. The repair is a Q node, neighbor of the last P node.......7 94 4.4. Connecting distant P and Q nodes along post-convergence 95 paths..........................................................8 96 5. Protecting segments............................................8 97 5.1. The active segment is a node segment......................8 98 5.2. The active segment is an adjacency segment................8 99 5.2.1. Protecting [Adjacency, Adjacency] segment lists......8 100 5.2.2. Protecting [Adjacency, Node] segment lists...........9 101 5.3. Protecting SR policy midpoints against node failure.......9 102 5.3.1. Protecting {F, T, D} or {S->F, T, D}.................9 103 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D}..........10 104 6. Security Considerations.......................................11 105 7. IANA Considerations...........................................11 106 8. Conclusions...................................................11 107 9. References....................................................11 108 9.1. Normative References.....................................11 109 9.2. Informative References...................................11 110 10. Acknowledgments..............................................12 112 1. Introduction 114 Segment Routing aims at supporting services with tight SLA 115 guarantees [1]. This document provides a local repair mechanism 116 relying on SR-capable of restoring end-to-end connectivity in the 117 case of a sudden failure of a network component. 119 For each destination in the network, TI-LFA prepares a data-plane 120 switch-over to be activated upon detection of the failure of a 121 link used to reach the destination. TI-LFA provides protection 122 against link failure, node failure, and local SRLG failures. In 123 link failure mode, the destination is protected assuming the 124 failure of the link. In node protection mode, the destination is 125 protected assuming that the neighbor connected to the primary link 126 has failed. In local SRLG protecting mode, the destination is 127 protected assuming that a configured set of links sharing fate 128 with the primary link has failed (e.g. a linecard). 130 Using segment routing, there is no need to establish TLDP sessions 131 with remote nodes in order to take advantage of the applicability 132 of remote LFAs (RLFA) or remote LFAs with directed forwarding 133 (DLFA)[2]. As a result, preferring LFAs over RLFAs or DLFAs, as 134 well as minimizing the number of RLFA or DLFA repair nodes is not 135 required. This allows for a protection path selection approach 136 meeting operational needs rather than a topologically constrained 137 one. 139 Using SR, there is no need to create state in the network in order 140 to enforce an explicit FRR path. As a result, we can use 141 optimized detour paths for each specific destination and for each 142 type of failure without creating additional forwarding state. 143 Also, the mode of protection (link, node, SRLG) is not constrained 144 to be network wide or node wide, but can be managed on a per 145 interface basis. 147 Building on such an easier forwarding environment, the FRR 148 behavior suggested in this document tailors the repair paths over 149 the post-convergence path from the PLR to the protected 150 destination, given the enabled protection mode for the interface. 152 As the capacity of the post-convergence path is typically planned 153 by the operator to support the post-convergence routing of the 154 traffic for any expected failure, there is much less need for the 155 operator to tune the decision among which protection path to 156 choose. The protection path will automatically follow the natural 157 backup path that would be used after local convergence. This also 158 helps to reduce the amount of path changes and hence service 159 transients: one transition (pre-convergence to post-convergence) 160 instead of two (pre-convergence to FRR and then post-convergence). 162 We provide the TI-LFA approach that achieves guaranteed coverage 163 against link, node, and local SRLG failure, in any IGP network, 164 relying on the flexibility of SR. 166 L ____ 167 S----F--{____}----D 168 /\ | / 169 | | | _______ / 170 |__}---Q{_______} 172 Figure 1 TI-LFA Protection 174 We use Figure 1 to illustrate the TI-LFA approach. 176 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 177 node) that is capable of safely forwarding the traffic to a 178 destination D affected by the failure of the protected link L, a set 179 of adjacent links including L (local SRLG), or the node F itself. 180 The PLR also needs to find a way to reach Q without being affected 181 by the convergence state of the nodes over the paths it wants to use 182 to reach Q. 184 In Section 2 we define the main notations used in the document. 185 They are in line with [2]. 187 In Section 3, we suggest to compute the P-Space and Q-Space 188 properties defined in Section 2, for the specific case of nodes 189 lying over the post-convergence paths towards the protected 190 destinations. 192 Using the properties defined in Section 3, we describe how to 193 compute protection lists that encode a loopfree post-convergence 194 towards the destination, in Section 4. 196 Finally, we define the segment operations to be applied by the PLR 197 to ensure consistency with the forwarding state of the repair node, 198 in Section 5. 200 1.1. Conventions used in this document 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 203 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 204 in this document are to be interpreted as described in RFC-2119 206 In this document, these words will appear with that interpretation 207 only when in ALL CAPS. Lower case uses of these words are not to 208 be interpreted as carrying RFC-2119 significance. 210 2. Terminology 212 We define the main notations used in this document as the following. 214 We refer to "old" and "new" topologies as the LSDB state before and 215 after the considered failure. 217 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 218 state of the network. 220 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the 221 state of the network after the resource X has failed. 223 Dist_old(A,B) is the distance from node A to node B in SPT_old(A). 225 Dist_new(A,B, X) is the distance from node A to node B in 226 SPT_new(A,X). 228 Similarly to [4], we rely on the concept of P-Space and Q-Space for 229 TI-LFA. 231 The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, 232 a node F, or a local SRLG) is the set of nodes that are reachable 233 from R without passing through X. It is the set of nodes that are 234 not downstream of X in SPT_old(R). 236 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 237 set of nodes that are reachable from R or a neighbor of R, without 238 passing through X. 240 The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is 241 the set of nodes which do not use X to reach D in the initial state 242 of the network. In other words, it is the set of nodes which have D 243 in their P-Space w.r.t. S-F, F, or a set of links adjacent to S). 245 A symmetric network is a network such that the IGP metric of each 246 link is the same in both directions of the link. 248 3. Intersecting P-Space and Q-Space with post-convergence paths 250 In this section, we suggest to determine the P-Space and Q-Space 251 properties of the nodes along the post-convergence paths from the 252 PLR to the protected destination and compute an SR-based explicit 253 path from P to Q when they are not adjacent. Such properties will 254 be used in Section 4 to compute the TI-LFA repair list. 256 3.1. P-Space property computation for a resource X 258 A node N is in P(R, X) if it is not downstream of X in SPT_old(R). 259 X can be a link, a node, or a set of links adjacent to the PLR. A 260 node N is in P'(R,X) if it is not downstream of X in SPT_old(N), 261 for at least one neighbor N of R. 263 3.2. Q-Space property computation for a link S-F, over post- 264 convergence paths 266 We want to determine which nodes on the post-convergence path from 267 the PLR to the destination D are in the Q-Space of destination D 268 w.r.t. link S-F. 270 This can be found by intersecting the post-convergence path to D, 271 assuming the failure of S-F, with Q(D, S-F). 273 3.3. Q-Space property computation for a set of links adjacent to 274 S, over post-convergence paths 276 We want to determine which nodes on the post-convergence path from 277 the PLR to the destination D are in the Q-Space of destination D 278 w.r.t. a set of links adjacent to S (S being the PLR). That is, we 279 aim to find the set of nodes on the post-convergence path that use 280 none of the members of the protected set of links, to reach D. 282 This can be found by intersecting the post-convergence path to D, 283 assuming the failure of the set of links, with the intersection 284 among Q(D, S->X) for all S->X belonging to the set of links. 286 3.4. Q-Space property computation for a node F, over post- 287 convergence paths 289 We want to determine which nodes on the post-convergence from the 290 PLR to the destination D are in the Q-Space of destination D w.r.t. 291 node F. 293 This can be found by intersecting the post-convergence path to D, 294 assuming the failure of F, with Q(D, F). 296 4. TI-LFA Repair Tunnel 298 The TI-LFA repair tunnel consists of an outgoing interface and a 299 list of segments (repair list) to insert on the SR header. The 300 repair list encodes the explicit post-convergence path to the 301 destination, which avoids the protected resource X. 303 The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) 304 with the post-convergence path to D and computing the explicit SR- 305 based path EP(P, Q) from P to Q when these nodes are not adjacent 306 along the post convergence path. The TI-LFA repair list is 307 expressed generally as (Node_SID(P), EP(P, Q)). 309 Most often, the TI-LFA repair list has a simpler form, as described 310 in the following sections. 312 4.1. The repair node is a direct neighbor 314 When the repair node is a direct neighbor, the outgoing interface is 315 set to that neighbor and the repair segment list is empty. 317 This is comparable to a post-convergence LFA FRR repair. 319 4.2. The repair node is a PQ node 321 When the repair node is in P(S,X), the repair list is made of a 322 single node segment to the repair node. 324 This is comparable to a post-convergence RLFA repair tunnel. 326 4.3. The repair is a Q node, neighbor of the last P node 328 When the repair node is adjacent to P(S,X), the repair list is made 329 of two segments: A node segment to the adjacent P node, and an 330 adjacency segment from that node to the repair node. 332 This is comparable to a post-convergence DLFA repair tunnel. 334 4.4. Connecting distant P and Q nodes along post-convergence paths 336 In some cases, there is no adjacent P and Q node along the post- 337 convergence path. However, the PLR can perform additional 338 computations to compute a list of segments that represent a loopfree 339 path from P to Q. 341 5. Protecting segments 343 In this section, we explain how a protecting router S processes the 344 active segment of a packet upon the failure of its primary outgoing 345 interface for the packet, S-F. 347 The behavior depends on the type of active segment to be protected. 349 5.1. The active segment is a node segment 351 The active segment is kept on the SR header, unchanged (1). The 352 repair list is inserted at the head of the list. The active segment 353 becomes the first segment of the inserted repair list. 355 Note (1): If the SRGB at the repair node is different from the SRGB 356 at the PLR, then the active segment must be updated to fit the SRGB 357 of the repair node. 359 In Section 5.3, we describe the node protection behavior of PLR S, 360 for the specific case where the active segment is a prefix segment 361 for the neighbor F itself. 363 5.2. The active segment is an adjacency segment 365 We define hereafter the FRR behavior applied by S for any packet 366 received with an active adjacency segment S-F for which protection 367 was enabled. We distinguish the case where this active segment is 368 followed by another adjacency segment from the case where it is 369 followed by a node segment. 371 5.2.1. Protecting [Adjacency, Adjacency] segment lists 373 If the next segment in the list is an Adjacency segment, then the 374 packet has to be conveyed to F. 376 To do so, S applies a "NEXT" operation on Adj(S-F) and then two 377 consecutive "PUSH" operations: first it pushes a node segment for F, 378 and then it pushes a protection list allowing to reach F while 379 bypassing S-F. 381 Upon failure of S-F, a packet reaching S with a segment list 382 matching [adj(S-F),adj(M),...] will thus leave S with a segment list 383 matching [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel 384 for destination F. 386 In Section 5.3.2, we describe the TI-LFA behavior of PLR S when 387 node protection is applied and the two first segments are Adjacency 388 Segments. 390 5.2.2. Protecting [Adjacency, Node] segment lists 392 If the next segment in the stack is a node segment, say for node T, 393 the packet segment list matches [adj(S-F),node(T),...]. 395 A first solution would consist in steering the packet back to F 396 while avoiding S-F. To do so, S applies a "NEXT" operation on 397 Adj(S-F) and then two consecutive "PUSH" operations: first it pushes 398 a node segment for F, and then it pushes a repair list allowing to 399 reach F while bypassing S-F. 401 Upon failure of S-F, a packet reaching S with a segment list 402 matching [adj(S-F),node(T),...] will thus leave S with a segment 403 list matching [RT(F),node(F),node(T)]. 405 Another solution is to not steer the packet back via F but rather 406 follow the new shortest path to T. In this case, S just needs to 407 apply a "NEXT" operation on the Adjacency segment related to S-F, 408 and push a repair list redirecting the traffic to a node Q, whose 409 path to node segment T is not affected by the failure. 411 Upon failure of S-F, packets reaching S with a segment list matching 412 [adj(L), node(T), ...], would leave S with a segment list matching 413 [RT(Q),node(T), ...]. Note that this second behavior is the one 414 followed for node protection, as described in Section 5.3.1. 416 5.3. Protecting SR policy midpoints against node failure 418 As planned in the previous version of this document, we describe the 419 behavior of a node S configured to interpret the failure of link S- 420 >F as the node failure of F, in the specific case where the active 421 segment of the packet received by S is a Prefix SID of F represented 422 as "F"), or an Adjacency SID for the link S-F (represented as "S- 423 >F"). 425 5.3.1. Protecting {F, T, D} or {S->F, T, D} 427 We describe the protection behavior of S when 428 1. the active segment is a prefix SID for a neighbor F, or an 429 adjacency segment S->F 431 2. the primary interface used to forward the packet failed 433 3. the segment following the active segment is a prefix SID (for 434 node T) 436 4. node protection is active for that interface. 438 The TILFA Node FRR behavior becomes equivalent to: 440 1. Pop; the segment F or S->F is removed 442 2. Confirm that the next segment is in the SRGB of F, meaning that 443 the next segment is a prefix segment, e.g. for node T 445 3. Identify T (as per the SRGB of F) 447 4. Pop the next segment and push T's segment based on the local SRGB 449 5. forward the packet according to T. 451 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 453 We describe the protection behavior of S when 455 1. the active segment is a prefix SID for a neighbor F, or an 456 adjacency segment S->F 458 2. the primary interface used to forward the packet failed 460 3. the segment following the active segment is an adjacency SID (F- 461 >T) 463 4. node protection is active for that interface. 465 The TILFA Node FRR behavior becomes equivalent to: 467 1. Pop; the segment F or S->F is removed 469 2. Confirm that the next segment is an adjacency SID of F, say F->T 471 3. Identify T (as per the set of Adjacency Segments of F) 473 4. Pop the next segment and push T's segment based on the local SRGB 475 5. forward the packet according to T. 477 6. Security Considerations 479 The behavior described in this document is internal functionality 480 to a router that result in the ability to guarantee an upper bound 481 on the time taken to restore traffic flow upon the failure of a 482 directly connected link or node. As such no additional security 483 risk is introduced by using the mechanisms proposed in this 484 document. 486 7. IANA Considerations 488 No requirements for IANA 490 8. Conclusions 492 This document proposes a mechanism that is able to pre-calculate a 493 backup path for every primary path so as to be able to protect 494 against the failure of a directly connected link or node. The 495 mechanism is able to calculate the backup path irrespective of the 496 topology as long as the topology is sufficiently redundant. 498 9. References 500 9.1. Normative References 502 9.2. Informative References 504 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 505 Shakir, "Segment Routing Architecture", draft-ietf-spring- 506 segment-routing-08 (work in progress), May 2016. 508 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 509 5714, January 2010. 511 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, 512 J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 513 Applicability in Service Provider (SP) Networks", RFC 6571, 514 June 2012. 516 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, 517 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 518 7490, DOI 10.17487/RFC7490, April 2015, . 521 10. Acknowledgments 523 This document was prepared using 2-Word-v2.0.template.dot. 525 Authors' Addresses 527 Pierre Francois 528 pfrpfr@gmail.com 530 Ahmed Bashandy 531 Cisco Systems 532 170 West Tasman Dr, San Jose, CA 95134, USA 533 Email: bashandy@cisco.com 535 Clarence Filsfils 536 Cisco Systems 537 Brussels, Belgium 538 Email: cfilsfil@cisco.com 540 Bruno Decraene 541 Orange 542 Issy-les-Moulineaux 543 FR 544 Email: bruno.decraene@orange.com 546 Stephane Litkowski 547 Orange 548 FR 549 Email: bruno.decraene@orange.com