idnits 2.17.1 draft-ietf-rtgwg-segment-routing-ti-lfa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 383: '... the PLR, then the active segment MUST...' RFC 2119 keyword, line 414: '... Node(F) MUST be calculated accordin...' RFC 2119 keyword, line 436: '...ting the node(F) MUST be calculated ac...' RFC 2119 keyword, line 452: '...nding to Node(T) MUST be calculated ac...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 3, 2018) is 1971 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 421 -- Looks like a reference, but probably isn't: 'Node' on line 421 == Unused Reference: '3' is defined on line 799, 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 '7', was also mentioned in '1'. Summary: 1 error (**), 0 flaws (~~), 6 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 Arrcus 3 Intended status: Standard Track C. Filsfils 4 Expires: June 2019 Cisco Systems 5 Bruno Decraene 6 Stephane Litkowski 7 Orange 8 Pierre Francois 9 INSA Lyon 10 D. Voyer 11 Bell Canada 12 Francois Clad 13 Pablo Camarillo 14 Cisco Systems 15 December 3, 2018 17 Topology Independent Fast Reroute using Segment Routing 18 draft-ietf-rtgwg-segment-routing-ti-lfa-00 20 Abstract 22 This document presents Topology Independent Loop-free Alternate Fast 23 Re-route (TI-LFA), aimed at providing protection of node and 24 adjacency segments within the Segment Routing (SR) framework. This 25 Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being 26 LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding 27 (DLFA). It extends these concepts to provide guaranteed coverage in 28 any IGP network. A key aspect of TI-LFA is the FRR path selection 29 approach establishing protection over post-convergence paths from 30 the point of local repair, dramatically reducing the operational 31 need to control the tie-breaks among various FRR options. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 This document may contain material from IETF Documents or IETF 39 Contributions published or made publicly available before November 40 10, 2008. The person(s) controlling the copyright in some of this 41 material may not have granted the IETF Trust the right to allow 42 modifications of such material outside the IETF Standards Process. 43 Without obtaining an adequate license from the person(s) controlling 44 the copyright in such materials, this document may not be modified 45 outside the IETF Standards Process, and derivative works of it may 46 not be created outside the IETF Standards Process, except to format 47 it for publication as an RFC or to translate it into languages other 48 than English. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six 56 months and may be updated, replaced, or obsoleted by other documents 57 at any time. It is inappropriate to use Internet-Drafts as 58 reference material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html 66 This Internet-Draft will expire on June 3, 2019. 68 Copyright Notice 70 Copyright (c) 2018 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with 78 respect to this document. Code Components extracted from this 79 document must include Simplified BSD License text as described in 80 Section 4.e of the Trust Legal Provisions and are provided without 81 warranty as described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction...................................................3 86 1.1. Conventions used in this document.........................5 87 2. Terminology....................................................5 88 3. Intersecting P-Space and Q-Space with post-convergence paths...6 89 3.1. P-Space property computation for a resource X.............6 90 3.2. Q-Space property computation for a link S-F, over post- 91 convergence paths..............................................6 92 3.3. Q-Space property computation for a set of links adjacent to 93 S, over post-convergence paths.................................7 94 3.4. Q-Space property computation for a node F, over post- 95 convergence paths..............................................7 96 4. TI-LFA Repair Tunnel...........................................7 97 4.1. The repair node is a direct neighbor......................7 98 4.2. The repair node is a PQ node..............................8 99 4.3. The repair is a Q node, neighbor of the last P node.......8 100 4.4. Connecting distant P and Q nodes along post-convergence 101 paths..........................................................8 102 5. Protecting segments............................................8 103 5.1. The active segment is a node segment......................8 104 5.2. The active segment is an adjacency segment................9 105 5.2.1. Protecting [Adjacency, Adjacency] segment lists......9 106 5.2.2. Protecting [Adjacency, Node] segment lists...........9 107 5.3. Protecting SR policy midpoints against node failure......10 108 5.3.1. Protecting {F, T, D} or {S->F, T, D}................10 109 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D}..........11 110 6. Measurements on Real Networks.................................12 111 7. Security Considerations.......................................17 112 8. IANA Considerations...........................................17 113 9. Conclusions...................................................17 114 10. References...................................................17 115 10.1. Normative References....................................17 116 10.2. Informative References..................................17 117 11. Acknowledgments..............................................18 119 1. Introduction 121 Segment Routing aims at supporting services with tight SLA 122 guarantees [1]. By relying on segment routing this document provides 123 a local repair mechanism for standard IGP shortest path capable of 124 restoring end-to-end connectivity in the case of a sudden directly 125 connected failure of a network component. Non-SR mechanisms for 126 local repair are beyond the scope of this document. Non-local 127 failures are addressed in a separate document [6]. 129 The term topology independent (Ti) refers to the ability to provide 130 a loop free backup path irrespective of the topologies prior the 131 failure and after the failure. 133 For each destination in the network, TI-LFA prepares a data-plane 134 switch-over to be activated upon detection of the failure of a link 135 used to reach the destination. TI-LFA provides protection in the 136 event of any one of the following: single link failure, single node 137 failure, or single local SRLG failure. In link failure mode, the 138 destination is protected assuming the failure of the link. In node 139 protection mode, the destination is protected assuming that the 140 neighbor connected to the primary link has failed. In local SRLG 141 protecting mode, the destination is protected assuming that a 142 configured set of links sharing fate with the primary link has 143 failed (e.g. a linecard). 145 Protection techniques outlined in this document are limited to 146 protecting links, nodes, and local SRLGs that are within a routing 147 domain. Protecting domain exit routers and/or links attached to 148 another routing domains are beyond the scope of this document 150 Using segment routing, there is no need to establish TLDP sessions 151 with remote nodes in order to take advantage of the applicability of 152 remote LFAs (RLFA) [4][5] or remote LFAs with directed forwarding 153 (DLFA)[2]. As a result, preferring LFAs over RLFAs or DLFAs, as well 154 as minimizing the number of RLFA or DLFA repair nodes is not 155 required 157 Using SR, there is no need to create state in the network in order 158 to enforce an explicit FRR path thereby relieving the nodes from the 159 extra state and the operator from having to deploy an extra protocol 160 just to enhance FRR coverage. 162 The FRR behavior suggested in this document tailors the repair paths 163 over the post-convergence path from the PLR to the protected 164 destination, given the enabled protection mode for the interface. 165 Using the post-convergence path in TI-LFA resolves some of 166 operational issues with LFA selection that are mentioned in Section 167 3 of [5] (e.g. using PE routers to protect against core failures, or 168 selecting links with low BW while links with high BW are available), 169 because these issues presumably have been taken care of by the 170 network operator as part of its original network engineering. Hence 171 traffic that permanently uses the PLR after the failure achieves 172 maximum benefits. Traffic that does not use the PLR prior to and 173 after the failure remains unaffected. Traffic that temporarily 174 continues to use the PLR after the failure benefits from the quick 175 switching to the backup path by minimizing traffic loss until remote 176 node(s) reacts. 178 L ____ 179 S----F--{____}----D 180 /\ | / 181 | | | _______ / 182 |__}---Q{_______} 184 Figure 1 TI-LFA Protection 186 We use Figure 1 to illustrate the TI-LFA approach. 188 The Point of Local Repair (PLR), S, needs to find a node Q (a repair 189 node) that is capable of safely forwarding the traffic to a 190 destination D affected by the failure of the protected link L, a set 191 of adjacent links including L (local SRLG), or the node F itself. 192 The PLR also needs to find a way to reach Q without being affected 193 by the convergence state of the nodes over the paths it wants to use 194 to reach Q. 196 In Section 2 we define the main notations used in the document. 197 They are in line with [2]. 199 In Section 3, we suggest to compute the P-Space and Q-Space 200 properties defined in Section 2, for the specific case of nodes 201 lying over the post-convergence paths towards the protected 202 destinations. 204 Using the properties defined in Section 3, Section 4 describes 205 how to compute protection lists that encode a loopfree post- 206 convergence path towards the destination. 208 Section 5 defines the segment operations to be applied by the PLR 209 to ensure consistency with the forwarding state of the repair node. 211 By applying the algorithms specified in this document to actual 212 service providers and large enterprise networks, we provide real 213 life measurements for the number of SIDs used by repair paths. 214 Section 6 summarizes these measurements. 216 1.1. Conventions used in this document 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC-2119 222 In this document, these words will appear with that interpretation 223 only when in ALL CAPS. Lower case uses of these words are not to be 224 interpreted as carrying RFC-2119 significance. 226 2. Terminology 228 We define the main notations used in this document as the following. 230 We refer to "old" and "new" topologies as the LSDB state before and 231 after the considered failure. 233 SPT_old(R) is the Shortest Path Tree rooted at node R in the initial 234 state of the network. 236 SPT_new(R, X) is the Shortest Path Tree rooted at node R in the 237 state of the network after the resource X has failed. 239 Dist_old(A,B) is the shortest distance from node A to node B in 240 SPT_old(A). 242 Dist_new(A,B, X) is the shortest distance from node A to node B in 243 SPT_new(A,X). 245 PLR stands for "Point of Local Repair". It is the router that 246 applies fast traffic restoration after detecting failure in a 247 directly attached link, set of links, and/or node. 249 Similar to [4], we use the concept of P-Space and Q-Space for TI- 250 LFA. 252 The P-Space P(R,X) of a node R w.r.t. a resource X (e.g. a link S-F, 253 a node F, or a local SRLG) is the set of nodes that are reachable 254 from R without passing through X. It is the set of nodes that are 255 not downstream of X in SPT_old(R). 257 The Extended P-Space P'(R,X) of a node R w.r.t. a resource X is the 258 set of nodes that are reachable from R or a neighbor of R, without 259 passing through X. 261 The Q-Space Q(D,X) of a destination node D w.r.t. a resource X is 262 the set of nodes which do not use X to reach D in the initial state 263 of the network. In other words, it is the set of nodes which have D 264 in their P-Space w.r.t. S-F, F, or a set of links adjacent to S). 266 A symmetric network is a network such that the IGP metric of each 267 link is the same in both directions of the link. 269 3. Intersecting P-Space and Q-Space with post-convergence paths 271 In this section, we suggest to determine the P-Space and Q-Space 272 properties of the nodes along the post-convergence paths from the 273 PLR to the protected destination and compute an SR-based explicit 274 path from P to Q when they are not adjacent. Such properties will 275 be used in Section 4 to compute the TI-LFA repair list. 277 3.1. P-Space property computation for a resource X 279 A node N is in P(R, X) if it is not downstream of X in SPT_old(R). 280 X can be a link, a node, or a set of links adjacent to the PLR. A 281 node N is in P'(R,X) if it is not downstream of X in SPT_old(N), 282 for at least one neighbor N of R. 284 3.2. Q-Space property computation for a link S-F, over post- 285 convergence paths 287 We want to determine which nodes on the post-convergence path from 288 the PLR to the destination D are in the Q-Space of destination D 289 w.r.t. link S-F. 291 This can be found by intersecting the post-convergence path to D, 292 assuming the failure of S-F, with Q(D, S-F). 294 3.3. Q-Space property computation for a set of links adjacent to S, 295 over post-convergence paths 297 We want to determine which nodes on the post-convergence path from 298 the PLR to the destination D are in the Q-Space of destination D 299 w.r.t. a set of links adjacent to S (S being the PLR). That is, we 300 aim to find the set of nodes on the post-convergence path that use 301 none of the members of the protected set of links, to reach D. 303 This can be found by intersecting the post-convergence path to D, 304 assuming the failure of the set of links, with the intersection 305 among Q(D, S->X) for all S->X belonging to the set of links. 307 3.4. Q-Space property computation for a node F, over post-convergence 308 paths 310 We want to determine which nodes on the post-convergence from the 311 PLR to the destination D are in the Q-Space of destination D w.r.t. 312 node F. 314 This can be found by intersecting the post-convergence path to D, 315 assuming the failure of F, with Q(D, F). 317 4. TI-LFA Repair Tunnel 319 The TI-LFA repair tunnel consists of an outgoing interface and a 320 list of segments (repair list) to insert on the SR header. The 321 repair list encodes the explicit post-convergence path to the 322 destination, which avoids the protected resource X and, at the same 323 time, is guaranteed to be loop free irrespective of the state of 324 FIBs along the nodes belonging to the explicit path. Thus there is 325 no need for any co-ordination or message exchange between the PLR 326 and any other router in the network. 328 The TI-LFA repair tunnel is found by intersecting P(S,X) and Q(D,X) 329 with the post-convergence path to D and computing the explicit SR- 330 based path EP(P, Q) from P to Q when these nodes are not adjacent 331 along the post convergence path. The TI-LFA repair list is 332 expressed generally as (Node_SID(P), EP(P, Q)). 334 Most often, the TI-LFA repair list has a simpler form, as described 335 in the following sections. Section 6 provides statistics for the 336 number of SIDs in the explicit path to protect against various 337 failures. 339 4.1. The repair node is a direct neighbor 341 When the repair node is a direct neighbor, the outgoing interface is 342 set to that neighbor and the repair segment list is empty. 344 This is comparable to a post-convergence LFA FRR repair. 346 4.2. The repair node is a PQ node 348 When the repair node is in P(S,X), the repair list is made of a 349 single node segment to the repair node. 351 This is comparable to a post-convergence RLFA repair tunnel. 353 4.3. The repair is a Q node, neighbor of the last P node 355 When the repair node is adjacent to P(S,X), the repair list is made 356 of two segments: A node segment to the adjacent P node, and an 357 adjacency segment from that node to the repair node. 359 This is comparable to a post-convergence DLFA repair tunnel. 361 4.4. Connecting distant P and Q nodes along post-convergence paths 363 In some cases, there is no adjacent P and Q node along the post- 364 convergence path. However, the PLR can perform additional 365 computations to compute a list of segments that represent a loopfree 366 path from P to Q. 368 5. Protecting segments 370 In this section, we explain how a protecting router S processes the 371 active segment of a packet upon the failure of its primary outgoing 372 interface for the packet, S-F. 374 The behavior depends on the type of active segment to be protected. 376 5.1. The active segment is a node segment 378 The active segment is kept on the SR header, unchanged (1). The 379 repair list is inserted at the head of the list. The active segment 380 becomes the first segment of the inserted repair list. 382 Note (1): If SR-MPLS is being used and the SRGB at the repair node 383 is different from the SRGB at the PLR, then the active segment MUST 384 be updated to fit the SRGB of the repair node. 386 In Section 5.3, we describe the node protection behavior of PLR S, 387 for the specific case where the active segment is a prefix segment 388 for the neighbor F itself. 390 5.2. The active segment is an adjacency segment 392 We define hereafter the FRR behavior applied by S for any packet 393 received with an active adjacency segment S-F for which protection 394 was enabled. We distinguish the case where this active segment is 395 followed by another adjacency segment from the case where it is 396 followed by a node segment. 398 5.2.1. Protecting [Adjacency, Adjacency] segment lists 400 If the next segment in the list is an Adjacency segment, then the 401 packet has to be conveyed to F. 403 To do so, S applies a "NEXT" operation on Adj(S-F) and then two 404 consecutive "PUSH" operations: first it pushes a node segment for F, 405 and then it pushes a protection list allowing to reach F while 406 bypassing S-F. For details on the "NEXT" and "PUSH" operations, 407 refer to [7]. 409 Upon failure of S-F, a packet reaching S with a segment list 410 matching [adj(S-F),adj(M),...] will thus leave S with a segment list 411 matching [RT(F),node(F),adj(M)], where RT(F) is the repair tunnel 412 for destination F. If MPLS forwarding plane is used, then Note(1) 413 from Section 5.1 applies here. Hence MPLS label representing 414 Node(F) MUST be calculated according to the exit point of the repair 415 tunnel "RT(F)" 417 In Section 5.3.2, we describe the TI-LFA behavior of PLR S when 418 node protection is applied and the two first segments are Adjacency 419 Segments. 421 5.2.2. Protecting [Adjacency, Node] segment lists 423 If the next segment in the stack is a node segment, say for node T, 424 the segment list on the packet matches [adj(S-F),node(T),...]. 426 A first solution would consist in steering the packet back to F 427 while avoiding S-F. To do so, S applies a "NEXT" operation on 428 Adj(S-F) and then two consecutive "PUSH" operations: first it pushes 429 a node segment for F, and then it pushes a repair list allowing to 430 reach F while bypassing S-F. 432 Upon failure of S-F, a packet reaching S with a segment list 433 matching [adj(S-F),node(T),...] will thus leave S with a segment 434 list matching [RT(F),node(F),node(T)]. Again if MPLS forwarding 435 plane is used, then Note(1) from Section 5.1 applies and the label 436 representing the node(F) MUST be calculated according to the SRGB of 437 the last node in the repair tunnel RT(F). 439 Another solution is to not steer the packet back via F but rather 440 follow the new shortest path to T. In this case, S just needs to 441 apply a "NEXT" operation on the Adjacency segment related to S-F, 442 and push a repair list redirecting the traffic to a node Q, whose 443 path to node segment T is not affected by the failure. 445 Upon failure of S-F, packets reaching S with a segment list matching 446 [adj(L), node(T), ...], would leave S with a segment list matching 447 [RT(Q),node(T), ...]. Note that this second behavior is the one 448 followed for node protection, as described in Section 5.3.1. 450 Just like the first solution above, if MPLS forwarding plane is 451 used, then Note(1) from Section 5.1 applies. Hence the label 452 corresponding to Node(T) MUST be calculated according to the SRGB of 453 node Q. 455 5.3. Protecting SR policy midpoints against node failure 457 In this section, we describe the behavior of a node S configured to 458 interpret the failure of link S->F as the node failure of F, in the 459 specific case where the active segment of the packet received by S 460 is a Prefix SID of F represented as "F"), or an Adjacency SID for 461 the link S-F (represented as "S->F"). 463 5.3.1. Protecting {F, T, D} or {S->F, T, D} 465 This section describes the protection behavior of S when all of the 466 following conditions are true: 468 1. the active segment is a prefix SID for a neighbor F, or an 469 adjacency segment S->F 471 2. the primary interface used to forward the packet failed 473 3. the segment following the active segment is a prefix SID (for 474 node T) 476 4. node protection is active for that interface. 478 The TILFA Node FRR behavior becomes equivalent to: 480 1. Pop; the segment F or S->F is removed 482 2. Confirm that the next segment is in the SRGB of F, meaning that 483 the next segment is a prefix segment, e.g. for node T 485 3. Identify T (as per the SRGB of F) 487 4. Pop the next segment and push T's segment based on the SRGB of 488 node "S". 490 5. forward the packet according to T. 492 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 494 This section describes the protection behavior of S when all of the 495 following conditions are true: 497 1. the active segment is a prefix SID for a neighbor F, or an 498 adjacency segment S->F 500 2. the primary interface used to forward the packet failed 502 3. the segment following the active segment is an adjacency SID (F- 503 >T) 505 4. node protection is active for that interface. 507 The TILFA Node FRR behavior becomes equivalent to: 509 1. Pop; the segment F or S->F is removed 511 2. Confirm that the next segment is an adjacency SID of F, say F->T 513 3. Identify T (as per the set of Adjacency Segments of F) 515 4. Pop the next segment and push T's segment based on the SRGB of 516 the node "S" 518 5. forward the packet according to T. 520 It is noteworthy to mention that node "S" in the procedures 521 described in Sections 5.3.1 and 5.3.2 can always determine whether 522 the segment after popping the top segment is an adjacency SID or a 523 prefix-SID of the next-hop "F" as follows: 525 1. In a link state environment, the node "S" knows the SRGB and the 526 adj-SIDs of the neighboring node "F" 528 2. If the new segment after popping the top segment is within the 529 SRGB or the adj-SIDs of "F", then node "S" is certain that the 530 failure of node "F" is a midpoint failure and hence node "S" 531 applies the procedures specified in Sections 5.3.1 or 5.3.2, 532 respectively. 534 3. Otherwise the failure is not a midpoint failure and hence the 535 node "S" may apply other protection techniques that are beyond 536 the scope of this document or simply drop the packet and wait for 537 normal protocol conversion. 539 6. Measurements on Real Networks 541 This section presents measurements performed on real service 542 provider and large enterprise networks. The objective of the 543 measurements is to assess the number of SIDs required in an explicit 544 path when the mechanism described in this document are used to 545 protect against the failure scenarios within the scope of this 546 document. The number of segments described in this section are 547 applicable to instantiating segment routing over the MPLS forwarding 548 plane. 550 The measurements below indicate that for link and local SRLG 551 protection, a 1 SID repair path delivers more than 99% coverage. For 552 node protection a 2 SIDs repair path yields 99% coverage. 554 Table 1 below lists the characteristics of the networks used in our 555 measurements. The measurements are carried out as follows 557 o For each network, the algorithms described in this document are 558 applied to protect all prefixes against link, node, and local 559 SRLG failure 561 o For each prefix, the number of SIDs used by the repair path is 562 recored 564 o The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, 565 and 4A/B 567 The measurements listed in the tables indicate that for link and 568 local SRLG protection, 1 SID repair paths are sufficient to protect 569 more than 99% of the prefix in almost all cases. For node protection 570 2 SIDs repair paths yield 99% coverage. 572 +-------------+------------+------------+------------+------------+ 573 | Network | Nodes | Circuits |Node-to-Link| SRLG info? | 574 | | | | Ratio | | 575 +-------------+------------+------------+------------+------------+ 576 | T1 | 408 | 665 | 1 : 63 | Yes | 577 +-------------+------------+------------+------------+------------+ 578 | T2 | 587 | 1083 | 1 : 84 | No | 579 +-------------+------------+------------+------------+------------+ 580 | T3 | 93 | 401 | 4 : 31 | Yes | 581 +-------------+------------+------------+------------+------------+ 582 | T4 | 247 | 393 | 1 : 59 | Yes | 583 +-------------+------------+------------+------------+------------+ 584 | T5 | 34 | 96 | 2 : 82 | Yes | 585 +-------------+------------+------------+------------+------------+ 586 | T6 | 50 | 78 | 1 : 56 | No | 587 +-------------+------------+------------+------------+------------+ 588 | T7 | 82 | 293 | 3 : 57 | No | 589 +-------------+------------+------------+------------+------------+ 590 | T8 | 35 | 41 | 1 : 17 | Yes | 591 +-------------+------------+------------+------------+------------+ 592 | T9 | 177 | 1371 | 7 : 74 | Yes | 593 +-------------+------------+------------+------------+------------+ 594 Table 1: Data Set Definition 596 The rest of this section presents the measurements done on the 597 actual topologies. The convention that we use is as follows 599 o 0 SIDs: the calculated repair path starts with a directly 600 connected neighbor that is also a loop free alternate, in which 601 case there is no need to explicitly route the traffic using 602 additional SIDs. This scenario is described in Section 4.1. 604 o 1 SIDs: the repair node is a PQ node, in which case only 1 SID is 605 needed to guarantee loop-freeness. This scenario is covered in 606 Section 4.2. 608 o 2 or more SIDs: The repair path consists of 2 or more SIDs as 609 described in Sections 4.3 and 4.4. We do not cover the case for 610 2 SIDs (Section 4.3) separately because there was no 611 granularity in the result. Also we treat the node-SID+adj-SID and 612 node-SID + node-SID the same because they do not differ from the 613 data plane point of view. 615 Table 2A and 2B below summarize the measurements on the number of 616 SIDs needed for link protection 617 +-------------+------------+------------+------------+------------+ 618 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 619 +-------------+------------+------------+------------+------------+ 620 | T1 | 74.227% | 25.256% | 0.517% | 0.001% | 621 +-------------+------------+------------+------------+------------+ 622 | T2 | 81.097% | 18.738% | 0.165% | 0.0% | 623 +-------------+------------+------------+------------+------------+ 624 | T3 | 95.878% | 4.067% | 0.056% | 0.0% | 625 +-------------+------------+------------+------------+------------+ 626 | T4 | 62.547% | 35.666% | 1.788% | 0.0% | 627 +-------------+------------+------------+------------+------------+ 628 | T5 | 85.733% | 14.267% | 0.0% | 0.0% | 629 +-------------+------------+------------+------------+------------+ 630 | T6 | 81.252% | 18.714% | 0.033% | 0.0% | 631 +-------------+------------+------------+------------+------------+ 632 | T7 | 98,857% | 1.143% | 0.0% | 0.0% | 633 +-------------+------------+------------+------------+------------+ 634 | T8 | 94,118% | 5.882% | 0.0% | 0.0% | 635 +-------------+------------+------------+------------+------------+ 636 | T9 | 98.950% | 1.050% | 0.0% | 0.0% | 637 +-------------+------------+------------+------------+------------+ 638 Table 2A: Link protection (repair size distribution) 640 +-------------+------------+------------+------------+------------+ 641 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 642 +-------------+------------+------------+------------+------------+ 643 | T1 | 74.227% | 99.482% | 99.999% | 100.0% | 644 +-------------+------------+------------+------------+------------+ 645 | T2 | 81.097% | 99.835% | 100.0% | 100.0% | 646 +-------------+------------+------------+------------+------------+ 647 | T3 | 95.878% | 99.944% | 100.0% | 100.0% | 648 +-------------+------------+------------+------------+------------+ 649 | T4 | 62.547% | 98.212% | 100.0% | 100.0% | 650 +-------------+------------+------------+------------+------------+ 651 | T5 | 85.733% | 100.000% | 100.0% | 100.0% | 652 +-------------+------------+------------+------------+------------+ 653 | T6 | 81.252% | 99.967% | 100.0% | 100.0% | 654 +-------------+------------+------------+------------+------------+ 655 | T7 | 98,857% | 100.000% | 100.0% | 100.0% | 656 +-------------+------------+------------+------------+------------+ 657 | T8 | 94,118% | 100.000% | 100.0% | 100.0% | 658 +-------------+------------+------------+------------+------------+ 659 | T9 | 98,950% | 100.000% | 100.0% | 100.0% | 660 +-------------+------------+------------+------------+------------+ 661 Table 2B: Link protection repair size cumulative distribution 663 Table 3A and 3B summarize the measurements on the number of SIDs 664 needed for local SRLG protection. 666 +-------------+------------+------------+------------+------------+ 667 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 668 +-------------+------------+------------+------------+------------+ 669 | T1 | 74.177% | 25.306% | 0.517% | 0.001% | 670 +-------------+------------+------------+------------+------------+ 671 | T2 | No SRLG Information | 672 +-------------+------------+------------+------------+------------+ 673 | T3 | 93.650% | 6.301% | 0.049% | 0.0% | 674 +-------------+------------+------------+------------+------------+ 675 | T4 | 62,547% | 35.666% | 1.788% | 0.0% | 676 +-------------+------------+------------+------------+------------+ 677 | T5 | 83.139% | 16.861% | 0.0% | 0.0% | 678 +-------------+------------+------------+------------+------------+ 679 | T6 | No SRLG Information | 680 +-------------+---------------------------------------------------+ 681 | T7 | No SRLG Information | 682 +-------------+------------+------------+------------+------------+ 683 | T8 | 85.185% | 14.815% | 0.0% | 0.0% | 684 +-------------+------------+------------+------------+------------+ 685 | T9 | 98,940% | 1.060% | 0.0% | 0.0% | 686 +-------------+------------+------------+------------+------------+ 687 Table 3A: Local SRLG protection repair size distribution 689 +-------------+------------+------------+------------+------------+ 690 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 691 +-------------+------------+------------+------------+------------+ 692 | T1 | 74.177% | 99.482% | 99.999% | 100.001% | 693 +-------------+------------+------------+------------+------------+ 694 | T2 | No SRLG Information | 695 +-------------+------------+------------+------------+------------+ 696 | T3 | 93.650% | 99.951% | 100.000% | 0.0% | 697 +-------------+------------+------------+------------+------------+ 698 | T4 | 62,547% | 98.212% | 100.000% | 100.0% | 699 +-------------+------------+------------+------------+------------+ 700 | T5 | 83.139% | 100.000% | 100.0% | 100.0% | 701 +-------------+------------+------------+------------+------------+ 702 | T6 | No SRLG Information | 703 +-------------+---------------------------------------------------+ 704 | T7 | No SRLG Information | 705 +-------------+------------+------------+------------+------------+ 706 | T8 | 85.185% | 100,000% | 100.000% | 100.0% | 707 +-------------+------------+------------+------------+------------+ 708 | T9 | 98,940% | 100,000% | 100.000% | 100.0% | 709 +-------------+------------+------------+------------+------------+ 710 Table 3B: Local SRLG protection repair size Cumulative distribution 712 The remaining two tables summarize the measurements on the number of 713 SIDs needed for node protection. 715 +---------+----------+----------+----------+----------+----------+ 716 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 717 +---------+----------+----------+----------+----------+----------+ 718 | T1 | 49.771% | 47.902% | 2.156% | 0.148% | 0.023% | 719 +---------+----------+----------+----------+----------+----------+ 720 | T2 | 36,528% | 59.625% | 3.628% | 0.194% | 0.025% | 721 +---------+----------+----------+----------+----------+----------+ 722 | T3 | 73,287% | 25,574% | 1,128% | 0.010% | 0% | 723 +---------+----------+----------+----------+----------+----------+ 724 | T4 | 36.112% | 57.350% | 6.329% | 0.199% | 0.010% | 725 +---------+----------+----------+----------+----------+----------+ 726 | T5 | 73.185% | 26.815% | 0% | 0% | 0% | 727 +---------+----------+----------+----------+----------+----------+ 728 | T6 | 78.362% | 21.320% | 0.318% | 0% | 0% | 729 +---------+----------+----------+----------+----------+----------+ 730 | T7 | 66.106% | 32.813% | 1.082% | 0% | 0% | 731 +---------+----------+----------+----------+----------+----------+ 732 | T8 | 59.712% | 40.288% | 0% | 0% | 0% | 733 +---------+----------+----------+----------+----------+----------+ 734 | T9 | 98.950% | 1.050% | 0% | 0% | 0% | 735 +---------+----------+----------+----------+----------+----------+ 736 Table 4A: Node protection (repair size distribution) 738 +---------+----------+----------+----------+----------+----------+ 739 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 740 +---------+----------+----------+----------+----------+----------+ 741 | T1 | 49.771% | 97.673% | 99.829% | 99.977% | 100% | 742 +---------+----------+----------+----------+----------+----------+ 743 | T2 | 36,528% | 96.153% | 99.781% | 99.975% | 100% | 744 +---------+----------+----------+----------+----------+----------+ 745 | T3 | 73,287% | 98.862% | 99.990% |100.0% | 100% | 746 +---------+----------+----------+----------+----------+----------+ 747 | T4 | 36.112% | 93.461% | 99.791% | 99.990% | 100% | 748 +---------+----------+----------+----------+----------+----------+ 749 | T5 | 73.185% | 100.0% | 100.0% |100.0% | 100% | 750 +---------+----------+----------+----------+----------+----------+ 751 | T6 | 78.362% | 99.682% | 100.0% |100.0% | 100% | 752 +---------+----------+----------+----------+----------+----------+ 753 | T7 | 66.106% | 98,918% | 100.0% |100.0% | 100% | 754 +---------+----------+----------+----------+----------+----------+ 755 | T8 | 59.712% | 100.0% | 100.0% |100.0% | 100% | 756 +---------+----------+----------+----------+----------+----------+ 757 | T9 | 98.950% | 100.0% | 100.0% |100.0% | 100% | 758 +---------+----------+----------+----------+----------+----------+ 759 Table 4B: Node protection (repair size cumulative distribution) 761 7. Security Considerations 763 The techniques described in this document is internal 764 functionality to a router that result in the ability to guarantee 765 an upper bound on the time taken to restore traffic flow upon the 766 failure of a directly connected link or node. As these techniques 767 steer traffic to the post-convergence path as quickly as possible, 768 this serves to minimize the disruption associated with a local 769 failure which can be seen as a modest security enhancement. The 770 protection mechanisms does not protect external destinations, but 771 rather provides quick restoration for destination that are 772 internal to a routing domain. 774 8. IANA Considerations 776 No requirements for IANA 778 9. Conclusions 780 This document proposes a mechanism that is able to pre-calculate a 781 backup path for every primary path so as to be able to protect 782 against the failure of a directly connected link, node, or SRLG. 783 The mechanism is able to calculate the backup path irrespective of 784 the topology as long as the topology is sufficiently redundant. 786 10. References 788 10.1. Normative References 790 10.2. Informative References 792 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 793 Shakir, "Segment Routing Architecture", draft-ietf-spring- 794 segment-routing-08 (work in progress), May 2016. 796 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 797 5714, January 2010. 799 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, 800 J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 801 Applicability in Service Provider (SP) Networks", RFC 6571, 802 June 2012. 804 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, 805 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 806 7490, DOI 10.17487/RFC7490, April 2015, . 809 [5] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 810 Horneffer, M., and P. Sarkar, "Operational Management of Loop- 811 Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, 812 . 814 [6] Bashandy, A., Filsfils, C., and Litkowski, S., " Loop 815 avoidance using Segment Routing", draft-bashandy-rtgwg- 816 segment-routing-uloop-00, (work in progress), May 2017 818 [7] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 819 Shakir, R, "Segment Routing Architecture", draft-ietf-spring- 820 segment-routing-11 (work in progress), February 2017 822 11. Acknowledgments 824 We would like to give Les Ginsberg special thanks for the valuable 825 comments and contribution 827 This document was prepared using 2-Word-v2.0.template.dot. 829 Authors' Addresses 831 Pierre Francois 832 INSA Lyon 833 Email: pierre.francois@insa-lyon.fr 835 Ahmed Bashandy 836 Arrcus 837 Email: abashandy.ietf@gmail.com 839 Clarence Filsfils 840 Cisco Systems 841 Brussels, Belgium 842 Email: cfilsfil@cisco.com 844 Bruno Decraene 845 Orange 846 Issy-les-Moulineaux 847 FR 848 Email: bruno.decraene@orange.com 850 Stephane Litkowski 851 Orange 852 FR 853 Email: stephane.litkowski@orange.com 855 Daniel Voyer 856 Bell Canada 857 Canada 858 Email: daniel.voyer@bell.ca 860 Pablo Camarillo 861 Cisco Systems 862 Email: pcamaril@cisco.com 864 Francois Clad 865 Cisco Systems 866 Email: fclad@cisco.com