idnits 2.17.1 draft-ietf-rtgwg-lfa-manageability-06.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 (January 6, 2015) is 3395 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: 'I-D.ietf-isis-node-admin-tag' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'RFC3906' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 969, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-11) exists of draft-ietf-isis-node-admin-tag-00 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-09 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-rlfa-node-protection-01 Summary: 1 error (**), 0 flaws (~~), 11 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: July 10, 2015 C. Filsfils 6 K. Raza 7 Cisco Systems 8 M. Horneffer 9 Deutsche Telekom 10 P. Sarkar 11 Juniper Networks 12 January 6, 2015 14 Operational management of Loop Free Alternates 15 draft-ietf-rtgwg-lfa-manageability-06 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 July 10, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Operational issues with default LFA tie breakers . . . . . . 3 70 2.1. Case 1: Edge router protecting core failures . . . . . . 3 71 2.2. Case 2: Edge router choosen to protect core failures 72 while core LFA exists . . . . . . . . . . . . . . . . . . 5 73 2.3. Case 3: suboptimal core alternate choice . . . . . . . . 5 74 2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 6 75 3. Need for coverage monitoring . . . . . . . . . . . . . . . . 7 76 4. Need for LFA activation granularity . . . . . . . . . . . . . 8 77 5. Configuration requirements . . . . . . . . . . . . . . . . . 8 78 5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 8 79 5.2. Policy based LFA selection . . . . . . . . . . . . . . . 9 80 5.2.1. Connected vs remote alternates . . . . . . . . . . . 9 81 5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 10 82 5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 10 83 5.2.4. Retrieving alternate path attributes . . . . . . . . 11 84 5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 12 85 5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 14 87 5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 15 88 5.2.9. Alternate preference . . . . . . . . . . . . . . . . 16 89 6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 17 90 6.1. ISIS overload bit on LFA computing node . . . . . . . . . 17 91 6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17 92 6.3. Required local information . . . . . . . . . . . . . . . 18 93 6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 19 94 6.5. LFA and network planning . . . . . . . . . . . . . . . . 19 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 11.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 Following the first deployments of Loop Free Alternates (LFA), this 107 document provides feedback to the community about the management of 108 LFA. 110 Section 2 provides real uses cases illustrating some limitations 111 and suboptimal behavior. 113 Section 4 proposes requirements for activation granularity and 114 policy based selection of the alternate. 116 Section 5 express requirements for the operational management of 117 LFA. 119 2. Operational issues with default LFA tie breakers 121 [RFC5286] introduces the notion of tie breakers when selecting the 122 LFA among multiple candidate alternate next-hops. When multiple LFA 123 exist, RFC 5286 has favored the selection of the LFA providing the 124 best coverage of the failure cases. While this is indeed a goal, 125 this is one among multiple and in some deployment this lead to the 126 selection of a suboptimal LFA. The following sections details real 127 use cases of such limitations. 129 Note that the use case of per-prefix LFA is assumed throughout this 130 analysis. 132 2.1. Case 1: Edge router protecting core failures 133 R1 --------- R2 ---------- R3 --------- R4 134 | 1 100 1 | 135 | | 136 | 100 | 100 137 | | 138 | 1 100 1 | 139 R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1 140 | | | | 141 | 5k | 5k | 5k | 5k 142 | | | | 143 +--- n*PEx ---+ +---- PE2 ----+ 144 | 145 | 146 PEy 148 Figure 1 150 Rx routers are core routers using n*10G links. PEs are connected 151 using links with lower bandwidth. PEx are a set of PEs connected to 152 R5 and R6. 154 In figure 1, let us consider the traffic flowing from PE1 to PEx. 155 The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of 156 link R7-R8. For R8, R4 is not an LFA and the only available LFA is 157 PE2. 159 When the core link R8-R7 fails, R8 switches all traffic destined to 160 all the PEx towards the edge node PE2. Hence an edge node and edge 161 links are used to protect the failure of a core link. Typically, 162 edge links have less capacity than core links and congestion may 163 occur on PE2 links. Note that although PE2 was not directly affected 164 by the failure, its links become congested and its traffic will 165 suffer from the congestion. 167 In summary, in case of failure, the impact on customer traffic is: 169 o From PE2 point of view : 171 * without LFA: no impact 173 * with LFA: traffic is partially dropped (but possibly 174 prioritized by a QoS mechanism). It must be highlighted that 175 in such situation, traffic not affected by the failure may be 176 affected by the congestion. 178 o From R8 point of view: 180 * without LFA: traffic is totally dropped until convergence 181 occurs. 183 * with LFA: traffic is partially dropped (but possibly 184 prioritized by a QoS mechanism). 186 Besides the congestion aspects of using an Edge router as an 187 alternate to protect a core failure, a service provider may consider 188 this as a bad routing design and would like to prevent it. 190 2.2. Case 2: Edge router choosen to protect core failures while core 191 LFA exists 193 R1 --------- R2 ------------ R3 --------- R4 194 | 1 100 | 1 | 195 | | | 196 | 100 | 30 | 30 197 | | | 198 | 1 50 50 | 10 | 199 R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1 200 | | \ | 201 | 5000 | 5000 \ 5000 | 5000 202 | | \ | 203 +--- n*PEx --+ +----- PE2 ----+ 204 | 205 | 206 PEy 208 Figure 2 210 Rx routers are core routers meshed with n*10G links. PEs are meshed 211 using links with lower bandwidth. 213 In the figure 2, let us consider the traffic coming from PE1 to PEx. 214 Nominal path is R9-R8-R7-R10-R6-PEx. Let us consider the failure of 215 the link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a 216 node-protecting LFA. PE2 is chosen as best LFA due to its better 217 protection type. Just like in case 1, this may lead to congestion on 218 PE2 links upon LFA activation. 220 2.3. Case 3: suboptimal core alternate choice 221 +--- PE3 --+ 222 / \ 223 1000 / \ 1000 224 / \ 225 +----- R1 ---------------- R2 ----+ 226 | | 500 | | 227 | 10 | | | 10 228 | | | | 229 R5 | 10 | 10 R7 230 | | | | 231 | 10 | | | 10 232 | | 500 | | 233 +---- R3 ---------------- R4 -----+ 234 \ / 235 1000 \ / 1000 236 \ / 237 +--- PE1 ---+ 239 Figure 3 241 Rx routers are core routers. R1-R2 and R3-R4 links are 1G links. 242 All others inter Rx links are 10G links. 244 In the figure above, let us consider the failure of link R1-R3. For 245 destination PE3, R3 has two possible alternates: 247 o R4, which is node-protecting 249 o R5, which is link-protecting 251 R4 is chosen as best LFA due to its better protection type. However, 252 it may not be desirable to use R4 for bandwidth capacity reason. A 253 service provider may prefer to use high bandwidth links as prefered 254 LFA. In this example, prefering shortest path over protection type 255 may achieve the expected behavior, but in cases where metric are not 256 reflecting bandwidth, it would not work and some other criteria would 257 need to be involved when selecting the best LFA. 259 2.4. Case 4: ISIS overload bit on LFA computing node 260 P1 P2 261 | \ / | 262 50 | 50 \/ 50 | 50 263 | /\ | 264 PE1-+ +-- PE2 265 \ / 266 45 \ / 45 267 -PE3-+ 268 (OL set) 270 Figure 4 272 In the figure above, PE3 has its overload bit set (permanently, for 273 design reason) and wants to protect traffic using LFA for destination 274 PE2. 276 On PE3, the loopfree condition is not satisified : 100 !< 45 + 45. 277 PE1 is thus not considered as an LFA. However thanks to the overload 278 bit set on PE3, we know that PE1 is loopfree so PE1 is an LFA to 279 reach PE2. 281 In case of overload condition set on a node, LFA behavior must be 282 clarified. 284 3. Need for coverage monitoring 286 As per [RFC6571], LFA coverage highly depends on the used network 287 topology. Even if remote LFA ([I-D.ietf-rtgwg-remote-lfa]) extends 288 significantly the coverage of the basic LFA specification, there is 289 still some cases where protection would not be available. As network 290 topologies are constantly evolving (network extension, capacity 291 addings, latency optimization ...), the protection coverage may 292 change. Fast reroute functionality may be critical for some services 293 supported by the network, a service provider must constantly know 294 what protection coverage is currently available on the network. 295 Moreover, predicting the protection coverage in case of network 296 topology change is mandatory. 298 Today network simulation tool associated with whatif scenarios 299 functionnality are often used by service providers for the overall 300 network design (capacity, path optimization ...). Section 6.5, 301 Section 6.4 and Section 6.3 of this document propose to add LFA 302 informations into such tool and within routers, so a service provider 303 may be able : 305 o to evaluate protection coverage after a topology change. 307 o to adjust the topology change to cover the primary need (e.g. 308 latency optimization or bandwidth increase) as well as LFA 309 protection. 311 o monitor constantly the LFA coverage in the live network and being 312 alerted. 314 4. Need for LFA activation granularity 316 As all FRR mechanism, LFA installs backup paths in Forwarding 317 Information Base (FIB). Depending of the hardware used by a service 318 provider, FIB ressource may be critical. Activating LFA, by default, 319 on all available components (IGP topologies, interface, address 320 families ...) may lead to waste of FIB ressource as generally in a 321 network only few destinations should be protected (e.g. loopback 322 addresses supporting MPLS services) compared to the amount of 323 destinations in RIB. 325 Moreover a service provider may implement multiple different FRR 326 mechanism in its networks for different usages (MRT, TE FRR), 327 computing LFAs for prefixes or interfaces that are already protected 328 by another mechanism is useless. 330 Section 5 of this document propose some implementation guidelines. 332 5. Configuration requirements 334 Controlling best alternate and LFA activation granularity is a 335 requirement for Service Providers. This section defines 336 configuration requirements for LFA. 338 5.1. LFA enabling/disabling scope 340 The granularity of LFA activation should be controlled (as alternate 341 nexthop consume memory in forwarding plane). 343 An implementation of LFA SHOULD allow its activation with the 344 following criteria: 346 o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast, 347 LDP IPv6 unicast ... 349 o Per routing context : VRF, virtual/logical router, global routing 350 table, ... 352 o Per interface 354 o Per protocol instance, topology, area 355 o Per prefixes: prefix protection SHOULD have a better priority 356 compared to interface protection. This means that if a specific 357 prefix must be protected due to a configuration request, LFA must 358 be computed and installed for this prefix even if the primary 359 outgoing interface is not configured for protection. 361 5.2. Policy based LFA selection 363 When multiple alternates exist, LFA selection algorithm is based on 364 tie breakers. Current tie breakers do not provide sufficient control 365 on how the best alternate is chosen. This document proposes an 366 enhanced tie breaker allowing service providers to manage all 367 specific cases: 369 1. An implementation of LFA SHOULD support policy-based decision for 370 determining the best LFA. 372 2. Policy based decision SHOULD be based on multiple criterions, 373 with each criteria having a level of preference. 375 3. If the defined policy does not permit to determine a unique best 376 LFA, an implementation SHOULD pick only one based on its own 377 decision, as a default behavior. An implementation SHOULD also 378 support election of multiple LFAs, for loadbalancing purposes. 380 4. Policy SHOULD be applicable to a protected interface or to a 381 specific set of destinations. In case of application on the 382 protected interface, all destinations primarily routed on this 383 interface SHOULD use the interface policy. 385 5. It is an implementation choice to reevaluate policy dynamically 386 or not (in case of policy change). If a dynamic approach is 387 chosen, the implementation SHOULD recompute the best LFAs and 388 reinstall them in FIB, without service disruption. If a non- 389 dynamic approach is chosen, the policy would be taken into 390 account upon the next IGP event. In this case, the 391 implementation SHOULD support a command to manually force the 392 recomputation/reinstallation of LFAs. 394 5.2.1. Connected vs remote alternates 396 In addition to direct LFAs, tunnels (e.g. IP, LDP or RSVP-TE) to 397 distant routers may be used to complement LFA coverage (tunnel tail 398 used as virtual neighbor). When a router has multiple alternate 399 candidates for a specific destination, it may have connected 400 alternates and remote alternates reachable via a tunnel. Connected 401 alternates may not always provide an optimal routing path and it may 402 be preferable to select a remote alternate over a connected 403 alternate. The usage of tunnels to extend LFA coverage is described 404 in [I-D.ietf-rtgwg-remote-lfa]. 406 In figure 1, there is no core alternate for R8 to reach PEs located 407 behind R6, so R8 is using PE2 as alternate, which may generate 408 congestion when FRR is activated. Instead, we could have a remote 409 core alternate for R8 to protect PEs destinations. For example, a 410 tunnel from R8 to R3 would ensure LFA protection without using an 411 edge router to protect a core router. 413 When selecting the best alternate, the selection algorithm MUST 414 consider all available alternates (connected or tunnel). Especially, 415 computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be 416 performed before best alternate selection. 418 5.2.2. Mandatory criteria 420 An implementation of LFA MUST support the following criteria: 422 o Non candidate link: A link marked as "non candidate" will never be 423 used as LFA. 425 o A primary nexthop being protected by another primary nexthop of 426 the same prefix (ECMP case). 428 o Type of protection provided by the alternate: link protection, 429 node protection. In case of node protection preference, an 430 implementation SHOULD support fallback to link protection if node 431 protection is not available. 433 o Shortest path: lowest IGP metric used to reach the destination. 435 o SRLG (as defined in [RFC5286] Section 3, see also Section 5.2.6 436 for more details). 438 5.2.3. Enhanced criteria 440 An implementation of LFA SHOULD support the following enhanced 441 criteria: 443 o Downstreamness of an alternate : preference of a downstream path 444 over a non downstream path SHOULD be configurable. 446 o Link coloring with : include, exclude and preference based system 447 (see Section 5.2.7). 449 o Link Bandwidth (see Section 5.2.8). 451 o Alternate preference (see Section 5.2.9). 453 5.2.4. Retrieving alternate path attributes 455 The policy to select the best alternate evaluate multiple criterions 456 (e.g. metric, SRLG, link colors ...) which first need to be computed 457 for each alternate.. In order to compare the different alternate 458 path, a router must retrieve the attributes of each alternate path. 459 The alternate path is composed of two distinct parts : PLR to 460 alternate and alternate to destination. 462 5.2.4.1. Connected alternate 464 For alternate path using a connected alternate : 466 o attributes from PLR to alternate path are retrieved from the 467 interface connected to the alternate. 469 o attributes from alternate to destination path are retrieved from 470 SPF rooted at the alternate. As the alternate is a connected 471 alternate, the SPF has already been computed to find the 472 alternate, so there is no need of additional computation. 474 5.2.4.2. Remote alternate 476 For alternate path using a remote alternate (tunnel) : 478 o attributes from the PLR to alternate path are retrieved using the 479 PLR's primary SPF if P space is used or using the neighbor's SPF 480 if extended P space is used, combined with the attributes of the 481 link(s) to reach that neighbor. In both cases, no additional SPF 482 is required. 484 o attributes from alternate to destination path are retrieved from 485 SPF rooted at the remote alternate. An additional forward SPF is 486 required for each remote alternate as indicated in 487 [I-D.ietf-rtgwg-rlfa-node-protection] section 3.2.. 489 The number of remote alternates may be very high, simulations shown 490 that hundred's of PQs may exist for a single interface being 491 protected. Running a forward SPF for every PQ-node in the network is 492 not scalable. 494 To handle this situation, it is needed to limit the number of remote 495 alternates to be evaluated to a finite number before collecting 496 alternate path attributes and running the policy evaluation. [I- 497 D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to 498 reduce the number of PQ to be evaluated. 500 Link Remote Remote 501 alternate alternate alternate 502 ------------- ------------------ ------------- 503 Alternates | LFA | | rLFA (PQs) | | Static | 504 sources | | | | | tunnels | 505 ------------- ------------------ ------------- 506 | | | 507 | | | 508 | ---------------------- | 509 | | Prune some PQs | | 510 | | (sorting strategy) | | 511 | ---------------------- | 512 | | | 513 | | | 514 ------------------------------------------------ 515 | Collect alternate attributes | 516 ------------------------------------------------ 517 | 518 | 519 ------------------------- 520 | Evaluate policy | 521 ------------------------- 522 | 523 | 524 Best alternates 526 5.2.5. ECMP LFAs 528 10 529 PE2 - PE3 530 | | 531 50 | 5 | 50 532 P1----P2 533 \\ // 534 50 \\ // 50 535 PE1 537 Figure 5 539 Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are 540 L3 and L4 542 In the figure above, primary path from PE1 to PE2 is through P1 using 543 ECMP on two parallel links L1 and L2. In case of standard ECMP 544 behavior, if L1 is failing, postconvergence nexthop would become L2 545 and there would be no longer ECMP. If LFA is activated, as stated in 546 [RFC5286] Section 3.4., "alternate next-hops may themselves also be 547 primary next-hops, but need not be" and "alternate next-hops should 548 maximize the coverage of the failure cases". In this scenario there 549 is no alternate providing node protection, LFA will so prefer L2 as 550 alternate to protect L1 which makes sense compared to postconvergence 551 behavior. 553 Considering a different scenario using figure 5, where L1 and L2 are 554 configured as a layer 3 bundle using a local feature, as well as L3/ 555 L4 being a second layer 3 bundle. Layer 3 bundles are configured as 556 if a link in the bundle is failing, the traffic must be rerouted out 557 of the bundle. Layer 3 bundles are generally introduced to increase 558 bandwidth between nodes. In nominal situation, ECMP is still 559 available from PE1 to PE2, but if L1 is failing, postconvergence 560 nexthop would become ECMP on L3 and L4. In this case, LFA behavior 561 SHOULD be adapted in order to reflect the bandwidth requirement. 563 We would expect the following FIB entry on PE1 : 565 On PE1 : PE2 +--> ECMP -> L1 566 | | 567 | +----> L2 568 | 569 +--> LFA(ECMP) -> L3 570 | 571 +---------> L4 573 If L1 or L2 is failing, traffic must be switched on the LFA ECMP 574 bundle rather than using the other primary nexthop. 576 As mentioned in [RFC5286] Section 3.4., protecting a link within an 577 ECMP by another primary nexthop is not a MUST. Moreover, we already 578 presented in this document, that maximizing the coverage of the 579 failure case may not be the right approach and policy based choice of 580 alternate may be preferred. 582 An implementation SHOULD permit to prefer a primary nexthop by 583 another primary nexthop with the possibility to deactivate this 584 criteria. An implementation SHOULD permit to use an ECMP bundle as a 585 LFA. 587 5.2.6. SRLG 589 [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode 590 SRLGs ([RFC4205] and [RFC4203]). The section is also describing the 591 algorithm to compute SRLG protection. 593 When SRLG protection is computed, and implementation SHOULD permit to 594 : 596 o Exclude alternates violating SRLG. 598 o Maintain a preference system between alternates based on number of 599 SRLG violations : more violations = less preference. 601 When applying SRLG criteria, the SRLG violation check SHOULD be 602 performed on source to alternate as well as alternate to destination 603 paths. In the case of remote LFA, PQ to destination path attributes 604 would be retrieved from SPT rooted at PQ. 606 5.2.7. Link coloring 608 Link coloring is a powerful system to control the choice of 609 alternates. Protecting interfaces are tagged with colors. Protected 610 interfaces are configured to include some colors with a preference 611 level, and exclude others. 613 Link color information SHOULD be signalled in the IGP. How 614 signalling is done is out of scope of the document but it may be 615 useful to reuse existing admin-groups from traffic-engineering 616 extensions. 618 PE2 619 | +---- P4 620 | / 621 PE1 ---- P1 --------- P2 622 | 10Gb 623 1Gb | 624 | 625 P3 627 Figure 5 629 Example : P1 router is connected to three P routers and two PEs. 631 P1 is configured to protect the P1-P4 link. We assume that given the 632 topology, all neighbors are candidate LFA. We would like to enforce 633 a policy in the network where only a core router may protect against 634 the failure of a core link, and where high capacity links are 635 prefered. 637 In this example, we can use the proposed link coloring by: 639 o Marking PEs links with color RED 640 o Marking 10Gb CORE link with color BLUE 642 o Marking 1Gb CORE link with color YELLOW 644 o Configured the protected interface P1->P4 with : 646 * Include BLUE, preference 200 648 * Include YELLOW, preference 100 650 * Exclude RED 652 Using this, PE links will never be used to protect against P1-P4 link 653 failure and 10Gb link will be be preferred. 655 The main advantage of this solution is that it can easily be 656 duplicated on other interfaces and other nodes without change. A 657 Service Provider has only to define the color system (associate color 658 with a significance), as it is done already for TE affinities or BGP 659 communities. 661 An implementation of link coloring: 663 o SHOULD support multiple include and exclude colors on a single 664 protected interface. 666 o SHOULD provide a level of preference between included colors. 668 o SHOULD support multiple colors configuration on a single 669 protecting interface. 671 5.2.8. Bandwidth 673 As mentionned in previous sections, not taking into account bandwidth 674 of an alternate could lead to congestion during FRR activation. We 675 propose to base the bandwidth criteria on the link speed information 676 for the following reason : 678 o if a router S has a set of X destinations primarly forwarded to N, 679 using per prefix LFA may lead to have a subset of X protected by a 680 neighbor N1, another subset by N2, another subset by Nx ... 682 o S is not aware about traffic flows to each destination and is not 683 able to evaluate how much traffic will be sent to N1,N2, ... Nx in 684 case of FRR activation. 686 Based on this, it is not useful to gather available bandwidth on 687 alternate paths, as the router does not know how much bandwidth it 688 requires for protection. The proposed link speed approach provides a 689 good approximation with a small cost as information is easily 690 available. 692 The bandwidth criteria of the policy framework SHOULD work in two 693 ways : 695 o PRUNE : exclude a LFA if link speed to reach it is lower than the 696 link speed of the primary nexthop interface. 698 o PREFER : prefer a LFA based on his bandwidth to reach it compared 699 to the link speed of the primary nexthop interface. 701 5.2.9. Alternate preference 703 Rather than tagging interface on each node (using link color) to 704 identify alternate node type (as example), it would be helpful if 705 routers could be identified in the IGP. This would permit a grouped 706 processing on multiple nodes. As an implementation need to exclude 707 some specific alternates (see Section 5.2.3), an implementation : 709 o SHOULD be able to give a preference to specific alternate. 711 o SHOULD be able to give a preference to a group of alternate. 713 o SHOULD be able to exclude a group of alternate. 715 A specific alternate may be identified by its interface, IP address 716 or router ID and group of alternates may be identified by a marker 717 (tag). 719 Consider the following network: 721 PE3 722 | 723 | 724 PE2 725 | +---- P4 726 | / 727 PE1 ---- P1 -------- P2 728 | 10Gb 729 1Gb | 730 | 731 P3 733 Figure 6 735 In the example above, each node is configured with a specific tag 736 flooded through the IGP. 738 o PE1,PE3: 200 (non candidate). 740 o PE2: 100 (edge/core). 742 o P1,P2,P3: 50 (core). 744 A simple policy could be configured on P1 to choose the best 745 alternate for P1->P4 based on router function/role as follows : 747 o criteria 1 -> alternate preference: exclude tag 100 and 200. 749 o criteria 2 -> bandwidth. 751 6. Operational aspects 753 6.1. ISIS overload bit on LFA computing node 755 In [RFC5286], Section 3.5, the setting of the overload bit condition 756 in LFA computation is only taken into account for the case where a 757 neighbor has the overload bit set. 759 In addition to RFC 5286 inequality 1 Loop-Free Criterion 760 (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the 761 IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be 762 taken into account. Indeed, if it has the overload bit set, no 763 neighbor will loop back to traffic to itself. 765 6.2. Manual triggering of FRR 767 Service providers often perform manual link shutdown (using router 768 CLI) to perform some network changes/tests. A manual link shutdown 769 may be done at multiple level : physical interface, logical 770 interface, IGP interface, BFD session ... Especially testing or 771 troubleshooting FRR requires to perform the manual shutdown on the 772 remote end of the link as generally a local shutdown would not 773 trigger FRR. 775 To enhance such situation, an implementation SHOULD support 776 triggering/activating LFA Fast Reroute for a given link when a manual 777 shutdown is done on a component that currently supports FRR 778 activation. 780 An implementation MAY also support FRR activation for a specific 781 interface or a specific prefix on a primary next-hop interface and 782 revert without any action on any running component of the node (links 783 or protocols). In this use case, the FRR activation time need to be 784 controlled by a timer in case the operator forgot to revert traffic 785 on primary path. When the timer expires, the traffic is 786 automatically reverted to the primary path. This will make easier 787 tests of fast-reroute path and then revert back to the primary path 788 without causing a global network convergence. 790 For example : 792 o if an implementation supports FRR activation upon BFD session down 793 event, this implementation SHOULD support FRR activation when a 794 manual shutdown is done on the BFD session. But if an 795 implementation does not support FRR activation on BFD session 796 down, there is no need for this implementation to support FRR 797 activation on manual shutdown of BFD session. 799 o if an implementation supports FRR activation on physical link down 800 event (e.g. Rx laser Off detection, or error threshold raised 801 ...), this implementation SHOULD support FRR activation when a 802 manual shutdown at physical interface is done. But if an 803 implementation does not support FRR activation on physical link 804 down event, there is no need for this implementation to support 805 FRR activation on manual physical link shutdown. 807 o A CLI command may permit to switch from primary path to FRR path 808 for testing FRR path for a specific. There is no impact on 809 controlplane, only dataplane of the local node could be changed. 810 A similar command may permit to switch back traffic from FRR path 811 to primary path. 813 6.3. Required local information 815 LFA introduction requires some enhancement in standard routing 816 information provided by implementations. Moreover, due to the non 817 100% coverage, coverage informations is also required. 819 Hence an implementation : 821 o MUST be able to display, for every prefixes, the primary nexthop 822 as well as the alternate nexthop information. 824 o MUST provide coverage information per activation domain of LFA 825 (area, level, topology, instance, virtual router, address family 826 ...). 828 o MUST provide number of protected prefixes as well as non protected 829 prefixes globally. 831 o SHOULD provide number of protected prefixes as well as non 832 protected prefixes per link. 834 o MAY provide number of protected prefixes as well as non protected 835 prefixes per priority if implementation supports prefix-priority 836 insertion in RIB/FIB. 838 o SHOULD provide a reason for chosing an alternate (policy and 839 criteria) and for excluding an alternate. 841 o SHOULD provide the list of non protected prefixes and the reason 842 why they are not protected (no protection required or no alternate 843 available). 845 6.4. Coverage monitoring 847 It is pretty easy to evaluate the coverage of a network in a nominal 848 situation, but topology changes may change the coverage. In some 849 situations, the network may no longer be able to provide the required 850 level of protection. Hence, it becomes very important for service 851 providers to get alerted about changes of coverage. 853 An implementation SHOULD : 855 o provide an alert system if total coverage (for a node) is below a 856 defined threshold or comes back to a normal situation. 858 o provide an alert system if coverage of a specific link is below a 859 defined threshold or comes back to a normal situation. 861 An implementation MAY : 863 o provide an alert system if a specific destination is not protected 864 anymore or when protection comes back up for this destination 866 Although the procedures for providing alerts are beyond the scope of 867 this document, we recommend that implementations consider standard 868 and well used mechanisms like syslog or SNMP traps. 870 6.5. LFA and network planning 872 The operator may choose to run simulations in order to ensure full 873 coverage of a certain type for the whole network or a given subset of 874 the network. This is particularly likely if he operates the network 875 in the sense of the third backbone profiles described in [RFC6571], 876 that is, he seeks to design and engineer the network topology in a 877 way that a certain coverage is always achieved. Obviously a complete 878 and exact simulation of the IP FRR coverage can only be achieved, if 879 the behavior is deterministic and if the algorithm used is available 880 to the simulation tool. Thus, an implementation SHOULD: 882 o Behave deterministic in its selection LFA process. I.e. in the 883 same topology and with the same policy configuration, the 884 implementation MUST always choose the same alternate for a given 885 prefix. 887 o Document its behavior. The implementation SHOULD provide enough 888 documentation of its behavior that allows an implementer of a 889 simulation tool, to foresee the exact choice of the LFA 890 implementation for every prefix in a given topology. This SHOULD 891 take into account all possible policy configuration options. One 892 possible way to document this behavior is to disclose the 893 algorithm used to choose alternates. 895 7. Security Considerations 897 This document does not introduce any change in security consideration 898 compared to [RFC5286]. 900 8. Contributors 902 Significant contributions were made by Pierre Francois, Hannes 903 Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri and Mustapha 904 Aissaoui which the authors would like to acknowledge. 906 9. Acknowledgements 908 10. IANA Considerations 910 This document has no action for IANA. 912 11. References 914 11.1. Normative References 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 920 of Generalized Multi-Protocol Label Switching (GMPLS)", 921 RFC 4203, October 2005. 923 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 924 Intermediate System (IS-IS) Extensions in Support of 925 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 926 4205, October 2005. 928 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 929 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 931 11.2. Informative References 933 [I-D.ietf-isis-node-admin-tag] 934 psarkar@juniper.net, p., Gredler, H., Hegde, S., 935 Litkowski, S., Decraene, B., Li, Z., Aries, E., Rodriguez, 936 R., and H. Raghuveer, "Advertising Per-node Admin Tags in 937 IS-IS", draft-ietf-isis-node-admin-tag-00 (work in 938 progress), December 2014. 940 [I-D.ietf-rtgwg-remote-lfa] 941 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 942 So, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-09 (work 943 in progress), December 2014. 945 [I-D.ietf-rtgwg-rlfa-node-protection] 946 psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, 947 C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node 948 Protection and Manageability", draft-ietf-rtgwg-rlfa-node- 949 protection-01 (work in progress), December 2014. 951 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 952 (TE) Extensions to OSPF Version 2", RFC 3630, September 953 2003. 955 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 956 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 957 RFC 3906, October 2004. 959 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 960 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 961 2005. 963 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 964 Engineering", RFC 5305, October 2008. 966 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 967 5714, January 2010. 969 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 970 Convergence", RFC 5715, January 2010. 972 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 973 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 974 Alternate (LFA) Applicability in Service Provider (SP) 975 Networks", RFC 6571, June 2012. 977 Authors' Addresses 979 Stephane Litkowski 980 Orange 982 Email: stephane.litkowski@orange.com 984 Bruno Decraene 985 Orange 987 Email: bruno.decraene@orange.com 989 Clarence Filsfils 990 Cisco Systems 992 Email: cfilsfil@cisco.com 994 Kamran Raza 995 Cisco Systems 997 Email: skraza@cisco.com 999 Martin Horneffer 1000 Deutsche Telekom 1002 Email: Martin.Horneffer@telekom.de 1004 Pushpasis Sarkar 1005 Juniper Networks 1007 Email: psarkar@juniper.net