idnits 2.17.1 draft-ietf-rtgwg-lfa-manageability-08.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 date (March 4, 2015) is 3341 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) == Unused Reference: 'RFC5307' is defined on line 1002, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) ** Downref: Normative reference to an Informational RFC: RFC 6571 == Outdated reference: A later version (-11) exists of draft-ietf-isis-node-admin-tag-00 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-rlfa-node-protection-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft B. Decraene 4 Intended status: Standards Track Orange 5 Expires: September 5, 2015 C. Filsfils 6 K. Raza 7 Cisco Systems 8 M. Horneffer 9 Deutsche Telekom 10 P. Sarkar 11 Juniper Networks 12 March 4, 2015 14 Operational management of Loop Free Alternates 15 draft-ietf-rtgwg-lfa-manageability-08 17 Abstract 19 Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast 20 ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic 21 (and MPLS LDP traffic by extension). Following first deployment 22 experiences, this document provides operational feedback on LFA, 23 highlights some limitations, and proposes a set of refinements to 24 address those limitations. It also proposes required management 25 specifications. 27 This proposal is also applicable to remote LFA solution. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 5, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Operational issues with default LFA tie breakers . . . . . . 4 71 3.1. Case 1: PE router protecting failures within core network 4 72 3.2. Case 2: PE router choosen to protect core failures while 73 P router LFA exists . . . . . . . . . . . . . . . . . . . 5 74 3.3. Case 3: suboptimal P router alternate choice . . . . . . 6 75 3.4. Case 4: IS-IS overload bit on LFA computing node . . . . 7 76 4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8 77 5. Need for LFA activation granularity . . . . . . . . . . . . . 9 78 6. Configuration requirements . . . . . . . . . . . . . . . . . 9 79 6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 9 80 6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10 81 6.2.1. Connected vs remote alternates . . . . . . . . . . . 11 82 6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 11 83 6.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12 84 6.2.4. Retrieving alternate path attributes . . . . . . . . 12 85 6.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14 86 6.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16 88 6.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17 89 6.2.9. Alternate preference/Node coloring . . . . . . . . . 18 90 7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19 91 7.1. IS-IS overload bit on LFA computing node . . . . . . . . 19 92 7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 20 93 7.3. Required local information . . . . . . . . . . . . . . . 21 94 7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 21 95 7.5. LFA and network planning . . . . . . . . . . . . . . . . 22 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 102 12.2. Informative References . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Definitions 107 o Per-prefix LFA : LFA computation, and best alternate evaluation is 108 done for each destination prefix. As opposed to "Per-next hop" 109 simplification also proposed in [RFC5286] Section 3.8. 111 o PE router : Provider Edge router. These routers are connecting 112 customers 114 o P router : Provider router. These routers are core routers, 115 without customer connections. They provide transit between PE 116 routers and they form the core network. 118 o Core network : subset of the network composed by P routers and 119 links between them. 121 o Core link : network link part of the core network i.e. a P router 122 to P router link. 124 o Link-protecting LFA : alternate providing protection against link 125 failure. 127 o Node-protecting LFA : alternate providing protection against node 128 failure. 130 o Connected alternate : alternate adjacent (at IGP level) to the 131 point of local repair (i.e. an IGP neighbor). 133 o Remote alternate : alternate which is does not share an IGP 134 adjacency with the point of local repair. 136 2. Introduction 138 Following the first deployments of Loop Free Alternates (LFA), this 139 document provides feedback to the community about the management of 140 LFA. 142 Section 3 provides real uses cases illustrating some limitations 143 and suboptimal behavior. 145 Section 5 proposes requirements for activation granularity and 146 policy based selection of the alternate. 148 Section 6 express requirements for the operational management of 149 LFA. 151 3. Operational issues with default LFA tie breakers 153 [RFC5286] introduces the notion of tie breakers when selecting the 154 LFA among multiple candidate alternate next-hops. When multiple LFA 155 exist, RFC 5286 has favored the selection of the LFA providing the 156 best coverage of the failure cases. While this is indeed a goal, 157 this is one among multiple and in some deployment this lead to the 158 selection of a suboptimal LFA. The following sections details real 159 use cases of such limitations. 161 Note that the use case of LFA computation per destination (per-prefix 162 LFA) is assumed throughout this analysis. We also assume in the 163 network figures that all IP prefixes are advertised with zero cost. 165 3.1. Case 1: PE router protecting failures within core network 167 P1 --------- P2 ---------- P3 --------- P4 168 | 1 100 1 | 169 | | 170 | 100 | 100 171 | | 172 | 1 100 1 | 1 5k 173 P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1 174 | | | | | | 175 5k| |5k 5k| |5k | 5k | 5k 176 | | | | | | 177 | +-- PE4 --+ | +---- PE2 ----+ 178 | | | 179 +---- PE5 ----+ | 5k 180 | 181 PE3 183 Figure 1 185 Px routers are P routers using n*10G links. PEs are connected using 186 links with lower bandwidth. 188 In figure 1, let us consider the traffic flowing from PE1 to PE4. 189 The nominal path is P9-P8-P7-P6-PE4. Let us consider the failure of 190 link P7-P8. For P8, P4 is not an LFA and the only available LFA is 191 PE2. 193 When the core link P8-P7 fails, P8 switches all traffic destined to 194 PE4/PE5 towards the node PE2. Hence a PE node and PE links are used 195 to protect the failure of a core link. Typically, PE links have less 196 capacity than core links and congestion may occur on PE2 links. Note 197 that although PE2 was not directly affected by the failure, its links 198 become congested and its traffic will suffer from the congestion. 200 In summary, in case of P8-P7 link failure, the impact on customer 201 traffic is: 203 o From PE2 point of view : 205 * without LFA: no impact 207 * with LFA: traffic is partially dropped (but possibly 208 prioritized by a QoS mechanism). It must be highlighted that 209 in such situation, traffic not affected by the failure may be 210 affected by the congestion. 212 o From P8 point of view: 214 * without LFA: traffic is totally dropped until convergence 215 occurs. 217 * with LFA: traffic is partially dropped (but possibly 218 prioritized by a QoS mechanism). 220 Besides the congestion aspects of using an Edge router as an 221 alternate to protect a core failure, a service provider may consider 222 this as a bad routing design and would like to prevent it. 224 3.2. Case 2: PE router choosen to protect core failures while P router 225 LFA exists 226 P1 --------- P2 ------------ P3 -------- P4 227 | 1 100 | 1 | 228 | | | 229 | 100 | 30 | 30 230 | | | 231 | 1 50 50 | 10 | 1 5k 232 P5 --------- P6 --- P10 ---- P7 -------- P8 --- P9 -- PE1 233 | | | | \ | 234 5k| |5k 5k| |5k \ 5k | 5k 235 | | | | \ | 236 | +-- PE4 --+ | +---- PE2 ----+ 237 | | | 238 +---- PE5 ----+ | 5k 239 | 240 PE3 242 Figure 2 244 Px routers are P routers meshed with n*10G links. PEs are meshed 245 using links with lower bandwidth. 247 In the figure 2, let us consider the traffic coming from PE1 to PE4. 248 Nominal path is P9-P8-P7-P10-P6-PE4. Let us consider the failure of 249 the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a 250 node-protecting LFA. PE2 is chosen as best LFA due to its better 251 protection type. Just like in case 1, this may lead to congestion on 252 PE2 links upon LFA activation. 254 3.3. Case 3: suboptimal P router alternate choice 255 +--- PE3 --+ 256 / \ 257 1000 / \ 1000 258 / \ 259 +----- P1 ---------------- P2 ----+ 260 | | 500 | | 261 | 10 | | | 10 262 | | | | 263 R5 | 10 | 10 R7 264 | | | | 265 | 10 | | | 10 266 | | 500 | | 267 +---- P3 ---------------- P4 -----+ 268 \ / 269 1000 \ / 1000 270 \ / 271 +--- PE1 ---+ 273 Figure 3 275 Px routers are P routers. P1-P2 and P3-P4 links are 1G links. All 276 others inter Px links are 10G links. 278 In the figure above, let us consider the failure of link P1-P3. For 279 destination PE3, P3 has two possible alternates: 281 o P4, which is node-protecting 283 o P5, which is link-protecting 285 P4 is chosen as best LFA due to its better protection type. However, 286 it may not be desirable to use P4 for bandwidth capacity reason. A 287 service provider may prefer to use high bandwidth links as prefered 288 LFA. In this example, prefering shortest path over protection type 289 may achieve the expected behavior, but in cases where metric are not 290 reflecting bandwidth, it would not work and some other criteria would 291 need to be involved when selecting the best LFA. 293 3.4. Case 4: IS-IS overload bit on LFA computing node 294 P1 P2 295 | \ / | 296 50 | 50 \/ 50 | 50 297 | /\ | 298 PE1-+ +-- PE2 299 \ / 300 45 \ / 45 301 -PE3-+ 302 (OL set) 304 Figure 4 306 In the figure above, PE3 has its overload bit set (permanently, for 307 design reason) and wants to protect traffic using LFA for destination 308 PE2. 310 On PE3, the loop-free condition is not satisfied : 100 !< 45 + 45. 311 PE1 is thus not considered as an LFA. However thanks to the overload 312 bit set on PE3, we know that PE1 is loop-free so PE1 is an LFA to 313 reach PE2. 315 In case of overload condition set on a node, LFA behavior must be 316 clarified. 318 4. Need for coverage monitoring 320 As per [RFC6571], LFA coverage highly depends on the used network 321 topology. Even if remote LFA ([I-D.ietf-rtgwg-remote-lfa]) extends 322 significantly the coverage of the basic LFA specification, there is 323 still some cases where protection would not be available. As network 324 topologies are constantly evolving (network extension, capacity 325 addings, latency optimization ...), the protection coverage may 326 change. Fast reroute functionality may be critical for some services 327 supported by the network, a service provider must constantly know 328 what protection coverage is currently available on the network. 329 Moreover, predicting the protection coverage in case of network 330 topology change is mandatory. 332 Today network simulation tool associated with whatif scenarios 333 functionality are often used by service providers for the overall 334 network design (capacity, path optimization ...). Section 7.5, 335 Section 7.4 and Section 7.3 of this document propose to add LFA 336 informations into such tool and within routers, so a service provider 337 may be able : 339 o to evaluate protection coverage after a topology change. 341 o to adjust the topology change to cover the primary need (e.g. 342 latency optimization or bandwidth increase) as well as LFA 343 protection. 345 o monitor constantly the LFA coverage in the live network and being 346 alerted. 348 Implementers SHOULD document their LFA selection algorithms (default 349 and tuning options) in order to leave possibility for 3rd party 350 modules to model these policy-LFA expressions. 352 5. Need for LFA activation granularity 354 As all FRR mechanism, LFA installs backup paths in Forwarding 355 Information Base (FIB). Depending of the hardware used by a service 356 provider, FIB resource may be critical. Activating LFA, by default, 357 on all available components (IGP topologies, interface, address 358 families ...) may lead to waste of FIB resource as generally in a 359 network only few destinations should be protected (e.g. loopback 360 addresses supporting MPLS services) compared to the amount of 361 destinations in RIB. 363 Moreover a service provider may implement multiple different FRR 364 mechanism in its networks for different usages (MRT, TE FRR). In 365 this scenario, an implementation MAY permit to compute alternates for 366 a specific destination even if the destination is already protected 367 by another mechanism. This will bring redundancy and let the ability 368 for the operator to select the best option for FRR using a policy 369 langage. 371 Section 6 of this document propose some implementation guidelines. 373 6. Configuration requirements 375 Controlling best alternate and LFA activation granularity is a 376 requirement for Service Providers. This section defines 377 configuration requirements for LFA. 379 6.1. LFA enabling/disabling scope 381 The granularity of LFA activation should be controlled (as alternate 382 next hop consume memory in forwarding plane). 384 An implementation of LFA SHOULD allow its activation with the 385 following criteria: 387 o Per routing context: VRF, virtual/logical router, global routing 388 table, ... 390 o Per interface 392 o Per protocol instance, topology, area 394 o Per prefixes: prefix protection SHOULD have a better priority 395 compared to interface protection. This means that if a specific 396 prefix must be protected due to a configuration request, LFA must 397 be computed and installed for this prefix even if the primary 398 outgoing interface is not configured for protection. 400 An implementation of LFA MAY allow its activation with the following 401 criteria: 403 o Per address-family: ipv4 unicast, ipv6 unicast 405 o Per MPLS control plane: for MPLS control planes that inherit 406 routing decision from the IGP routing protocol, MPLS dataplane may 407 be protected by LFA. The implementation may allow operator to 408 control this inheritance of protection from the IP prefix to the 409 MPLS label bound to this prefix. The protection inheritance will 410 concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries. As 411 example, LDP and segment-routing extensions for ISIS and OSPF are 412 control plane eligible to this inheritance of protection. 414 6.2. Policy based LFA selection 416 When multiple alternates exist, LFA selection algorithm is based on 417 tie breakers. Current tie breakers do not provide sufficient control 418 on how the best alternate is chosen. This document proposes an 419 enhanced tie breaker allowing service providers to manage all 420 specific cases: 422 1. An implementation of LFA SHOULD support policy-based decision for 423 determining the best LFA. 425 2. Policy based decision SHOULD be based on multiple criterions, 426 with each criteria having a level of preference. 428 3. If the defined policy does not permit to determine a unique best 429 LFA, an implementation SHOULD pick only one based on its own 430 decision, as a default behavior. An implementation SHOULD also 431 support election of multiple LFAs, for loadbalancing purposes. 433 4. Policy SHOULD be applicable to a protected interface or to a 434 specific set of destinations. In case of application on the 435 protected interface, all destinations primarily routed on this 436 interface SHOULD use the interface policy. 438 5. It is an implementation choice to reevaluate policy dynamically 439 or not (in case of policy change). If a dynamic approach is 440 chosen, the implementation SHOULD recompute the best LFAs and 441 reinstall them in FIB, without service disruption. If a non- 442 dynamic approach is chosen, the policy would be taken into 443 account upon the next IGP event. In this case, the 444 implementation SHOULD support a command to manually force the 445 recomputation/reinstallation of LFAs. 447 6.2.1. Connected vs remote alternates 449 In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or 450 Segment Routing) to distant routers may be used to complement LFA 451 coverage (tunnel tail used as virtual neighbor). When a router has 452 multiple alternate candidates for a specific destination, it may have 453 connected alternates and remote alternates (reachable via a tunnel). 454 Connected alternates may not always provide an optimal routing path 455 and it may be preferable to select a remote alternate over a 456 connected alternate. Some usage of tunnels to extend LFA ([RFC5286]) 457 coverage is described in either [I-D.ietf-rtgwg-remote-lfa] or 458 [I-D.francois-segment-routing-ti-lfa]. These documents present some 459 use cases of LDP tunnels ([I-D.ietf-rtgwg-remote-lfa]) or Segment 460 Routing tunnels ([I-D.francois-segment-routing-ti-lfa]). This 461 document considers any type of tunneling techniques to reach remote 462 alternates (IP, GRE, LDP, RSVP-TE, L2TP, Segment Routing ...) and 463 does not restrict the remote alternates to the usage presented in the 464 referenced document. 466 In figure 1, there is no P router alternate for P8 to reach PE4 or 467 PE5 , so P8 is using PE2 as alternate, which may generate congestion 468 when FRR is activated. Instead, we could have a remote alternate for 469 P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 470 to P3 (following shortest path) can be setup and P8 would be able to 471 use P3 as remote alternate to protect traffic to PE4 and PE5. In 472 this scenario, traffic will not use a PE link during FRR activation. 474 When selecting the best alternate, the selection algorithm MUST 475 consider all available alternates (connected or tunnel). Especially, 476 computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be 477 performed before best alternate selection. 479 6.2.2. Mandatory criteria 481 An implementation of LFA MUST support the following criteria: 483 o Non candidate link: A link marked as "non candidate" will never be 484 used as LFA. 486 o A primary next hop being protected by another primary next hop of 487 the same prefix (ECMP case). 489 o Type of protection provided by the alternate: link protection, 490 node protection. In case of node protection preference, an 491 implementation SHOULD support fall back to link protection if node 492 protection is not available. 494 o Shortest path: lowest IGP metric used to reach the destination. 496 o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.6 497 for more details). 499 6.2.3. Enhanced criteria 501 An implementation of LFA SHOULD support the following enhanced 502 criteria: 504 o Downstreamness of an alternate : preference of a downstream path 505 over a non downstream path SHOULD be configurable. 507 o Link coloring with : include, exclude and preference based system 508 (see Section 6.2.7). 510 o Link Bandwidth (see Section 6.2.8). 512 o Alternate preference/Node coloring (see Section 6.2.9). 514 6.2.4. Retrieving alternate path attributes 516 The policy to select the best alternate evaluate multiple criterions 517 (e.g. metric, SRLG, link colors ...) which first need to be computed 518 for each alternate.. In order to compare the different alternate 519 path, a router must retrieve the attributes of each alternate path. 520 The alternate path is composed of two distinct parts : PLR to 521 alternate and alternate to destination. 523 6.2.4.1. Connected alternate 525 For alternate path using a connected alternate : 527 o attributes from PLR to alternate path are retrieved from the 528 interface connected to the alternate. 530 o attributes from alternate to destination path are retrieved from 531 SPF rooted at the alternate. As the alternate is a connected 532 alternate, the SPF has already been computed to find the 533 alternate, so there is no need of additional computation. 535 6.2.4.2. Remote alternate 537 For alternate path using a remote alternate (tunnel) : 539 o attributes from the PLR to alternate path are retrieved using the 540 PLR's primary SPF if P space is used or using the neighbor's SPF 541 if extended P space is used, combined with the attributes of the 542 link(s) to reach that neighbor. In both cases, no additional SPF 543 is required. 545 o attributes from alternate to destination path may be retrieved 546 from SPF rooted at the remote alternate. An additional forward 547 SPF is required for each remote alternate as indicated in 548 [I-D.ietf-rtgwg-rlfa-node-protection] section 3.2.. . In some 549 remote alternate scenarios, like 550 [I-D.francois-segment-routing-ti-lfa], alternate to destination 551 path attributes may be obtained using a different technique. 553 The number of remote alternates may be very high. In case of remote 554 LFA, simulations of real-world network topologies, reveal that order 555 of hundreths of PQ ... 557 To handle this situation, it is needed to limit the number of remote 558 alternates to be evaluated to a finite number before collecting 559 alternate path attributes and running the policy evaluation. [I- 560 D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to 561 reduce the number of PQ to be evaluated. 563 Some other remote alternate techniques using static or dynamic 564 tunnels may not require this pruning. 566 Link Remote Remote 567 alternate alternate alternate 568 ------------- ------------------ ------------- 569 Alternates | LFA | | rLFA (PQs) | | Static/ | 570 | | | | | Dynamic | 571 sources | | | | | tunnels | 572 ------------- ------------------ ------------- 573 | | | 574 | | | 575 | -------------------------- | 576 | | Prune some alternates | | 577 | | (sorting strategy) | | 578 | -------------------------- | 579 | | | 580 | | | 581 ------------------------------------------------ 582 | Collect alternate attributes | 583 ------------------------------------------------ 584 | 585 | 586 ------------------------- 587 | Evaluate policy | 588 ------------------------- 589 | 590 | 591 Best alternates 593 6.2.5. ECMP LFAs 595 10 596 PE2 - PE3 597 | | 598 50 | 5 | 50 599 P1----P2 600 \\ // 601 50 \\ // 50 602 PE1 604 Figure 5 606 Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are 607 L3 and L4 609 In the figure above, primary path from PE1 to PE2 is through P1 using 610 ECMP on two parallel links L1 and L2. In case of standard ECMP 611 behavior, if L1 is failing, postconvergence next hop would become L2 612 and there would be no longer ECMP. If LFA is activated, as stated in 613 [RFC5286] Section 3.4., "alternate next-hops may themselves also be 614 primary next-hops, but need not be" and "alternate next-hops should 615 maximize the coverage of the failure cases". In this scenario there 616 is no alternate providing node protection, LFA will so prefer L2 as 617 alternate to protect L1 which makes sense compared to postconvergence 618 behavior. 620 Considering a different scenario using figure 5, where L1 and L2 are 621 configured as a layer 3 bundle using a local feature, as well as L3/ 622 L4 being a second layer 3 bundle. Layer 3 bundles are configured as 623 if a link in the bundle is failing, the traffic must be rerouted out 624 of the bundle. Layer 3 bundles are generally introduced to increase 625 bandwidth between nodes. In nominal situation, ECMP is still 626 available from PE1 to PE2, but if L1 is failing, postconvergence next 627 hop would become ECMP on L3 and L4. In this case, LFA behavior 628 SHOULD be adapted in order to reflect the bandwidth requirement. 630 We would expect the following FIB entry on PE1 : 632 On PE1 : PE2 +--> ECMP -> L1 633 | | 634 | +----> L2 635 | 636 +--> LFA(ECMP) -> L3 637 | 638 +---------> L4 640 If L1 or L2 is failing, traffic must be switched on the LFA ECMP 641 bundle rather than using the other primary next hop. 643 As mentioned in [RFC5286] Section 3.4., protecting a link within an 644 ECMP by another primary next hop is not a MUST. Moreover, we already 645 presented in this document, that maximizing the coverage of the 646 failure case may not be the right approach and policy based choice of 647 alternate may be preferred. 649 An implementation SHOULD permit to prefer to protect a primary next 650 hop by another primary next hop. An implementation SHOULD permit to 651 prefer to protect a primary next hop by a NON primary next hop. An 652 implementation SHOULD permit to use an ECMP bundle as a LFA. 654 6.2.6. SRLG 656 [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode 657 SRLGs ([RFC4205] and [RFC4203]). The section is also describing the 658 algorithm to compute SRLG protection. 660 When SRLG protection is computed, and implementation SHOULD permit to 661 : 663 o Exclude alternates violating SRLG. 665 o Maintain a preference system between alternates based on number of 666 SRLG violations : more violations = less preference. 668 When applying SRLG criteria, the SRLG violation check SHOULD be 669 performed on source to alternate as well as alternate to destination 670 paths based on the SRLG set of the primary path. In the case of 671 remote LFA, PQ to destination path attributes would be retrieved from 672 SPT rooted at PQ. 674 6.2.7. Link coloring 676 Link coloring is a powerful system to control the choice of 677 alternates. Protecting interfaces are tagged with colors. Protected 678 interfaces are configured to include some colors with a preference 679 level, and exclude others. 681 Link color information SHOULD be signalled in the IGP. How 682 signalling is done is out of scope of the document but it may be 683 useful to reuse existing admin-groups from traffic-engineering 684 extensions. 686 PE2 687 | +---- P4 688 | / 689 PE1 ---- P1 --------- P2 690 | 10Gb 691 1Gb | 692 | 693 P3 695 Figure 5 697 Example : P1 router is connected to three P routers and two PEs. 699 P1 is configured to protect the P1-P4 link. We assume that given the 700 topology, all neighbors are candidate LFA. We would like to enforce 701 a policy in the network where only a core router may protect against 702 the failure of a core link, and where high capacity links are 703 prefered. 705 In this example, we can use the proposed link coloring by: 707 o Marking PEs links with color RED 708 o Marking 10Gb CORE link with color BLUE 710 o Marking 1Gb CORE link with color YELLOW 712 o Configured the protected interface P1->P4 with : 714 * Include BLUE, preference 200 716 * Include YELLOW, preference 100 718 * Exclude RED 720 Using this, PE links will never be used to protect against P1-P4 link 721 failure and 10Gb link will be be preferred. 723 The main advantage of this solution is that it can easily be 724 duplicated on other interfaces and other nodes without change. A 725 Service Provider has only to define the color system (associate color 726 with a significance), as it is done already for TE affinities or BGP 727 communities. 729 An implementation of link coloring: 731 o SHOULD support multiple include and exclude colors on a single 732 protected interface. 734 o SHOULD provide a level of preference between included colors. 736 o SHOULD support multiple colors configuration on a single 737 protecting interface. 739 6.2.8. Bandwidth 741 As mentionned in previous sections, not taking into account bandwidth 742 of an alternate could lead to congestion during FRR activation. We 743 propose to base the bandwidth criteria on the link speed information 744 for the following reason : 746 o if a router S has a set of X destinations primarly forwarded to N, 747 using per prefix LFA may lead to have a subset of X protected by a 748 neighbor N1, another subset by N2, another subset by Nx ... 750 o S is not aware about traffic flows to each destination and is not 751 able to evaluate how much traffic will be sent to N1,N2, ... Nx in 752 case of FRR activation. 754 Based on this, it is not useful to gather available bandwidth on 755 alternate paths, as the router does not know how much bandwidth it 756 requires for protection. The proposed link speed approach provides a 757 good approximation with a small cost as information is easily 758 available. 760 The bandwidth criteria of the policy framework SHOULD work in two 761 ways : 763 o PRUNE : exclude a LFA if link speed to reach it is lower than the 764 link speed of the primary next hop interface. 766 o PREFER : prefer a LFA based on his bandwidth to reach it compared 767 to the link speed of the primary next hop interface. 769 6.2.9. Alternate preference/Node coloring 771 Rather than tagging interface on each node (using link color) to 772 identify alternate node type (as example), it would be helpful if 773 routers could be identified in the IGP. This would permit a grouped 774 processing on multiple nodes. As an implementation need to exclude 775 some specific alternates (see Section 6.2.3), an implementation : 777 o SHOULD be able to give a preference to specific alternate. 779 o SHOULD be able to give a preference to a group of alternate. 781 o SHOULD be able to exclude a group of alternate. 783 A specific alternate may be identified by its interface, IP address 784 or router ID and group of alternates may be identified by a marker 785 (tag) (for example, in case of IS-IS protocol 786 [I-D.ietf-isis-node-admin-tag] can be used). Using a tag is referred 787 as Node coloring in comparison to link coloring option presented in 788 Section 6.2.7. 790 Consider the following network: 792 PE3 793 | 794 | 795 PE2 796 | +---- P4 797 | / 798 PE1 ---- P1 -------- P2 799 | 10Gb 800 1Gb | 801 | 802 P3 804 Figure 6 806 In the example above, each node is configured with a specific tag 807 flooded through the IGP. 809 o PE1,PE3: 200 (non candidate). 811 o PE2: 100 (edge/core). 813 o P1,P2,P3: 50 (core). 815 A simple policy could be configured on P1 to choose the best 816 alternate for P1->P4 based on router function/role as follows : 818 o criteria 1 -> alternate preference: exclude tag 100 and 200. 820 o criteria 2 -> bandwidth. 822 7. Operational aspects 824 7.1. IS-IS overload bit on LFA computing node 826 In [RFC5286], Section 3.5, the setting of the overload bit condition 827 in LFA computation is only taken into account for the case where a 828 neighbor has the overload bit set. 830 In addition to RFC 5286 inequality 1 Loop-Free Criterion 831 (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the 832 IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be 833 taken into account. Indeed, if it has the overload bit set, no 834 neighbor will loop back to traffic to itself. 836 7.2. Manual triggering of FRR 838 Service providers often perform manual link shutdown (using router 839 CLI) to perform some network changes/tests. A manual link shutdown 840 may be done at multiple level : physical interface, logical 841 interface, IGP interface, BFD session ... Especially testing or 842 troubleshooting FRR requires to perform the manual shutdown on the 843 remote end of the link as generally a local shutdown would not 844 trigger FRR. 846 To enhance such situation, an implementation SHOULD support 847 triggering/activating LFA Fast Reroute for a given link when a manual 848 shutdown is done on a component that currently supports FRR 849 activation. 851 An implementation MAY also support FRR activation for a specific 852 interface or a specific prefix on a primary next-hop interface and 853 revert without any action on any running component of the node (links 854 or protocols). In this use case, the FRR activation time need to be 855 controlled by a timer in case the operator forgot to revert traffic 856 on primary path. When the timer expires, the traffic is 857 automatically reverted to the primary path. This will make easier 858 tests of fast-reroute path and then revert back to the primary path 859 without causing a global network convergence. 861 For example : 863 o if an implementation supports FRR activation upon BFD session down 864 event, this implementation SHOULD support FRR activation when a 865 manual shutdown is done on the BFD session. But if an 866 implementation does not support FRR activation on BFD session 867 down, there is no need for this implementation to support FRR 868 activation on manual shutdown of BFD session. 870 o if an implementation supports FRR activation on physical link down 871 event (e.g. Rx laser Off detection, or error threshold raised 872 ...), this implementation SHOULD support FRR activation when a 873 manual shutdown at physical interface is done. But if an 874 implementation does not support FRR activation on physical link 875 down event, there is no need for this implementation to support 876 FRR activation on manual physical link shutdown. 878 o A CLI command may permit to switch from primary path to FRR path 879 for testing FRR path for a specific. There is no impact on 880 controlplane, only dataplane of the local node could be changed. 881 A similar command may permit to switch back traffic from FRR path 882 to primary path. 884 7.3. Required local information 886 LFA introduction requires some enhancement in standard routing 887 information provided by implementations. Moreover, due to the non 888 100% coverage, coverage informations is also required. 890 Hence an implementation : 892 o MUST be able to display, for every prefixes, the primary next hop 893 as well as the alternate next hop information. 895 o MUST provide coverage information per activation domain of LFA 896 (area, level, topology, instance, virtual router, address family 897 ...). 899 o MUST provide number of protected prefixes as well as non protected 900 prefixes globally. 902 o SHOULD provide number of protected prefixes as well as non 903 protected prefixes per link. 905 o MAY provide number of protected prefixes as well as non protected 906 prefixes per priority if implementation supports prefix-priority 907 insertion in RIB/FIB. 909 o SHOULD provide a reason for choosing an alternate (policy and 910 criteria) and for excluding an alternate. 912 o SHOULD provide the list of non protected prefixes and the reason 913 why they are not protected (no protection required or no alternate 914 available). 916 7.4. Coverage monitoring 918 It is pretty easy to evaluate the coverage of a network in a nominal 919 situation, but topology changes may change the coverage. In some 920 situations, the network may no longer be able to provide the required 921 level of protection. Hence, it becomes very important for service 922 providers to get alerted about changes of coverage. 924 An implementation SHOULD : 926 o provide an alert system if total coverage (for a node) is below a 927 defined threshold or comes back to a normal situation. 929 o provide an alert system if coverage of a specific link is below a 930 defined threshold or comes back to a normal situation. 932 An implementation MAY : 934 o provide an alert system if a specific destination is not protected 935 anymore or when protection comes back up for this destination 937 Although the procedures for providing alerts are beyond the scope of 938 this document, we recommend that implementations consider standard 939 and well used mechanisms like syslog or SNMP traps. 941 7.5. LFA and network planning 943 The operator may choose to run simulations in order to ensure full 944 coverage of a certain type for the whole network or a given subset of 945 the network. This is particularly likely if he operates the network 946 in the sense of the third backbone profiles described in [RFC6571], 947 that is, he seeks to design and engineer the network topology in a 948 way that a certain coverage is always achieved. Obviously a complete 949 and exact simulation of the IP FRR coverage can only be achieved, if 950 the behavior is deterministic and if the algorithm used is available 951 to the simulation tool. Thus, an implementation SHOULD: 953 o Behave deterministic in its selection LFA process. I.e. in the 954 same topology and with the same policy configuration, the 955 implementation MUST always choose the same alternate for a given 956 prefix. 958 o Document its behavior. The implementation SHOULD provide enough 959 documentation of its behavior that allows an implementer of a 960 simulation tool, to foresee the exact choice of the LFA 961 implementation for every prefix in a given topology. This SHOULD 962 take into account all possible policy configuration options. One 963 possible way to document this behavior is to disclose the 964 algorithm used to choose alternates. 966 8. Security Considerations 968 This document does not introduce any change in security consideration 969 compared to [RFC5286]. 971 9. Contributors 973 Significant contributions were made by Pierre Francois, Hannes 974 Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri and Mustapha 975 Aissaoui which the authors would like to acknowledge. 977 10. Acknowledgements 979 11. IANA Considerations 981 This document has no action for IANA. 983 12. References 985 12.1. Normative References 987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", BCP 14, RFC 2119, March 1997. 990 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 991 of Generalized Multi-Protocol Label Switching (GMPLS)", 992 RFC 4203, October 2005. 994 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 995 Intermediate System (IS-IS) Extensions in Support of 996 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 997 4205, October 2005. 999 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1000 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1002 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1003 of Generalized Multi-Protocol Label Switching (GMPLS)", 1004 RFC 5307, October 2008. 1006 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 1007 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 1008 Alternate (LFA) Applicability in Service Provider (SP) 1009 Networks", RFC 6571, June 2012. 1011 12.2. Informative References 1013 [I-D.francois-segment-routing-ti-lfa] 1014 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 1015 "Topology Independent Fast Reroute using Segment Routing", 1016 draft-francois-segment-routing-ti-lfa-00 (work in 1017 progress), November 2013. 1019 [I-D.ietf-isis-node-admin-tag] 1020 Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., 1021 Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. 1022 Raghuveer, "Advertising Per-node Admin Tags in IS-IS", 1023 draft-ietf-isis-node-admin-tag-00 (work in progress), 1024 December 2014. 1026 [I-D.ietf-rtgwg-remote-lfa] 1027 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 1028 So, "Remote Loop-Free Alternate (LFA) Fast Re-Route 1029 (FRR)", draft-ietf-rtgwg-remote-lfa-11 (work in progress), 1030 January 2015. 1032 [I-D.ietf-rtgwg-rlfa-node-protection] 1033 Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, 1034 S., and H. Raghuveer, "Remote-LFA Node Protection and 1035 Manageability", draft-ietf-rtgwg-rlfa-node-protection-01 1036 (work in progress), December 2014. 1038 Authors' Addresses 1040 Stephane Litkowski 1041 Orange 1043 Email: stephane.litkowski@orange.com 1045 Bruno Decraene 1046 Orange 1048 Email: bruno.decraene@orange.com 1050 Clarence Filsfils 1051 Cisco Systems 1053 Email: cfilsfil@cisco.com 1055 Kamran Raza 1056 Cisco Systems 1058 Email: skraza@cisco.com 1060 Martin Horneffer 1061 Deutsche Telekom 1063 Email: Martin.Horneffer@telekom.de 1065 Pushpasis Sarkar 1066 Juniper Networks 1068 Email: psarkar@juniper.net