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