idnits 2.17.1 draft-bashandy-rtgwg-segment-routing-ti-lfa-05.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...' 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 (October 4, 2018) is 2031 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 418 -- Looks like a reference, but probably isn't: 'Node' on line 418 == Unused Reference: '3' is defined on line 786, 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: April 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 October 4, 2018 17 Topology Independent Fast Reroute using Segment Routing 18 draft-bashandy-rtgwg-segment-routing-ti-lfa-05 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 April 4, 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}..........10 110 6. Measurements on Real Networks.................................11 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. 414 In Section 5.3.2, we describe the TI-LFA behavior of PLR S when 415 node protection is applied and the two first segments are Adjacency 416 Segments. 418 5.2.2. Protecting [Adjacency, Node] segment lists 420 If the next segment in the stack is a node segment, say for node T, 421 the packet segment list matches [adj(S-F),node(T),...]. 423 A first solution would consist in steering the packet back to F 424 while avoiding S-F. To do so, S applies a "NEXT" operation on 425 Adj(S-F) and then two consecutive "PUSH" operations: first it pushes 426 a node segment for F, and then it pushes a repair list allowing to 427 reach F while bypassing S-F. 429 Upon failure of S-F, a packet reaching S with a segment list 430 matching [adj(S-F),node(T),...] will thus leave S with a segment 431 list matching [RT(F),node(F),node(T)]. 433 Another solution is to not steer the packet back via F but rather 434 follow the new shortest path to T. In this case, S just needs to 435 apply a "NEXT" operation on the Adjacency segment related to S-F, 436 and push a repair list redirecting the traffic to a node Q, whose 437 path to node segment T is not affected by the failure. 439 Upon failure of S-F, packets reaching S with a segment list matching 440 [adj(L), node(T), ...], would leave S with a segment list matching 441 [RT(Q),node(T), ...]. Note that this second behavior is the one 442 followed for node protection, as described in Section 5.3.1. 444 5.3. Protecting SR policy midpoints against node failure 446 In this section, we describe the behavior of a node S configured to 447 interpret the failure of link S->F as the node failure of F, in the 448 specific case where the active segment of the packet received by S 449 is a Prefix SID of F represented as "F"), or an Adjacency SID for 450 the link S-F (represented as "S->F"). 452 5.3.1. Protecting {F, T, D} or {S->F, T, D} 454 This section describes the protection behavior of S when all of the 455 following conditions are true: 457 1. the active segment is a prefix SID for a neighbor F, or an 458 adjacency segment S->F 460 2. the primary interface used to forward the packet failed 462 3. the segment following the active segment is a prefix SID (for 463 node T) 465 4. node protection is active for that interface. 467 The TILFA Node FRR behavior becomes equivalent to: 469 1. Pop; the segment F or S->F is removed 471 2. Confirm that the next segment is in the SRGB of F, meaning that 472 the next segment is a prefix segment, e.g. for node T 474 3. Identify T (as per the SRGB of F) 476 4. Pop the next segment and push T's segment based on the local SRGB 478 5. forward the packet according to T. 480 5.3.2. Protecting {F, F->T, D} or {S->F, F->T, D} 482 This section describes the protection behavior of S when all of the 483 following conditions are true: 485 1. the active segment is a prefix SID for a neighbor F, or an 486 adjacency segment S->F 488 2. the primary interface used to forward the packet failed 490 3. the segment following the active segment is an adjacency SID (F- 491 >T) 493 4. node protection is active for that interface. 495 The TILFA Node FRR behavior becomes equivalent to: 497 1. Pop; the segment F or S->F is removed 499 2. Confirm that the next segment is an adjacency SID of F, say F->T 501 3. Identify T (as per the set of Adjacency Segments of F) 503 4. Pop the next segment and push T's segment based on the local SRGB 505 5. forward the packet according to T. 507 It is noteworthy to mention that node "S" in the procedures 508 described in Sections 5.3.1 and 5.3.2 can always determine whether 509 the segment after popping the top segment is an adjacency SID or a 510 prefix-SID of the next-hop "F" as follows: 512 1. In a link state environment, the node "S" knows the SRGB and the 513 adj-SIDs of the neighboring node "F" 515 2. If the new segment after popping the top segment is within the 516 SRGB or the adj-SIDs of "F", then node "S" is certain that the 517 failure of node "F" is a midpoint failure and hence node "S" 518 applies the procedures specified in Sections 5.3.1 or 5.3.2, 519 respectively. 521 3. Otherwise the failure is not a midpoint failure and hence the 522 node "S" may apply other protection techniques that are beyond 523 the scope of this document or simply drop the packet and wait for 524 normal protocol conversion. 526 6. Measurements on Real Networks 528 This section presents measurements performed on real service 529 provider and large enterprise networks. The objective of the 530 measurements is to assess the number of SIDs required in an explicit 531 path when the mechanism described in this document are used to 532 protect against the failure scenarios within the scope of this 533 document. The number of segments described in this section are 534 applicable to instantiating segment routing over the MPLS forwarding 535 plane. 537 The measurements below indicate that for link and local SRLG 538 protection, a 1 SID repair path delivers more than 99% coverage. For 539 node protection a 2 SIDs repair path yields 99% coverage. 541 Table 1 below lists the characteristics of the networks used in our 542 measurements. The measurements are carried out as follows 544 o For each network, the algorithms described in this document are 545 applied to protect all prefixes against link, node, and local 546 SRLG failure 548 o For each prefix, the number of SIDs used by the repair path is 549 recored 551 o The percentage of number of SIDs are listed in Tables 2A/B, 3A/B, 552 and 4A/B 554 The measurements listed in the tables indicate that for link and 555 local SRLG protection, 1 SID repair paths are sufficient to protect 556 more than 99% of the prefix in almost all cases. For node protection 557 2 SIDs repair paths yield 99% coverage. 559 +-------------+------------+------------+------------+------------+ 560 | Network | Nodes | Circuits |Node-to-Link| SRLG info? | 561 | | | | Ratio | | 562 +-------------+------------+------------+------------+------------+ 563 | T1 | 408 | 665 | 1 : 63 | Yes | 564 +-------------+------------+------------+------------+------------+ 565 | T2 | 587 | 1083 | 1 : 84 | No | 566 +-------------+------------+------------+------------+------------+ 567 | T3 | 93 | 401 | 4 : 31 | Yes | 568 +-------------+------------+------------+------------+------------+ 569 | T4 | 247 | 393 | 1 : 59 | Yes | 570 +-------------+------------+------------+------------+------------+ 571 | T5 | 34 | 96 | 2 : 82 | Yes | 572 +-------------+------------+------------+------------+------------+ 573 | T6 | 50 | 78 | 1 : 56 | No | 574 +-------------+------------+------------+------------+------------+ 575 | T7 | 82 | 293 | 3 : 57 | No | 576 +-------------+------------+------------+------------+------------+ 577 | T8 | 35 | 41 | 1 : 17 | Yes | 578 +-------------+------------+------------+------------+------------+ 579 | T9 | 177 | 1371 | 7 : 74 | Yes | 580 +-------------+------------+------------+------------+------------+ 581 Table 1: Data Set Definition 583 The rest of this section presents the measurements done on the 584 actual topologies. The convention that we use is as follows 586 o 0 SIDs: the calculated repair path starts with a directly 587 connected neighbor that is also a loop free alternate, in which 588 case there is no need to explicitly route the traffic using 589 additional SIDs. This scenario is described in Section 4.1. 591 o 1 SIDs: the repair node is a PQ node, in which case only 1 SID is 592 needed to guarantee loop-freeness. This scenario is covered in 593 Section 4.2. 595 o 2 or more SIDs: The repair path consists of 2 or more SIDs as 596 described in Sections 4.3 and 4.4. We do not cover the case for 597 2 SIDs (Section 4.3) separately because there was no 598 granularity in the result. Also we treat the node-SID+adj-SID and 599 node-SID + node-SID the same because they do not differ from the 600 data plane point of view. 602 Table 2A and 2B below summarize the measurements on the number of 603 SIDs needed for link protection 604 +-------------+------------+------------+------------+------------+ 605 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 606 +-------------+------------+------------+------------+------------+ 607 | T1 | 74.227% | 25.256% | 0.517% | 0.001% | 608 +-------------+------------+------------+------------+------------+ 609 | T2 | 81.097% | 18.738% | 0.165% | 0.0% | 610 +-------------+------------+------------+------------+------------+ 611 | T3 | 95.878% | 4.067% | 0.056% | 0.0% | 612 +-------------+------------+------------+------------+------------+ 613 | T4 | 62.547% | 35.666% | 1.788% | 0.0% | 614 +-------------+------------+------------+------------+------------+ 615 | T5 | 85.733% | 14.267% | 0.0% | 0.0% | 616 +-------------+------------+------------+------------+------------+ 617 | T6 | 81.252% | 18.714% | 0.033% | 0.0% | 618 +-------------+------------+------------+------------+------------+ 619 | T7 | 98,857% | 1.143% | 0.0% | 0.0% | 620 +-------------+------------+------------+------------+------------+ 621 | T8 | 94,118% | 5.882% | 0.0% | 0.0% | 622 +-------------+------------+------------+------------+------------+ 623 | T9 | 98.950% | 1.050% | 0.0% | 0.0% | 624 +-------------+------------+------------+------------+------------+ 625 Table 2A: Link protection (repair size distribution) 627 +-------------+------------+------------+------------+------------+ 628 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 629 +-------------+------------+------------+------------+------------+ 630 | T1 | 74.227% | 99.482% | 99.999% | 100.0% | 631 +-------------+------------+------------+------------+------------+ 632 | T2 | 81.097% | 99.835% | 100.0% | 100.0% | 633 +-------------+------------+------------+------------+------------+ 634 | T3 | 95.878% | 99.944% | 100.0% | 100.0% | 635 +-------------+------------+------------+------------+------------+ 636 | T4 | 62.547% | 98.212% | 100.0% | 100.0% | 637 +-------------+------------+------------+------------+------------+ 638 | T5 | 85.733% | 100.000% | 100.0% | 100.0% | 639 +-------------+------------+------------+------------+------------+ 640 | T6 | 81.252% | 99.967% | 100.0% | 100.0% | 641 +-------------+------------+------------+------------+------------+ 642 | T7 | 98,857% | 100.000% | 100.0% | 100.0% | 643 +-------------+------------+------------+------------+------------+ 644 | T8 | 94,118% | 100.000% | 100.0% | 100.0% | 645 +-------------+------------+------------+------------+------------+ 646 | T9 | 98,950% | 100.000% | 100.0% | 100.0% | 647 +-------------+------------+------------+------------+------------+ 648 Table 2B: Link protection repair size cumulative distribution 650 Table 3A and 3B summarize the measurements on the number of SIDs 651 needed for local SRLG protection. 653 +-------------+------------+------------+------------+------------+ 654 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 655 +-------------+------------+------------+------------+------------+ 656 | T1 | 74.177% | 25.306% | 0.517% | 0.001% | 657 +-------------+------------+------------+------------+------------+ 658 | T2 | No SRLG Information | 659 +-------------+------------+------------+------------+------------+ 660 | T3 | 93.650% | 6.301% | 0.049% | 0.0% | 661 +-------------+------------+------------+------------+------------+ 662 | T4 | 62,547% | 35.666% | 1.788% | 0.0% | 663 +-------------+------------+------------+------------+------------+ 664 | T5 | 83.139% | 16.861% | 0.0% | 0.0% | 665 +-------------+------------+------------+------------+------------+ 666 | T6 | No SRLG Information | 667 +-------------+---------------------------------------------------+ 668 | T7 | No SRLG Information | 669 +-------------+------------+------------+------------+------------+ 670 | T8 | 85.185% | 14.815% | 0.0% | 0.0% | 671 +-------------+------------+------------+------------+------------+ 672 | T9 | 98,940% | 1.060% | 0.0% | 0.0% | 673 +-------------+------------+------------+------------+------------+ 674 Table 3A: Local SRLG protection repair size distribution 676 +-------------+------------+------------+------------+------------+ 677 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 678 +-------------+------------+------------+------------+------------+ 679 | T1 | 74.177% | 99.482% | 99.999% | 100.001% | 680 +-------------+------------+------------+------------+------------+ 681 | T2 | No SRLG Information | 682 +-------------+------------+------------+------------+------------+ 683 | T3 | 93.650% | 99.951% | 100.000% | 0.0% | 684 +-------------+------------+------------+------------+------------+ 685 | T4 | 62,547% | 98.212% | 100.000% | 100.0% | 686 +-------------+------------+------------+------------+------------+ 687 | T5 | 83.139% | 100.000% | 100.0% | 100.0% | 688 +-------------+------------+------------+------------+------------+ 689 | T6 | No SRLG Information | 690 +-------------+---------------------------------------------------+ 691 | T7 | No SRLG Information | 692 +-------------+------------+------------+------------+------------+ 693 | T8 | 85.185% | 100,000% | 100.000% | 100.0% | 694 +-------------+------------+------------+------------+------------+ 695 | T9 | 98,940% | 100,000% | 100.000% | 100.0% | 696 +-------------+------------+------------+------------+------------+ 697 Table 3B: Local SRLG protection repair size Cumulative distribution 699 The remaining two tables summarize the measurements on the number of 700 SIDs needed for node protection. 702 +---------+----------+----------+----------+----------+----------+ 703 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 704 +---------+----------+----------+----------+----------+----------+ 705 | T1 | 49.771% | 47.902% | 2.156% | 0.148% | 0.023% | 706 +---------+----------+----------+----------+----------+----------+ 707 | T2 | 36,528% | 59.625% | 3.628% | 0.194% | 0.025% | 708 +---------+----------+----------+----------+----------+----------+ 709 | T3 | 73,287% | 25,574% | 1,128% | 0.010% | 0% | 710 +---------+----------+----------+----------+----------+----------+ 711 | T4 | 36.112% | 57.350% | 6.329% | 0.199% | 0.010% | 712 +---------+----------+----------+----------+----------+----------+ 713 | T5 | 73.185% | 26.815% | 0% | 0% | 0% | 714 +---------+----------+----------+----------+----------+----------+ 715 | T6 | 78.362% | 21.320% | 0.318% | 0% | 0% | 716 +---------+----------+----------+----------+----------+----------+ 717 | T7 | 66.106% | 32.813% | 1.082% | 0% | 0% | 718 +---------+----------+----------+----------+----------+----------+ 719 | T8 | 59.712% | 40.288% | 0% | 0% | 0% | 720 +---------+----------+----------+----------+----------+----------+ 721 | T9 | 98.950% | 1.050% | 0% | 0% | 0% | 722 +---------+----------+----------+----------+----------+----------+ 723 Table 4A: Node protection (repair size distribution) 725 +---------+----------+----------+----------+----------+----------+ 726 | Network | 0 SIDs | 1 SID | 2 SIDs | 3 SIDs | 4 SIDs | 727 +---------+----------+----------+----------+----------+----------+ 728 | T1 | 49.771% | 97.673% | 99.829% | 99.977% | 100% | 729 +---------+----------+----------+----------+----------+----------+ 730 | T2 | 36,528% | 96.153% | 99.781% | 99.975% | 100% | 731 +---------+----------+----------+----------+----------+----------+ 732 | T3 | 73,287% | 98.862% | 99.990% |100.0% | 100% | 733 +---------+----------+----------+----------+----------+----------+ 734 | T4 | 36.112% | 93.461% | 99.791% | 99.990% | 100% | 735 +---------+----------+----------+----------+----------+----------+ 736 | T5 | 73.185% | 100.0% | 100.0% |100.0% | 100% | 737 +---------+----------+----------+----------+----------+----------+ 738 | T6 | 78.362% | 99.682% | 100.0% |100.0% | 100% | 739 +---------+----------+----------+----------+----------+----------+ 740 | T7 | 66.106% | 98,918% | 100.0% |100.0% | 100% | 741 +---------+----------+----------+----------+----------+----------+ 742 | T8 | 59.712% | 100.0% | 100.0% |100.0% | 100% | 743 +---------+----------+----------+----------+----------+----------+ 744 | T9 | 98.950% | 100.0% | 100.0% |100.0% | 100% | 745 +---------+----------+----------+----------+----------+----------+ 746 Table 4B: Node protection (repair size cumulative distribution) 748 7. Security Considerations 750 The techniques described in this document is internal 751 functionality to a router that result in the ability to guarantee 752 an upper bound on the time taken to restore traffic flow upon the 753 failure of a directly connected link or node. As these techniques 754 steer traffic to the post-convergence path as quickly as possible, 755 this serves to minimize the disruption associated with a local 756 failure which can be seen as a modest security enhancement. The 757 protection mechanisms does not protect external destinations, but 758 rather provides quick restoration for destination that are 759 internal to a routing domain. 761 8. IANA Considerations 763 No requirements for IANA 765 9. Conclusions 767 This document proposes a mechanism that is able to pre-calculate a 768 backup path for every primary path so as to be able to protect 769 against the failure of a directly connected link, node, or SRLG. 770 The mechanism is able to calculate the backup path irrespective of 771 the topology as long as the topology is sufficiently redundant. 773 10. References 775 10.1. Normative References 777 10.2. Informative References 779 [1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. 780 Shakir, "Segment Routing Architecture", draft-ietf-spring- 781 segment-routing-08 (work in progress), May 2016. 783 [2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 784 5714, January 2010. 786 [3] Filsfils, C., Francois, P., Shand, M., Decraene, B., Uttaro, 787 J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) 788 Applicability in Service Provider (SP) Networks", RFC 6571, 789 June 2012. 791 [4] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, 792 "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 793 7490, DOI 10.17487/RFC7490, April 2015, . 796 [5] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 797 Horneffer, M., and P. Sarkar, "Operational Management of Loop- 798 Free Alternates", RFC 7916, DOI 10.17487/RFC7916, July 2016, 799 . 801 [6] Bashandy, A., Filsfils, C., and Litkowski, S., " Loop 802 avoidance using Segment Routing", draft-bashandy-rtgwg- 803 segment-routing-uloop-00, (work in progress), May 2017 805 [7] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and 806 Shakir, R, "Segment Routing Architecture", draft-ietf-spring- 807 segment-routing-11 (work in progress), February 2017 809 11. Acknowledgments 811 We would like to give Les Ginsberg special thanks for the valuable 812 comments and contribution 814 This document was prepared using 2-Word-v2.0.template.dot. 816 Authors' Addresses 818 Pierre Francois 819 INSA Lyon 820 Email: pierre.francois@insa-lyon.fr 822 Ahmed Bashandy 823 Arrcus 824 Email: abashandy.ietf@gmail.com 826 Clarence Filsfils 827 Cisco Systems 828 Brussels, Belgium 829 Email: cfilsfil@cisco.com 831 Bruno Decraene 832 Orange 833 Issy-les-Moulineaux 834 FR 835 Email: bruno.decraene@orange.com 837 Stephane Litkowski 838 Orange 839 FR 840 Email: stephane.litkowski@orange.com 842 Daniel Voyer 843 Bell Canada 844 Canada 845 Email: daniel.voyer@bell.ca 847 Pablo Camarillo 848 Cisco Systems 849 Email: pcamaril@cisco.com 851 Francois Clad 852 Cisco Systems 853 Email: fclad@cisco.com