idnits 2.17.1 draft-francois-rtgwg-segment-routing-ti-lfa-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2016) is 2898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Adjacency' on line 354 -- Looks like a reference, but probably isn't: 'Node' on line 354 == Unused Reference: '3' is defined on line 438, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 ** Downref: Normative reference to an Informational RFC: RFC 5714 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 6571 (ref. '3') Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft Clarence Filsfils 4 Intended status: Standards Track Ahmed Bashandy 5 Expires: November 18, 2016 Cisco Systems, Inc. 6 Bruno Decraene 7 Stephane Litkowski 8 Orange 9 May 17, 2016 11 Topology Independent Fast Reroute using Segment Routing 12 draft-francois-rtgwg-segment-routing-ti-lfa-01 14 Abstract 16 This document presents Topology Independent Loop-free Alternate Fast 17 Re-route (TI-LFA), aimed at providing protection of node and 18 adjacency segments within the Segment Routing (SR) framework. This 19 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 20 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 21 (DLFA). It extends these concepts to provide guaranteed coverage in 22 any IGP network. A key aspect of TI-LFA is the FRR path selection 23 approach establising protection over post-convergence paths from the 24 point of local repair, dramatically reducing the operational need to 25 control the tie-breaks among various FRR options. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 18, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Intersecting P-Space and Q-Space with post-convergence 64 paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. P-Space property computation for a resource X . . . . . . 5 66 3.2. Q-Space property computation for a link S-F, over 67 post-convergence paths . . . . . . . . . . . . . . . . . . 6 68 3.3. Q-Space property computation for a set of links 69 adjacent to S, over post-convergence paths . . . . . . . . 6 70 3.4. Q-Space property computation for a node F, over 71 post-convergence paths . . . . . . . . . . . . . . . . . . 6 72 4. TI-LFA Repair Tunnel . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. The repair node is a direct neighbor . . . . . . . . . . . 7 74 4.2. The repair node is a PQ node . . . . . . . . . . . . . . . 7 75 4.3. The repair is a Q node, neighbor of the last P node . . . 7 76 4.4. Connecting distant P and Q nodes along 77 post-convergence paths . . . . . . . . . . . . . . . . . . 7 78 5. Protecting segments . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. The active segment is a node segment . . . . . . . . . . . 7 80 5.2. The active segment is an adjacency segment . . . . . . . . 8 81 5.2.1. Protecting [Adjacency, Adjacency] segment lists . . . 8 82 5.2.2. Protecting [Adjacency, Node] segment lists . . . . . . 8 83 5.3. Protecting SR policy midpoints against node failure . . . 9 84 5.3.1. Protecting {F, T, D} or {S->F, T, D} . . . . . . . . . 9 85 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} . . . . . . 9 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 Segment Routing aims at supporting services with tight SLA guarantees 92 [1]. This document provides a local repair mechanism relying on SR, 93 capable of restoring end-to-end connectivity in the case of a sudden 94 failure of a network component. 96 For each destination in the network, TI-LFA prepares a data-plane 97 switch-over to be activated upon detection of the failure of a link 98 used to reach the destination. TI-LFA provides protection against 99 link failure, node failure, and local SRLG failures. In link failure 100 mode, the destination is protected assuming the failure of the link. 101 In node protection mode, the destination is protected assuming that 102 the neighbour connected to the primary link has failed. In local 103 SRLG protecting mode, the destination is protected assuming that a 104 configured set of links sharing fate with the primary link has failed 105 (e.g. a linecard). 107 Using segment routing, there is no need to establish TLDP sessions 108 with remote nodes in order to take advantage of the applicability of 109 remote LFAs (RLFA) or remote LFAs with directed forwarding (DLFA) 110 [2]. As a result, preferring LFAs over RLFAs or DLFAs, as well as 111 minimizing the number of RLFA or DLFA repair nodes is not required. 112 This allows for a protection path selection approach meeting 113 operational needs rather than a topologically constrained one. 115 Using SR, there is no need to create state in the network in order to 116 enforce an explicit FRR path. As a result, we can use optimized 117 detour paths for each specific destination and for each type of 118 failure without creating additional forwarding state. Also, the mode 119 of protection (link, node, SRLG) is not constrained to be network 120 wide or node wide, but can be managed on a per interface basis. 122 Building on such an easier forwarding environment, the FRR behavior 123 suggested in this document tailors the repair paths over the post- 124 convergence path from the PLR to the protected destination, given the 125 enabled protection mode for the interface. 127 As the capacity of the post-convergence path is typically planned by 128 the operator to support the post-convergence routing of the traffic 129 for any expected failure, there is much less need for the operator to 130 tune the decision among which protection path to choose. The 131 protection path will automatically follow the natural backup path 132 that would be used after local convergence. This also helps to 133 reduce the amount of path changes and hence service transients: one 134 transition (pre-convergence to post-convergence) instead of two (pre- 135 convergence to FRR and then post-convergence). 137 We provide the TI-LFA approach that achieves guaranteed coverage 138 against link, node, and local SRLG failure, in any IGP network, 139 relying on the flexibility of SR. 141 L ____ 142 S----F--{____}----D 143 /\ | / 144 | | | _______ / 145 |__}---Q{_______} 147 Figure 1: TI-LFA Protection 149 We use Figure 1 to illustrate the TI-LFA approach. 151 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 152 node) that is capable of safely forwarding the traffic to a 153 destination D affected by the failure of the protected link L, a set 154 of adjacent links including L (local SRLG), or the node F itself. 155 The PLR also needs to find a way to reach Q without being affected by 156 the convergence state of the nodes over the paths it wants to use to 157 reach Q. 159 In Section 2 we define the main notations used in the document. They 160 are in line with [2]. 162 In Section 3, we suggest to compute the P-Space and Q-Space 163 properties defined in Section 2, for the specific case of nodes lying 164 over the post-convergence paths towards the protected destinations. 166 Using the properties defined in Section 3, we describe how to compute 167 protection lists that encode a loopfree post-convergence towards the 168 destination, in Section 4. 170 Finally, we define the segment operations to be applied by the PLR to 171 ensure consistency with the forwarding state of the repair node, in 172 Section 5. 174 2. Terminology 176 We define the main notations used in this document as the following. 178 We refer to "old" and "new" topologies as the LSDB state before and 179 after the considered failure. 181 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 182 state of the network. 184 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the state 185 of the network after the resource X has failed. 187 Dist_old(A,B) is the distance from node A to node B in SPT_old(A). 189 Dist_new(A,B, X) is the distance from node A to node B in SPT_new(A, 190 X). 192 Similarly to [4], we rely on the concept of P-Space and Q-Space for 193 TI-LFA. 195 The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, 196 a node F, or a local SRLG) is the set of nodes that are reachable 197 from R without passing through X. It is the set of nodes that are not 198 downstream of X in SPT_old(R). 200 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 201 set of nodes that are reachable from R or a neighbor of R, without 202 passing through X. 204 The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is the 205 set of nodes which do not use X to reach D in the initial state of 206 the network. In other words, it is the set of nodes which have D in 207 their P-Space w.r.t. S-F, F, or a set of links adjacent to S). 209 A symmetric network is a network such that the IGP metric of each 210 link is the same in both directions of the link. 212 3. Intersecting P-Space and Q-Space with post-convergence paths 214 In this section, we suggest to determine the P-Space and Q-Space 215 properties of the nodes along the post-convergence paths from the PLR 216 to the protected destination and compute an SR-based explicit path 217 from P to Q when they are not adjacent. Such properties will be used 218 in Section 4 to compute the TI-LFA repair list. 220 3.1. P-Space property computation for a resource X 222 A node N is in P(R, X) if it is not downstream of X in SPT_old(R). X 223 can be a link, a node, or a set of links adjacent to the PLR 224 A node N is in P'(R,X) if it is not downstream of X in SPT_old(N), 225 for at least one neighbor N of R. 227 3.2. Q-Space property computation for a link S-F, over post-convergence 228 paths 230 We want to determine which nodes on the post-convergence path from 231 the PLR to the destination D are in the Q-Space of destination D 232 w.r.t. link S-F. 234 This can be found by intersecting the post-convergence path to D, 235 assuming the failure of S-F, with Q(D, S-F). 237 3.3. Q-Space property computation for a set of links adjacent to S, 238 over post-convergence paths 240 We want to determine which nodes on the post-convergence path from 241 the PLR to the destination D are in the Q-Space of destination D 242 w.r.t. a set of links adjacent to S (S being the PLR). That is, we 243 aim to find the set of nodes on the post-convergence path that use 244 none of the members of the protected set of links, to reach D. 246 This can be found by intersecting the post-convergence path to D, 247 assuming the failure of the set of links, with the intersection among 248 Q(D, S->X) for all S->X belonging to the set of links. 250 3.4. Q-Space property computation for a node F, over post-convergence 251 paths 253 We want to determine which nodes on the post-convergence from the PLR 254 to the destination D are in the Q-Space of destination D w.r.t. node 255 F. 257 This can be found by intersecting the post-convergence path to D, 258 assuming the failure of F, with Q(D, F). 260 4. TI-LFA Repair Tunnel 262 The TI-LFA repair tunnel consists of an outgoing interface and a list 263 of segments (repair list) to insert on the SR header. The repair 264 list encodes the explicit post-convergence path to the destination, 265 which avoids the protected resource X. 267 The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) 268 with the post-convergence path to D and computing the explicit SR- 269 based path EP(P, Q) from P to Q when these nodes are not adjacent 270 along the post convergence path. The TI-LFA repair list is expressed 271 generally as (Node_SID(P), EP(P, Q)). 273 Most often, the TI-LFA repair list has a simpler form, as described 274 in the following sections. 276 4.1. The repair node is a direct neighbor 278 When the repair node is a direct neighbor, the outgoing interface is 279 set to that neighbor and the repair segment list is empty. 281 This is comparable to a post-convergence LFA FRR repair. 283 4.2. The repair node is a PQ node 285 When the repair node is in P(S,X), the repair list is made of a 286 single node segment to the repair node. 288 This is comparable to a post-convergence RLFA repair tunnel. 290 4.3. The repair is a Q node, neighbor of the last P node 292 When the repair node is adjacent to P(S,X), the repair list is made 293 of two segments: A node segment to the adjacent P node, and an 294 adjacency segment from that node to the repair node. 296 This is comparable to a post-convergence DLFA repair tunnel. 298 4.4. Connecting distant P and Q nodes along post-convergence paths 300 In some cases, there is no adjacent P and Q node along the post- 301 convergence path. However, the PLR can perform additional 302 computations to compute a list of segments that represent a loopfree 303 path from P to Q. 305 5. Protecting segments 307 In this section, we explain how a protecting router S processes the 308 active segment of a packet upon the failure of its primary outgoing 309 interface for the packet, S-F. 311 The behavior depends on the type of active segment to be protected. 313 5.1. The active segment is a node segment 315 The active segment is kept on the SR header, unchanged (1). The 316 repair list is inserted at the head of the list. The active segment 317 becomes the first segment of the inserted repair list. 319 Note (1): If the SRGB at the repair node is different from the SRGB 320 at the PLR, then the active segment must be updated to fit the SRGB 321 of the repair node. 323 In section Section 5.3, we describe the node protection behavior of 324 PLR S, for the specific case where the active segment is a prefix 325 segment for the neighbour F itself. 327 5.2. The active segment is an adjacency segment 329 We define hereafter the FRR behavior applied by S for any packet 330 received with an active adjacency segment S-F for which protection 331 was enabled. We distinguish the case where this active segment is 332 followed by another adjacency segment from the case where it is 333 followed by a node segment. 335 5.2.1. Protecting [Adjacency, Adjacency] segment lists 337 If the next segment in the list is an Adjacency segment, then the 338 packet has to be conveyed to F. 340 To do so, S applies a "NEXT" operation on Adj(S-F) and then two 341 consecutive "PUSH" operations: first it pushes a node segment for F, 342 and then it pushes a protection list allowing to reach F while 343 bypassing S-F. 345 Upon failure of S-F, a packet reaching S with a segment list matching 346 [adj(S-F),adj(M),...] will thus leave S with a segment list matching 347 [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel for 348 destination F. 350 In section Section 5.3.2, we describe the TI-LFA behavior of PLR S 351 when node protection is applied and the two first segments are 352 Adjacency Segments. 354 5.2.2. Protecting [Adjacency, Node] segment lists 356 If the next segment in the stack is a node segment, say for node T, 357 the packet segment list matches [adj(S-F),node(T),...]. 359 A first solution would consist in steering the packet back to F while 360 avoiding S-F. To do so, S applies a "NEXT" operation on Adj(S-F) and 361 then two consecutive "PUSH" operations: first it pushes a node 362 segment for F, and then it pushes a repair list allowing to reach F 363 while bypassing S-F. 365 Upon failure of S-F, a packet reaching S with a segment list matching 366 [adj(S-F),node(T),...] will thus leave S with a segment list matching 368 [RT(F),node(F),node(T)]. 370 Another solution is to not steer the packet back via F but rather 371 follow the new shortest path to T. In this case, S just needs to 372 apply a "NEXT" operation on the Adjacency segment related to S-F, and 373 push a repair list redirecting the traffic to a node Q, whose path to 374 node segment T is not affected by the failure. 376 Upon failure of S-F, packets reaching S with a segment list matching 377 [adj(L), node(T), ...], would leave S with a segment list matching 378 [RT(Q),node(T), ...]. Note that this second behaviour is the one 379 followed for node protection, as described in section Section 5.3.1. 381 5.3. Protecting SR policy midpoints against node failure 383 As planned in the previous version of this document, we describe the 384 behaviour of a node S configured to interpret the failure of link 385 S->F as the node failure of F, in the specific case where the active 386 segment of the packet received by S is a Prefix SID of F (represented 387 as "F"), or an Adjacency SID for the link S-F (represented as 388 "S->F"). 390 5.3.1. Protecting {F, T, D} or {S->F, T, D} 392 We describe the protection behaviour of S when 394 1. the active segment is a prefix SID for a neighbour F, or an 395 adjacency segment S->F 396 2. the primary interface used to forward the packet failed 397 3. the segment following the active segment is a prefix SID (for 398 node T) 399 4. node protetion is active for that interface. 401 The TILFA Node FRR behavior becomes equivalent to: 403 1. Pop; the segment F or S->F is removed 404 2. Confirm that the next segment is in the SRGB of F, meaning that 405 the next segment is a prefix segment, e.g. for node T 406 3. Identify T (as per the SRGB of F) 407 4. Pop the next segment and push T's segment based on the local SRGB 408 5. forward the packet according to T. 410 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 412 We describe the protection behaviour of S when 413 1. the active segment is a prefix SID for a neighbour F, or an 414 adjacency segment S->F 415 2. the primary interface used to forward the packet failed 416 3. the segment following the active segment is an adjacency SID 417 (F->T) 418 4. node protetion is active for that interface. 420 The TILFA Node FRR behavior becomes equivalent to: 422 1. Pop; the segment F or S->F is removed 423 2. Confirm that the next segment is an adjacency SID of F, say F->T 424 3. Identify T (as per the set of Adjancey Segments of F) 425 4. Pop the next segment and push T's segment based on the local SRGB 426 5. forward the packet according to T. 428 6. References 430 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 431 Shakir, "Segment Routing Architecture", 432 draft-ietf-spring-segment-routing-08 (work in progress), 433 May 2016. 435 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, 436 January 2010. 438 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, J., 439 Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 440 Applicability in Service Provider (SP) Networks", RFC 6571, 441 June 2012. 443 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, 444 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, 445 DOI 10.17487/RFC7490, April 2015, 446 . 448 Authors' Addresses 450 Pierre Francois 451 Cisco Systems, Inc. 452 Vimercate 453 IT 455 Email: pifranco@cisco.com 456 Clarence Filsfils 457 Cisco Systems, Inc. 458 Brussels 459 BE 461 Email: cfilsfil@cisco.com 463 Ahmed Bashandy 464 Cisco Systems, Inc. 465 San Jose 466 US 468 Email: bashandy@cisco.com 470 Bruno Decraene 471 Orange 472 Issy-les-Moulineaux 473 FR 475 Email: bruno.decraene@orange.com 477 Stephane Litkowski 478 Orange 479 FR 481 Email: bruno.decraene@orange.com