idnits 2.17.1 draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet 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 (March 30, 2018) is 2217 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 415 -- Looks like a reference, but probably isn't: 'Node' on line 415 == Unused Reference: '3' is defined on line 776, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-08 == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-00 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- Duplicate reference: draft-ietf-spring-segment-routing, mentioned in '6', was also mentioned in '1'. Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy 2 Internet Draft C. Filsfils 3 Intended status: Standard Track Cisco Systems 4 Expires: September 2018 Bruno Decraene 5 Stephane Litkowski 6 Orange 7 Pierre Francois 8 Individual Contributor 9 D. Voyer 10 Bell Canada 11 March 30, 2018 13 Topology Independent Fast Reroute using Segment Routing 14 draft-bashandy-rtgwg-segment-routing-ti-lfa-04 16 Abstract 18 This document presents Topology Independent Loop-free Alternate Fast 19 Re-route (TI-LFA), aimed at providing protection of node and 20 adjacency segments within the Segment Routing (SR) framework. This 21 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 22 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 23 (DLFA). It extends these concepts to provide guaranteed coverage in 24 any IGP network. A key aspect of TI-LFA is the FRR path selection 25 approach establishing protection over post-convergence paths from 26 the point of local repair, dramatically reducing the operational 27 need to control the tie-breaks among various FRR options. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 This document may contain material from IETF Documents or IETF 35 Contributions published or made publicly available before November 36 10, 2008. The person(s) controlling the copyright in some of this 37 material may not have granted the IETF Trust the right to allow 38 modifications of such material outside the IETF Standards Process. 39 Without obtaining an adequate license from the person(s) controlling 40 the copyright in such materials, this document may not be modified 41 outside the IETF Standards Process, and derivative works of it may 42 not be created outside the IETF Standards Process, except to format 43 it for publication as an RFC or to translate it into languages other 44 than English. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six 52 months and may be updated, replaced, or obsoleted by other documents 53 at any time. It is inappropriate to use Internet-Drafts as 54 reference material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html 62 This Internet-Draft will expire on September 30, 2018. 64 Copyright Notice 66 Copyright (c) 2018 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with 74 respect to this document. Code Components extracted from this 75 document must include Simplified BSD License text as described in 76 Section 4.e of the Trust Legal Provisions and are provided without 77 warranty as described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction...................................................3 82 1.1. Conventions used in this document.........................5 83 2. Terminology....................................................5 84 3. Intersecting P-Space and Q-Space with post-convergence paths...6 85 3.1. P-Space property computation for a resource X.............6 86 3.2. Q-Space property computation for a link S-F, over post- 87 convergence paths..............................................6 88 3.3. Q-Space property computation for a set of links adjacent to 89 S, over post-convergence paths.................................7 90 3.4. Q-Space property computation for a node F, over post- 91 convergence paths..............................................7 92 4. TI-LFA Repair Tunnel...........................................7 93 4.1. The repair node is a direct neighbor......................7 94 4.2. The repair node is a PQ node..............................8 95 4.3. The repair is a Q node, neighbor of the last P node.......8 96 4.4. Connecting distant P and Q nodes along post-convergence 97 paths..........................................................8 98 5. Protecting segments............................................8 99 5.1. The active segment is a node segment......................8 100 5.2. The active segment is an adjacency segment................9 101 5.2.1. Protecting [Adjacency, Adjacency] segment lists......9 102 5.2.2. Protecting [Adjacency, Node] segment lists...........9 103 5.3. Protecting SR policy midpoints against node failure......10 104 5.3.1. Protecting {F, T, D} or {S->F, T, D}................10 105 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D}..........10 106 6. Measurements on Real Networks.................................11 107 7. Security Considerations.......................................16 108 8. IANA Considerations...........................................16 109 9. Conclusions...................................................16 110 10. References...................................................17 111 10.1. Normative References....................................17 112 10.2. Informative References..................................17 113 11. Acknowledgments..............................................17 115 1. Introduction 117 Segment Routing aims at supporting services with tight SLA 118 guarantees [1]. By relying on segment routing this document provides 119 a local repair mechanism for standard IGP shortest path capable of 120 restoring end-to-end connectivity in the case of a sudden directly 121 connected failure of a network component. Non-SR mechanisms for 122 local repair are beyond the scope of this document. Non-local 123 failures are addressed in a separate document [5]. 125 The term topology independent (Ti) refers to the ability to provide 126 a loop free backup path irrespective of the topologies prior the 127 failure and after the failure. 129 For each destination in the network, TI-LFA prepares a data-plane 130 switch-over to be activated upon detection of the failure of a link 131 used to reach the destination. TI-LFA provides protection in the 132 event of any one of the following: single link failure, single node 133 failure, or single local SRLG failure. In link failure mode, the 134 destination is protected assuming the failure of the link. In node 135 protection mode, the destination is protected assuming that the 136 neighbor connected to the primary link has failed. In local SRLG 137 protecting mode, the destination is protected assuming that a 138 configured set of links sharing fate with the primary link has 139 failed (e.g. a linecard). 141 Protection applies to traffic which traverses the Point of Local 142 Repair (PLR). Traffic which does NOT traverse the PLR remains 143 unaffected. 145 Using segment routing, there is no need to establish TLDP sessions 146 with remote nodes in order to take advantage of the applicability of 147 remote LFAs (RLFA) or remote LFAs with directed forwarding 148 (DLFA)[2]. As a result, preferring LFAs over RLFAs or DLFAs, as well 149 as minimizing the number of RLFA or DLFA repair nodes is not 150 required. This allows for a protection path selection approach 151 meeting operational needs rather than a topologically constrained 152 one. 154 Using SR, there is no need to create state in the network in order 155 to enforce an explicit FRR path. As a result, we can use optimized 156 detour paths for each specific destination and for each type of 157 failure without creating additional forwarding state. Also, the 158 mode of protection (link, node, SRLG) is not constrained to be 159 network wide or node wide, but can be managed on a per interface 160 basis. 162 Building on such an easier forwarding environment, the FRR behavior 163 suggested in this document tailors the repair paths over the post- 164 convergence path from the PLR to the protected destination, given 165 the enabled protection mode for the interface. 167 As the capacity of the post-convergence path is typically planned by 168 the operator to support the post-convergence routing of the traffic 169 for any expected failure, there is much less need for the operator 170 to tune the decision among which protection path to choose. The 171 protection path will automatically follow the natural backup path 172 that would be used after local convergence. This also helps to 173 reduce the amount of path changes and hence service transients: one 174 transition (pre-convergence to post-convergence) instead of two 175 (pre-convergence to FRR and then post-convergence). 177 L ____ 178 S----F--{____}----D 179 /\ | / 180 | | | _______ / 181 |__}---Q{_______} 183 Figure 1 TI-LFA Protection 185 We use Figure 1 to illustrate the TI-LFA approach. 187 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 188 node) that is capable of safely forwarding the traffic to a 189 destination D affected by the failure of the protected link L, a set 190 of adjacent links including L (local SRLG), or the node F itself. 191 The PLR also needs to find a way to reach Q without being affected 192 by the convergence state of the nodes over the paths it wants to use 193 to reach Q. 195 In Section 2 we define the main notations used in the document. 196 They are in line with [2]. 198 In Section 3, we suggest to compute the P-Space and Q-Space 199 properties defined in Section 2, for the specific case of nodes 200 lying over the post-convergence paths towards the protected 201 destinations. 203 Using the properties defined in Section 3, Section 4 describes 204 how to compute protection lists that encode a loopfree post- 205 convergence path towards the destination. 207 Section 5 defines the segment operations to be applied by the PLR 208 to ensure consistency with the forwarding state of the repair node. 210 By applying the algorithms specified in this document to actual 211 service providers and large enterprise networks, we provide real 212 life measurements for the number of SIDs used by repair paths. 213 Section 6 summarizes these measurements. 215 1.1. Conventions used in this document 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in RFC-2119 221 In this document, these words will appear with that interpretation 222 only when in ALL CAPS. Lower case uses of these words are not to be 223 interpreted as carrying RFC-2119 significance. 225 2. Terminology 227 We define the main notations used in this document as the following. 229 We refer to "old" and "new" topologies as the LSDB state before and 230 after the considered failure. 232 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 233 state of the network. 235 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the 236 state of the network after the resource X has failed. 238 Dist_old(A,B) is the shortest distance from node A to node B in 239 SPT_old(A). 241 Dist_new(A,B, X) is the shortest distance from node A to node B in 242 SPT_new(A,X). 244 PLR stands for "Point of Local Repair". It is the router that 245 applies fast traffic restoration after detecting failure in a 246 directly attached link, set of links, and/or node. 248 Similar to [4], we use the concept of P-Space and Q-Space for TI- 249 LFA. 251 The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, 252 a node F, or a local SRLG) is the set of nodes that are reachable 253 from R without passing through X. It is the set of nodes that are 254 not downstream of X in SPT_old(R). 256 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 257 set of nodes that are reachable from R or a neighbor of R, without 258 passing through X. 260 The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is 261 the set of nodes which do not use X to reach D in the initial state 262 of the network. In other words, it is the set of nodes which have D 263 in their P-Space w.r.t. S-F, F, or a set of links adjacent to S). 265 A symmetric network is a network such that the IGP metric of each 266 link is the same in both directions of the link. 268 3. Intersecting P-Space and Q-Space with post-convergence paths 270 In this section, we suggest to determine the P-Space and Q-Space 271 properties of the nodes along the post-convergence paths from the 272 PLR to the protected destination and compute an SR-based explicit 273 path from P to Q when they are not adjacent. Such properties will 274 be used in Section 4 to compute the TI-LFA repair list. 276 3.1. P-Space property computation for a resource X 278 A node N is in P(R, X) if it is not downstream of X in SPT_old(R). 279 X can be a link, a node, or a set of links adjacent to the PLR. A 280 node N is in P'(R,X) if it is not downstream of X in SPT_old(N), 281 for at least one neighbor N of R. 283 3.2. Q-Space property computation for a link S-F, over post- 284 convergence paths 286 We want to determine which nodes on the post-convergence path from 287 the PLR to the destination D are in the Q-Space of destination D 288 w.r.t. link S-F. 290 This can be found by intersecting the post-convergence path to D, 291 assuming the failure of S-F, with Q(D, S-F). 293 3.3. Q-Space property computation for a set of links adjacent to S, 294 over post-convergence paths 296 We want to determine which nodes on the post-convergence path from 297 the PLR to the destination D are in the Q-Space of destination D 298 w.r.t. a set of links adjacent to S (S being the PLR). That is, we 299 aim to find the set of nodes on the post-convergence path that use 300 none of the members of the protected set of links, to reach D. 302 This can be found by intersecting the post-convergence path to D, 303 assuming the failure of the set of links, with the intersection 304 among Q(D, S->X) for all S->X belonging to the set of links. 306 3.4. Q-Space property computation for a node F, over post-convergence 307 paths 309 We want to determine which nodes on the post-convergence from the 310 PLR to the destination D are in the Q-Space of destination D w.r.t. 311 node F. 313 This can be found by intersecting the post-convergence path to D, 314 assuming the failure of F, with Q(D, F). 316 4. TI-LFA Repair Tunnel 318 The TI-LFA repair tunnel consists of an outgoing interface and a 319 list of segments (repair list) to insert on the SR header. The 320 repair list encodes the explicit post-convergence path to the 321 destination, which avoids the protected resource X and, at the same 322 time, is guaranteed to be loop free irrespective of the state of 323 FIBs along the nodes belonging to the explicit path. 325 The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) 326 with the post-convergence path to D and computing the explicit SR- 327 based path EP(P, Q) from P to Q when these nodes are not adjacent 328 along the post convergence path. The TI-LFA repair list is 329 expressed generally as (Node_SID(P), EP(P, Q)). 331 Most often, the TI-LFA repair list has a simpler form, as described 332 in the following sections. Section 6 provides statistics for the 333 number of SIDs in the explicit path to protect against various 334 failures. 336 4.1. The repair node is a direct neighbor 338 When the repair node is a direct neighbor, the outgoing interface is 339 set to that neighbor and the repair segment list is empty. 341 This is comparable to a post-convergence LFA FRR repair. 343 4.2. The repair node is a PQ node 345 When the repair node is in P(S,X), the repair list is made of a 346 single node segment to the repair node. 348 This is comparable to a post-convergence RLFA repair tunnel. 350 4.3. The repair is a Q node, neighbor of the last P node 352 When the repair node is adjacent to P(S,X), the repair list is made 353 of two segments: A node segment to the adjacent P node, and an 354 adjacency segment from that node to the repair node. 356 This is comparable to a post-convergence DLFA repair tunnel. 358 4.4. Connecting distant P and Q nodes along post-convergence paths 360 In some cases, there is no adjacent P and Q node along the post- 361 convergence path. However, the PLR can perform additional 362 computations to compute a list of segments that represent a loopfree 363 path from P to Q. 365 5. Protecting segments 367 In this section, we explain how a protecting router S processes the 368 active segment of a packet upon the failure of its primary outgoing 369 interface for the packet, S-F. 371 The behavior depends on the type of active segment to be protected. 373 5.1. The active segment is a node segment 375 The active segment is kept on the SR header, unchanged (1). The 376 repair list is inserted at the head of the list. The active segment 377 becomes the first segment of the inserted repair list. 379 Note (1): If SR-MPLS is being used and the SRGB at the repair node 380 is different from the SRGB at the PLR, then the active segment must 381 be updated to fit the SRGB of the repair node. 383 In Section 5.3, we describe the node protection behavior of PLR S, 384 for the specific case where the active segment is a prefix segment 385 for the neighbor F itself. 387 5.2. The active segment is an adjacency segment 389 We define hereafter the FRR behavior applied by S for any packet 390 received with an active adjacency segment S-F for which protection 391 was enabled. We distinguish the case where this active segment is 392 followed by another adjacency segment from the case where it is 393 followed by a node segment. 395 5.2.1. Protecting [Adjacency, Adjacency] segment lists 397 If the next segment in the list is an Adjacency segment, then the 398 packet has to be conveyed to F. 400 To do so, S applies a "NEXT" operation on Adj(S-F) and then two 401 consecutive "PUSH" operations: first it pushes a node segment for F, 402 and then it pushes a protection list allowing to reach F while 403 bypassing S-F. For details on the "NEXT" and "PUSH" operations, 404 refer to [6]. 406 Upon failure of S-F, a packet reaching S with a segment list 407 matching [adj(S-F),adj(M),...] will thus leave S with a segment list 408 matching [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel 409 for destination F. 411 In Section 5.3.2, we describe the TI-LFA behavior of PLR S when 412 node protection is applied and the two first segments are Adjacency 413 Segments. 415 5.2.2. Protecting [Adjacency, Node] segment lists 417 If the next segment in the stack is a node segment, say for node T, 418 the packet segment list matches [adj(S-F),node(T),...]. 420 A first solution would consist in steering the packet back to F 421 while avoiding S-F. To do so, S applies a "NEXT" operation on 422 Adj(S-F) and then two consecutive "PUSH" operations: first it pushes 423 a node segment for F, and then it pushes a repair list allowing to 424 reach F while bypassing S-F. 426 Upon failure of S-F, a packet reaching S with a segment list 427 matching [adj(S-F),node(T),...] will thus leave S with a segment 428 list matching [RT(F),node(F),node(T)]. 430 Another solution is to not steer the packet back via F but rather 431 follow the new shortest path to T. In this case, S just needs to 432 apply a "NEXT" operation on the Adjacency segment related to S-F, 433 and push a repair list redirecting the traffic to a node Q, whose 434 path to node segment T is not affected by the failure. 436 Upon failure of S-F, packets reaching S with a segment list matching 437 [adj(L), node(T), ...], would leave S with a segment list matching 438 [RT(Q),node(T), ...]. Note that this second behavior is the one 439 followed for node protection, as described in Section 5.3.1. 441 5.3. Protecting SR policy midpoints against node failure 443 In this section, we describe the behavior of a node S configured to 444 interpret the failure of link S->F as the node failure of F, in the 445 specific case where the active segment of the packet received by S 446 is a Prefix SID of F represented as "F"), or an Adjacency SID for 447 the link S-F (represented as "S->F"). 449 5.3.1. Protecting {F, T, D} or {S->F, T, D} 451 We describe the protection behavior of S when 453 1. the active segment is a prefix SID for a neighbor F, or an 454 adjacency segment S->F 456 2. the primary interface used to forward the packet failed 458 3. the segment following the active segment is a prefix SID (for 459 node T) 461 4. node protection is active for that interface. 463 The TILFA Node FRR behavior becomes equivalent to: 465 1. Pop; the segment F or S->F is removed 467 2. Confirm that the next segment is in the SRGB of F, meaning that 468 the next segment is a prefix segment, e.g. for node T 470 3. Identify T (as per the SRGB of F) 472 4. Pop the next segment and push T's segment based on the local SRGB 474 5. forward the packet according to T. 476 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 478 We describe the protection behavior of S when 480 1. the active segment is a prefix SID for a neighbor F, or an 481 adjacency segment S->F 483 2. the primary interface used to forward the packet failed 484 3. the segment following the active segment is an adjacency SID (F- 485 >T) 487 4. node protection is active for that interface. 489 The TILFA Node FRR behavior becomes equivalent to: 491 1. Pop; the segment F or S->F is removed 493 2. Confirm that the next segment is an adjacency SID of F, say F->T 495 3. Identify T (as per the set of Adjacency Segments of F) 497 4. Pop the next segment and push T's segment based on the local SRGB 499 5. forward the packet according to T. 501 It is noteworthy to mention that node "S" in the procedures 502 described in Sections 5.3.1 and 5.3.2 can always determine whether 503 the segment after popping the top segment is an adjacency SID or a 504 prefix-SID of the next-hop "F" as follows: 506 1. In a link state environment, the node "S" knows the SRGB and the 507 adj-SIDs of the neighboring node "F" 509 2. If the new segment after popping the top segment is within the 510 SRGB or the adj-SIDs of "F", then node "S" is certain that the 511 failure of node "F" is a midpoint failure and hence node "S" 512 applies the procedures specified in Sections 5.3.1 or 5.3.2, 513 respectively. 515 3. Otherwise the failure is not a midpoint failure and hence the 516 node "S" may apply other protection techniques that are beyond 517 the scope of this document or simply drop the packet and wait for 518 normal protocol conversion. 520 6. Measurements on Real Networks 522 This section presents measurements performed on real service 523 provider and large enterprise networks. The objective of the 524 measurements is to assess the number of SIDs required in an explicit 525 path when the mechanism described in this document are used to 526 protect against the failure scenarios within the scope of this 527 document. 529 The measurements below indicate that for link and local SRLG 530 protection, a 1 SID repair path delivers more than 99% coverage. For 531 node protection a 2 SIDs repair path yields 99% coverage. 533 Table 1 below lists the characteristics of the networks used in our 534 measurements. The measurements are carried out as follows 536 o For each network, the algorithms described in this document are 537 applied to protect all prefixes against link, node, and local 538 SRLG failure 540 o For each prefix, the number of SIDs used by the repair path is 541 recored 543 o The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, 544 and 4A/B 546 The measurements listed in the tables indicate that for link and 547 local SRLG protection, 1 SID repair paths are sufficient to protect 548 more than 99% of the prefix in almost all cases. For node protection 549 2 SIDs repair paths yield 99% coverage. 551 +-------------+------------+------------+------------+------------+ 552 | Network | Nodes | Circuits |Node-to-Link| SRLG info? | 553 | | | | Ratio | | 554 +-------------+------------+------------+------------+------------+ 555 | T1 | 408 | 665 | 1 : 63 | Yes | 556 +-------------+------------+------------+------------+------------+ 557 | T2 | 587 | 1083 | 1 : 84 | No | 558 +-------------+------------+------------+------------+------------+ 559 | T3 | 93 | 401 | 4 : 31 | Yes | 560 +-------------+------------+------------+------------+------------+ 561 | T4 | 247 | 393 | 1 : 59 | Yes | 562 +-------------+------------+------------+------------+------------+ 563 | T5 | 34 | 96 | 2 : 82 | Yes | 564 +-------------+------------+------------+------------+------------+ 565 | T6 | 50 | 78 | 1 : 56 | No | 566 +-------------+------------+------------+------------+------------+ 567 | T7 | 82 | 293 | 3 : 57 | No | 568 +-------------+------------+------------+------------+------------+ 569 | T8 | 35 | 41 | 1 : 17 | Yes | 570 +-------------+------------+------------+------------+------------+ 571 | T9 | 177 | 1371 | 7 : 74 | Yes | 572 +-------------+------------+------------+------------+------------+ 573 Table 1: Data Set Definition 575 The rest of this section presents the measurements done on the 576 actual topologies. The convention that we use is as follows 578 o 0 SIDs: the calculated repair path starts with a directly 579 connected neighbor that is also a loop free alternate, in which 580 case there is no need to explicitly route the traffic using 581 additional SIDs. This scenario is described in Section 4.1. 583 o 1 SIDs: the repair node is a PQ node, in which case only 1 SID is 584 needed to guarantee loop-freeness. This scenario is covered in 585 Section 4.2. 587 o 2 or more SIDs: The repair path consists of 2 or more SIDs as 588 described in Sections 4.3 and 4.4. We do not cover the case for 589 2 SIDs (Section 4.3) separately because there was no 590 granularity in the result. Also we treat the node-SID+adj-SID and 591 node-SID + node-SID the same because they do not differ from the 592 data plane point of view. 594 Table 2A and 2B below summarize the measurements on the number of 595 SIDs needed for link protection 597 +-------------+------------+------------+------------+------------+ 598 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 599 +-------------+------------+------------+------------+------------+ 600 | T1 | 74.227% | 25.256% | 0.517% | 0.001% | 601 +-------------+------------+------------+------------+------------+ 602 | T2 | 81.097% | 18.738% | 0.165% | 0.0% | 603 +-------------+------------+------------+------------+------------+ 604 | T3 | 95.878% | 4.067% | 0.056% | 0.0% | 605 +-------------+------------+------------+------------+------------+ 606 | T4 | 62.547% | 35.666% | 1.788% | 0.0% | 607 +-------------+------------+------------+------------+------------+ 608 | T5 | 85.733% | 14.267% | 0.0% | 0.0% | 609 +-------------+------------+------------+------------+------------+ 610 | T6 | 81.252% | 18.714% | 0.033% | 0.0% | 611 +-------------+------------+------------+------------+------------+ 612 | T7 | 98,857% | 1.143% | 0.0% | 0.0% | 613 +-------------+------------+------------+------------+------------+ 614 | T8 | 94,118% | 5.882% | 0.0% | 0.0% | 615 +-------------+------------+------------+------------+------------+ 616 | T9 | 98.950% | 1.050% | 0.0% | 0.0% | 617 +-------------+------------+------------+------------+------------+ 618 Table 2A: Link protection (repair size distribution) 620 +-------------+------------+------------+------------+------------+ 621 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 622 +-------------+------------+------------+------------+------------+ 623 | T1 | 74.227% | 99.482% | 99.999% | 100.0% | 624 +-------------+------------+------------+------------+------------+ 625 | T2 | 81.097% | 99.835% | 100.0% | 100.0% | 626 +-------------+------------+------------+------------+------------+ 627 | T3 | 95.878% | 99.944% | 100.0% | 100.0% | 628 +-------------+------------+------------+------------+------------+ 629 | T4 | 62.547% | 98.212% | 100.0% | 100.0% | 630 +-------------+------------+------------+------------+------------+ 631 | T5 | 85.733% | 100.000% | 100.0% | 100.0% | 632 +-------------+------------+------------+------------+------------+ 633 | T6 | 81.252% | 99.967% | 100.0% | 100.0% | 634 +-------------+------------+------------+------------+------------+ 635 | T7 | 98,857% | 100.000% | 100.0% | 100.0% | 636 +-------------+------------+------------+------------+------------+ 637 | T8 | 94,118% | 100.000% | 100.0% | 100.0% | 638 +-------------+------------+------------+------------+------------+ 639 | T9 | 98,950% | 100.000% | 100.0% | 100.0% | 640 +-------------+------------+------------+------------+------------+ 641 Table 2B: Link protection repair size cumulative distribution 643 Table 3A and 3B summarize the measurements on the number of SIDs 644 needed for local SRLG protection. 646 +-------------+------------+------------+------------+------------+ 647 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 648 +-------------+------------+------------+------------+------------+ 649 | T1 | 74.177% | 25.306% | 0.517% | 0.001% | 650 +-------------+------------+------------+------------+------------+ 651 | T2 | No SRLG Information | 652 +-------------+------------+------------+------------+------------+ 653 | T3 | 93.650% | 6.301% | 0.049% | 0.0% | 654 +-------------+------------+------------+------------+------------+ 655 | T4 | 62,547% | 35.666% | 1.788% | 0.0% | 656 +-------------+------------+------------+------------+------------+ 657 | T5 | 83.139% | 16.861% | 0.0% | 0.0% | 658 +-------------+------------+------------+------------+------------+ 659 | T6 | No SRLG Information | 660 +-------------+---------------------------------------------------+ 661 | T7 | No SRLG Information | 662 +-------------+------------+------------+------------+------------+ 663 | T8 | 85.185% | 14.815% | 0.0% | 0.0% | 664 +-------------+------------+------------+------------+------------+ 665 | T9 | 98,940% | 1.060% | 0.0% | 0.0% | 666 +-------------+------------+------------+------------+------------+ 667 Table 3A: Local SRLG protection repair size distribution 669 +-------------+------------+------------+------------+------------+ 670 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 671 +-------------+------------+------------+------------+------------+ 672 | T1 | 74.177% | 99.482% | 99.999% | 100.001% | 673 +-------------+------------+------------+------------+------------+ 674 | T2 | No SRLG Information | 675 +-------------+------------+------------+------------+------------+ 676 | T3 | 93.650% | 99.951% | 100.000% | 0.0% | 677 +-------------+------------+------------+------------+------------+ 678 | T4 | 62,547% | 98.212% | 100.000% | 100.0% | 679 +-------------+------------+------------+------------+------------+ 680 | T5 | 83.139% | 100.000% | 100.0% | 100.0% | 681 +-------------+------------+------------+------------+------------+ 682 | T6 | No SRLG Information | 683 +-------------+---------------------------------------------------+ 684 | T7 | No SRLG Information | 685 +-------------+------------+------------+------------+------------+ 686 | T8 | 85.185% | 100,000% | 100.000% | 100.0% | 687 +-------------+------------+------------+------------+------------+ 688 | T9 | 98,940% | 100,000% | 100.000% | 100.0% | 689 +-------------+------------+------------+------------+------------+ 690 Table 3B: Local SRLG protection repair size Cumulative distribution 692 The remaining two tables summarize the measurements on the number of 693 SIDs needed for node protection. 695 +---------+----------+----------+----------+----------+----------+ 696 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 697 +---------+----------+----------+----------+----------+----------+ 698 | T1 | 49.771% | 47.902% | 2.156% | 0.148% | 0.023% | 699 +---------+----------+----------+----------+----------+----------+ 700 | T2 | 36,528% | 59.625% | 3.628% | 0.194% | 0.025% | 701 +---------+----------+----------+----------+----------+----------+ 702 | T3 | 73,287% | 25,574% | 1,128% | 0.010% | 0% | 703 +---------+----------+----------+----------+----------+----------+ 704 | T4 | 36.112% | 57.350% | 6.329% | 0.199% | 0.010% | 705 +---------+----------+----------+----------+----------+----------+ 706 | T5 | 73.185% | 26.815% | 0% | 0% | 0% | 707 +---------+----------+----------+----------+----------+----------+ 708 | T6 | 78.362% | 21.320% | 0.318% | 0% | 0% | 709 +---------+----------+----------+----------+----------+----------+ 710 | T7 | 66.106% | 32.813% | 1.082% | 0% | 0% | 711 +---------+----------+----------+----------+----------+----------+ 712 | T8 | 59.712% | 40.288% | 0% | 0% | 0% | 713 +---------+----------+----------+----------+----------+----------+ 714 | T9 | 98.950% | 1.050% | 0% | 0% | 0% | 715 +---------+----------+----------+----------+----------+----------+ 716 Table 4A: Node protection (repair size distribution) 718 +---------+----------+----------+----------+----------+----------+ 719 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 720 +---------+----------+----------+----------+----------+----------+ 721 | T1 | 49.771% | 97.673% | 99.829% | 99.977% | 100% | 722 +---------+----------+----------+----------+----------+----------+ 723 | T2 | 36,528% | 96.153% | 99.781% | 99.975% | 100% | 724 +---------+----------+----------+----------+----------+----------+ 725 | T3 | 73,287% | 98.862% | 99.990% |100.0% | 100% | 726 +---------+----------+----------+----------+----------+----------+ 727 | T4 | 36.112% | 93.461% | 99.791% | 99.990% | 100% | 728 +---------+----------+----------+----------+----------+----------+ 729 | T5 | 73.185% | 100.0% | 100.0% |100.0% | 100% | 730 +---------+----------+----------+----------+----------+----------+ 731 | T6 | 78.362% | 99.682% | 100.0% |100.0% | 100% | 732 +---------+----------+----------+----------+----------+----------+ 733 | T7 | 66.106% | 98,918% | 100.0% |100.0% | 100% | 734 +---------+----------+----------+----------+----------+----------+ 735 | T8 | 59.712% | 100.0% | 100.0% |100.0% | 100% | 736 +---------+----------+----------+----------+----------+----------+ 737 | T9 | 98.950% | 100.0% | 100.0% |100.0% | 100% | 738 +---------+----------+----------+----------+----------+----------+ 739 Table 4B: Node protection (repair size cumulative distribution) 741 7. Security Considerations 743 The techniques described in this document is internal 744 functionality to a router that result in the ability to guarantee 745 an upper bound on the time taken to restore traffic flow upon the 746 failure of a directly connected link or node. As these techniques 747 steer traffic to the post-convergence path as quickly as possible, 748 this serves to minimize the disruption associated with a local 749 failure which can be seen as a modest security enhancement. 751 8. IANA Considerations 753 No requirements for IANA 755 9. Conclusions 757 This document proposes a mechanism that is able to pre-calculate a 758 backup path for every primary path so as to be able to protect 759 against the failure of a directly connected link, node, or SRLG. 760 The mechanism is able to calculate the backup path irrespective of 761 the topology as long as the topology is sufficiently redundant. 763 10. References 765 10.1. Normative References 767 10.2. Informative References 769 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 770 Shakir, "Segment Routing Architecture", draft-ietf-spring- 771 segment-routing-08 (work in progress), May 2016. 773 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 774 5714, January 2010. 776 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, 777 J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 778 Applicability in Service Provider (SP) Networks", RFC 6571, 779 June 2012. 781 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, 782 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 783 7490, DOI 10.17487/RFC7490, April 2015, . 786 [5] Bashandy, A., Filsfils, C., and Litkowski, S., " Loop 787 avoidance using Segment Routing", draft-bashandy-rtgwg- 788 segment-routing-uloop-00, (work in progress), May 2017 790 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 791 Shakir, R, "Segment Routing Architecture", draft-ietf-spring- 792 segment-routing-11 (work in progress), February 2017 794 11. Acknowledgments 796 We would like to give Les Ginsberg special thanks for the valuable 797 comments and contribution 799 This document was prepared using 2-Word-v2.0.template.dot. 801 Authors' Addresses 803 Pierre Francois 804 pfrpfr@gmail.com 806 Ahmed Bashandy 807 Cisco Systems 808 170 West Tasman Dr, San Jose, CA 95134, USA 809 Email: abashandy.ietf@gmail.com 811 Clarence Filsfils 812 Cisco Systems 813 Brussels, Belgium 814 Email: cfilsfil@cisco.com 816 Bruno Decraene 817 Orange 818 Issy-les-Moulineaux 819 FR 820 Email: bruno.decraene@orange.com 822 Stephane Litkowski 823 Orange 824 FR 825 Email: stephane.litkowski@orange.com 827 Daniel Voyer 828 Bell Canada 829 Canada 830 Email: daniel.voyer@bell.ca