idnits 2.17.1 draft-ietf-rtgwg-lfa-manageability-01.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 22, 2014) is 3747 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.litkowski-rtgwg-lfa-rsvpte-cooperation' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3906' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 901, 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-rtgwg-remote-lfa-04 == Outdated reference: A later version (-03) exists of draft-psarkar-isis-node-admin-tag-00 == Outdated reference: A later version (-05) exists of draft-psarkar-rtgwg-rlfa-node-protection-03 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 26, 2014 C. Filsfils 6 K. Raza 7 Cisco Systems 8 M. Horneffer 9 Deutsche Telekom 10 P. Sarkar 11 Juniper Networks 12 January 22, 2014 14 Operational management of Loop Free Alternates 15 draft-ietf-rtgwg-lfa-manageability-01 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 26, 2014. 51 Copyright Notice 53 Copyright (c) 2014 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. Configuration requirements . . . . . . . . . . . . . . . . . 7 76 3.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 7 77 3.2. Policy based LFA selection . . . . . . . . . . . . . . . 8 78 3.2.1. Connected vs remote alternates . . . . . . . . . . . 8 79 3.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 9 80 3.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 9 81 3.2.4. Retrieving alternate path attributes . . . . . . . . 10 82 3.2.5. Details on criterions . . . . . . . . . . . . . . . . 11 83 4. Operational aspects . . . . . . . . . . . . . . . . . . . . . 16 84 4.1. ISIS overload bit on LFA computing node . . . . . . . . . 16 85 4.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 17 86 4.3. Required local information . . . . . . . . . . . . . . . 17 87 4.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 17 88 4.5. Deterministic and documents LFA selection behavior . . . 18 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 9.2. Informative References . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Following the first deployments of Loop Free Alternates (LFA), this 101 document provides feedback to the community about the management of 102 LFA. 104 Section 2 provides real uses cases illustrating some limitations 105 and suboptimal behavior. 107 Section 3 proposes requirements for activation granularity and 108 policy based selection of the alternate. 110 Section 4 express requirements for the operational management of 111 LFA. 113 2. Operational issues with default LFA tie breakers 115 [RFC5286] introduces the notion of tie breakers when selecting the 116 LFA among multiple candidate alternate next-hops. When multiple LFA 117 exist, RFC 5286 has favored the selection of the LFA providing the 118 best coverage of the failure cases. While this is indeed a goal, 119 this is one among multiple and in some deployment this lead to the 120 selection of a suboptimal LFA. The following sections details real 121 use cases of such limitations. 123 Note that the use case of per-prefix LFA is assumed throughout this 124 analysis. 126 2.1. Case 1: Edge router protecting core failures 127 R1 --------- R2 ---------- R3 --------- R4 128 | 1 100 1 | 129 | | 130 | 100 | 100 131 | | 132 | 1 100 1 | 133 R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1 134 | | | | 135 | 5k | 5k | 5k | 5k 136 | | | | 137 +--- n*PEx ---+ +---- PE2 ----+ 138 | 139 | 140 PEy 142 Figure 1 144 Rx routers are core routers using n*10G links. PEs are connected 145 using links with lower bandwidth. 147 In figure 1, let us consider the traffic flowing from PE1 to PEx. 148 The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of 149 link R7-R8. For R8, R4 is not an LFA and the only available LFA is 150 PE2. 152 When the core link R8-R7 fails, R8 switches all traffic destined to 153 all the PEx towards the edge node PE2. Hence an edge node and edge 154 links are used to protect the failure of a core link. Typically, 155 edge links have less capacity than core links and congestion may 156 occur on PE2 links. Note that although PE2 was not directly affected 157 by the failure, its links become congested and its traffic will 158 suffer from the congestion. 160 In summary, in case of failure, the impact on customer traffic is: 162 o From PE2 point of view : 164 * without LFA: no impact 166 * with LFA: traffic is partially dropped (but possibly 167 prioritized by a QoS mechanism). It must be highlighted that 168 in such situation, traffic not affected by the failure may be 169 affected by the congestion. 171 o From R8 point of view: 173 * without LFA: traffic is totally dropped until convergence 174 occurs. 176 * with LFA: traffic is partially dropped (but possibly 177 prioritized by a QoS mechanism). 179 Besides the congestion aspects of using an Edge router as an 180 alternate to protect a core failure, a service provider may consider 181 this as a bad routing design and would like to prevent it. 183 2.2. Case 2: Edge router choosen to protect core failures while core 184 LFA exists 186 R1 --------- R2 ------------ R3 --------- R4 187 | 1 100 | 1 | 188 | | | 189 | 100 | 30 | 30 190 | | | 191 | 1 50 50 | 10 | 192 R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1 193 | | \ | 194 | 5000 | 5000 \ 5000 | 5000 195 | | \ | 196 +--- n*PEx --+ +----- PE2 ----+ 197 | 198 | 199 PEy 201 Figure 2 203 Rx routers are core routers meshed with n*10G links. PEs are meshed 204 using links with lower bandwidth. 206 In the figure 2, let us consider the traffic coming from PE1 to PEx. 207 Nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of the 208 link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a node- 209 protecting LFA. PE2 is chosen as best LFA due to its better 210 protection type. Just like in case 1, this may lead to congestion on 211 PE2 links upon LFA activation. 213 2.3. Case 3: suboptimal core alternate choice 214 +--- PE3 --+ 215 / \ 216 1000 / \ 1000 217 / \ 218 +----- R1 ---------------- R2 ----+ 219 | | 500 | | 220 | 10 | | | 10 221 | | | | 222 R5 | 10 | 10 R7 223 | | | | 224 | 10 | | | 10 225 | | 500 | | 226 +---- R3 ---------------- R4 -----+ 227 \ / 228 \ / 229 \ / 230 +--- PE1 ---+ 232 Figure 3 234 Rx routers are core routers. R1-R2 and R3-R4 links are 1G links. 235 All others inter Rx links are 10G links. 237 In the figure above, let us consider the failure of link R1-R3. For 238 destination PE3, R3 has two possible alternates: 240 o R4, which is node-protecting 242 o R5, which is link-protecting 244 R4 is chosen as best LFA due to its better protection type. However, 245 it may not be desirable to use R4 for bandwidth capacity reason. A 246 service provider may prefer to use high bandwidth links as prefered 247 LFA. In this example, prefering shortest path over protection type 248 may achieve the expected behavior, but in cases where metric are not 249 reflecting bandwidth, it would not work and some other criteria would 250 need to be involved when selecting the best LFA. 252 2.4. Case 4: ISIS overload bit on LFA computing node 253 P1 P2 254 | \ / | 255 50 | 50 \/ 50 | 50 256 | /\ | 257 PE1-+ +-- PE2 258 \ / 259 45 \ / 45 260 -PE3-+ 261 (OL set) 263 Figure 4 265 In the figure above, PE3 has its overload bit set (permanently, for 266 design reason) and wants to protect traffic using LFA for destination 267 PE2. 269 On PE3, the loopfree condition is not satisified : 100 !< 45 + 45. 270 PE1 is thus not considered as an LFA. However thanks to the overload 271 bit set on PE3, we know that PE1 is loopfree so PE1 is an LFA to 272 reach PE2. 274 In case of overload condition set on a node, LFA behavior must be 275 clarified. 277 3. Configuration requirements 279 Controlling best alternate and LFA activation granularity is a 280 requirement for Service Providers. This section defines 281 configuration requirements for LFA. 283 3.1. LFA enabling/disabling scope 285 The granularity of LFA activation should be controlled (as alternate 286 nexthop consume memory in forwarding plane). 288 An implementation of LFA SHOULD allow its activation with the 289 following criteria: 291 o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast, 292 LDP IPv6 unicast ... 294 o Per routing context : VRF, virtual/logical router, global routing 295 table, ... 297 o Per interface 299 o Per protocol instance, topology, area 300 o Per prefixes: prefix protection SHOULD have a better priority 301 compared to interface protection. This means that if a specific 302 prefix must be protected due to a configuration request, LFA must 303 be computed and installed for this prefix even if the primary 304 outgoing interface is not configured for protection. 306 3.2. Policy based LFA selection 308 When multiple alternates exist, LFA selection algorithm is based on 309 tie breakers. Current tie breakers do not provide sufficient control 310 on how the best alternate is chosen. This document proposes an 311 enhanced tie breaker allowing service providers to manage all 312 specific cases: 314 1. An implementation of LFA SHOULD support policy-based decision for 315 determining the best LFA. 317 2. Policy based decision SHOULD be based on multiple criterions, 318 with each criteria having a level of preference. 320 3. If the defined policy does not permit to determine a unique best 321 LFA, an implementation SHOULD pick only one based on its own 322 decision, as a default behavior. An implementation SHOULD also 323 support election of multiple LFAs, for loadbalancing purposes. 325 4. Policy SHOULD be applicable to a protected interface or to a 326 specific set of destinations. In case of application on the 327 protected interface, all destinations primarily routed on this 328 interface SHOULD use the interface policy. 330 5. It is an implementation choice to reevaluate policy dynamically 331 or not (in case of policy change). If a dynamic approach is 332 chosen, the implementation SHOULD recompute the best LFAs and 333 reinstall them in FIB, without service disruption. If a non- 334 dynamic approach is chosen, the policy would be taken into 335 account upon the next IGP event. In this case, the 336 implementation SHOULD support a command to manually force the 337 recomputation/reinstallation of LFAs. 339 3.2.1. Connected vs remote alternates 341 In addition to direct LFAs, tunnels (e.g. IP, LDP or RSVP-TE) to 342 distant routers may be used to complement LFA coverage (tunnel tail 343 used as virtual neighbor). When a router has multiple alternate 344 candidates for a specific destination, it may have connected 345 alternates and remote alternates reachable via a tunnel. Connected 346 alternates may not always provide an optimal routing path and it may 347 be preferable to select a remote alternate over a connected 348 alternate. The usage of tunnels to extend LFA coverage is described 349 in [I-D.ietf-rtgwg-remote-lfa]. 351 In figure 1, there is no core alternate for R8 to reach PEs located 352 behind R6, so R8 is using PE2 as alternate, which may generate 353 congestion when FRR is activated. Instead, we could have a remote 354 core alternate for R8 to protect PEs destinations. For example, a 355 tunnel from R8 to R3 would ensure LFA protection without using an 356 edge router to protect a core router. 358 When selecting the best alternate, the selection algorithm MUST 359 consider all available alternates (connected or tunnel). Especially, 360 computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD to be 361 performed before best alternate selection. 363 3.2.2. Mandatory criteria 365 An implementation of LFA MUST support the following criteria: 367 o Non candidate link: A link marked as "non candidate" will never be 368 used as LFA. 370 o A primary nexthop being protected by another primary nexthop of 371 the same prefix (ECMP case). 373 o Type of protection provided by the alternate: link protection, 374 node protection. In case of node protection preference, an 375 implementation SHOULD support fallback to link protection if node 376 protection is not available. 378 o Shortest path: lowest IGP metric used to reach the destination. 380 o SRLG (as defined in [RFC5286] Section 3). 382 3.2.3. Enhanced criteria 384 An implementation of LFA SHOULD support the following enhanced 385 criteria: 387 o Downstreamness of a neighbor : preference of a downstream path 388 over a non downstream path SHOULD be configurable. 390 o Link coloring with : include, exclude and preference based system. 392 o Link Bandwidth. 394 o Neighbor preference. 396 3.2.4. Retrieving alternate path attributes 398 The policy to select the best alternate evaluate multiple criterions 399 (e.g. metric, SRLG, link colors ...) which first need to be computed 400 for each alternate.. In order to compare the different alternate 401 path, a router must retrieve the attributes of each alternate path. 402 The alternate path is composed of two distinct parts : PLR to 403 alternate and alternate to destination. 405 3.2.4.1. Connected alternate 407 For alternate path using a connected alternate : 409 o attributes from PLR to alternate path are retrieved from the 410 interface connected to the alternate. 412 o attributes from alternate to destination path are retrieved from 413 SPF rooted at the alternate. As the alternate is a connected 414 alternate, the SPF has already been computed to find the 415 alternate, so there is no need of additional computation. 417 3.2.4.2. Remote alternate 419 For alternate path using a remote alternate (tunnel) : 421 o attributes from the PLR to alternate path are retrieved using the 422 PLR's primary SPF if P space is used or using the neighbor's SPF 423 if extended P space is used, combined with the attributes of the 424 link(s) to reach that neighbor. In both cases, no additional SPF 425 is required. 427 o attributes from alternate to destination path are retrieved from 428 SPF rooted at the remote alternate. An additional forward SPF is 429 required for each remote alternate as indicated in 430 [I-D.psarkar-rtgwg-rlfa-node-protection] section 3.2.. 432 The number of remote alternates may be very high, simulations shown 433 that hundred's of PQs may exist for a single interface being 434 protected. Running a forward SPF for every PQ-node in the network is 435 not scalable. 437 To handle this situation, it is needed to limit the number of remote 438 alternates to be evaluated to a finite number before collecting 439 alternate path attributes and running the policy evaluation. [I-D 440 .psarkar-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to 441 reduce the number of PQ to be evaluated. 443 Link Remote Remote 444 alternate alternate alternate 445 ------------- ------------------ ------------- 446 Alternates | LFA | | rLFA (PQs) | | Static | 447 sources | | | | | tunnels | 448 ------------- ------------------ ------------- 449 | | | 450 | | | 451 | ---------------------- | 452 | | Prune some PQs | | 453 | | (sorting strategy) | | 454 | ---------------------- | 455 | | | 456 | | | 457 ------------------------------------------------ 458 | Collect alternate attributes | 459 ------------------------------------------------ 460 | 461 | 462 ------------------------- 463 | Evaluate policy | 464 ------------------------- 465 | 466 | 467 Best alternates 469 3.2.5. Details on criterions 471 3.2.5.1. LFA and ECMP 473 10 474 PE2 - PE3 475 | | 476 50 | 5 | 50 477 P1----P2 478 \\ // 479 50 \\ // 50 480 PE1 482 Figure 5 484 Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are 485 L3 and L4 487 In the figure above, primary path from PE1 to PE2 is through P1 using 488 ECMP on two parallel links L1 and L2. In case of standard ECMP 489 behavior, if L1 is failing, postconvergence nexthop would become L2 490 and there would be no longer ECMP. If LFA is activated, as stated in 492 [RFC5286] Section 3.4., "alternate next-hops may themselves also be 493 primary next-hops, but need not be" and "alternate next-hops should 494 maximize the coverage of the failure cases". In this scenario there 495 is no alternate providing node protection, LFA will so prefer L2 as 496 alternate to protect L1 which makes sense compared to postconvergence 497 behavior. 499 Considering a different scenario using figure 5, where L1 and L2 are 500 configured as a layer 3 bundle using a local feature, as well as L3/ 501 L4 being a second layer 3 bundle. Layer 3 bundles are configured as 502 if a link in the bundle is failing, the traffic must be rerouted out 503 of the bundle. Layer 3 bundles are generally introduced to increase 504 bandwidth between nodes. In nominal situation, ECMP is still 505 available from PE1 to PE2, but if L1 is failing, postconvergence 506 nexthop would become ECMP on L3 and L4. In this case, LFA behavior 507 SHOULD be adapted in order to reflect the bandwidth requirement. 509 We would expect the following FIB entry on PE1 : 511 On PE1 : PE2 +--> ECMP -> L1 512 | | 513 | +----> L2 514 | 515 +--> LFA(ECMP) -> L3 516 | 517 +---------> L4 519 If L1 or L2 is failing, traffic must be switched on the LFA ECMP 520 bundle rather than using the other primary nexthop. 522 As mentioned in [RFC5286] Section 3.4., protecting a link within an 523 ECMP by another primary nexthop is not a MUST. Moreover, we already 524 presented in this document, that maximizing the coverage of the 525 failure case may not be the right approach and policy based choice of 526 alternate may be preferred. 528 An implementation SHOULD permit to prefer a primary nexthop by 529 another primary nexthop with the possibility to deactivate this 530 criteria. An implementation SHOULD permit to use an ECMP bundle as a 531 LFA. 533 3.2.5.2. SRLG 535 [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode 536 SRLGs ([RFC4205] and [RFC4203]). The section is also describing the 537 algorithm to compute SRLG protection. 539 When SRLG protection is computed, and implementation SHOULD permit to 540 : 542 o Exclude alternates violating SRLG. 544 o Maintain a preference system between alternates based on number of 545 SRLG violations : more violations = less preference. 547 When applying SRLG criteria, the SRLG violation check SHOULD be 548 performed on source to alternate as well as alternate to destination 549 paths. In the case of remote LFA, PQ to destination path attributes 550 would be retrieved from SPT rooted at PQ. 552 3.2.5.3. Link coloring 554 Link coloring is a powerful system to control the choice of 555 alternates. Protecting interfaces are tagged with colors. Protected 556 interfaces are configured to include some colors with a preference 557 level, and exclude others. 559 Link color information SHOULD be signalled in the IGP. How 560 signalling is done is out of scope of the document but it may be 561 useful to reuse existing admin-groups from traffic-engineering 562 extensions. 564 PE2 565 | +---- P4 566 | / 567 PE1 ---- P1 --------- P2 568 | 10Gb 569 1Gb | 570 | 571 P3 573 Figure 5 575 Example : P1 router is connected to three P routers and two PEs. 577 P1 is configured to protect the P1-P4 link. We assume that given the 578 topology, all neighbors are candidate LFA. We would like to enforce 579 a policy in the network where only a core router may protect against 580 the failure of a core link, and where high capacity links are 581 prefered. 583 In this example, we can use the proposed link coloring by: 585 o Marking PEs links with color RED 586 o Marking 10Gb CORE link with color BLUE 588 o Marking 1Gb CORE link with color YELLOW 590 o Configured the protected interface P1->P4 with : 592 * Include BLUE, preference 200 594 * Include YELLOW, preference 100 596 * Exclude RED 598 Using this, PE links will never be used to protect against P1-P4 link 599 failure and 10Gb link will be be preferred. 601 The main advantage of this solution is that it can easily be 602 duplicated on other interfaces and other nodes without change. A 603 Service Provider has only to define the color system (associate color 604 with a significance), as it is done already for TE affinities or BGP 605 communities. 607 An implementation of link coloring: 609 o SHOULD support multiple include and exclude colors on a single 610 protected interface. 612 o SHOULD provide a level of preference between included colors. 614 o SHOULD support multiple colors configuration on a single 615 protecting interface. 617 3.2.5.4. Bandwidth 619 As mentionned in previous sections, not taking into account bandwidth 620 of an alternate could lead to congestion during FRR activation. We 621 propose to base the bandwidth criteria on the link speed information 622 for the following reason : 624 o if a router S has a set of X destinations primarly forwarded to N, 625 using per prefix LFA may lead to have a subset of X protected by a 626 neighbor N1, another subset by N2, another subset by Nx ... 628 o S is not aware about traffic flows to each destination and is not 629 able to evaluate how much traffic will be sent to N1,N2, ... Nx in 630 case of FRR activation. 632 Based on this, it is not useful to gather available bandwidth on 633 alternate paths, as the router does not know how much bandwidth it 634 requires for protection. The proposed link speed approach provides a 635 good approximation with a small cost as information is easily 636 available. 638 The bandwidth criteria of the policy framework SHOULD work in two 639 ways : 641 o PRUNE : exclude a LFA if link speed to reach it is lower than the 642 link speed of the primary nexthop interface. 644 o PREFER : prefer a LFA based on his bandwidth to reach it compared 645 to the link speed of the primary nexthop interface. 647 3.2.5.5. Neighbor preference 649 Rather than tagging interface on each node (using link color) to 650 identify neighbor node type (as example), it would be helpful if 651 routers could be identified in the IGP. This would permit a grouped 652 processing on multiple nodes. [I-D.psarkar-isis-node-admin-tag] 653 proposes a tagging mechanism for ISIS nodes that may help the node 654 identification. As an implementation need to exclude some specific 655 neighbors (see Section 3.2.3), an implementation : 657 o SHOULD be able to give a preference to specific neighbor. 659 o SHOULD be able to give a preference to a group of neighbor. 661 o SHOULD be able to exclude a group of neighbor. 663 A specific neighbor may be identified by its interface or IP address 664 and group of neighbors may be identified by a marker like SUB-TLV1 in 665 TLV135. As multiple prefixes may be present in TLVs 135, an 666 heuristic is required to choose the appropriate one that will 667 identify the neighbor and will transport the tag associated with the 668 neighbor preference. 670 We propose the following algorithm to select the prefix : 672 1. Select the prefix in TLV#135 that is equal to TLV#134 value 673 (Router ID) and prefix length is 32. 675 2. Select the prefix in TLV#135 that is equal to TLV#132 value (IP 676 Addresses) and prefix length is 32, it must be noted that TLV#132 677 may transport multiple addresses and so multiple matches may 678 happen. 680 3. If multiple prefixes are matching TLV#132 values, choose the 681 highest one. 683 Consider the following network: 685 PE3 686 | 687 | 688 PE2 689 | +---- P4 690 | / 691 PE1 ---- P1 -------- P2 692 | 10Gb 693 1Gb | 694 | 695 P3 697 Figure 6 699 In the example above, each node is configured with a specific tag 700 flooded through the IGP. 702 o PE1,PE3: 200 (non candidate). 704 o PE2: 100 (edge/core). 706 o P1,P2,P3: 50 (core). 708 A simple policy could be configured on P1 to choose the best 709 alternate for P1->P4 based on router function/role as follows : 711 o criteria 1 -> neighbor preference: exclude tag 100 and 200. 713 o criteria 2 -> bandwidth. 715 4. Operational aspects 717 4.1. ISIS overload bit on LFA computing node 719 In [RFC5286], Section 3.5, the setting of the overload bit condition 720 in LFA computation is only taken into account for the case where a 721 neighbor has the overload bit set. 723 In addition to RFC 5286 inequality 1 Loop-Free Criterion 724 (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the 725 IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be 726 taken into account. Indeed, if it has the overload bit set, no 727 neighbor will loop back to traffic to itself. 729 4.2. Manual triggering of FRR 731 Service providers often perform manual link shutdown (using router 732 CLI) to perform some network changes/tests. Especially testing or 733 troubleshooting FRR requires to perform the manual shutdown on the 734 remote end of the link as generally a local shutdown would not 735 trigger FRR. To enhance such situation, an implementation SHOULD 736 support triggering/activating LFA Fast Reroute for a given link when 737 a manual shutdown is done. 739 4.3. Required local information 741 LFA introduction requires some enhancement in standard routing 742 information provided by implementations. Moreover, due to the non 743 100% coverage, coverage informations is also required. 745 Hence an implementation : 747 o MUST be able to display, for every prefixes, the primary nexthop 748 as well as the alternate nexthop information. 750 o MUST provide coverage information per activation domain of LFA 751 (area, level, topology, instance, virtual router, address family 752 ...). 754 o MUST provide number of protected prefixes as well as non protected 755 prefixes globally. 757 o SHOULD provide number of protected prefixes as well as non 758 protected prefixes per link. 760 o MAY provide number of protected prefixes as well as non protected 761 prefixes per priority if implementation supports prefix-priority 762 insertion in RIB/FIB. 764 o SHOULD provide a reason for chosing an alternate (policy and 765 criteria) and for excluding an alternate. 767 o SHOULD provide the list of non protected prefixes and the reason 768 why they are not protected (no protection required or no alternate 769 available). 771 4.4. Coverage monitoring 773 It is pretty easy to evaluate the coverage of a network in a nominal 774 situation, but topology changes may change the coverage. In some 775 situations, the network may no longer be able to provide the required 776 level of protection. Hence, it becomes very important for service 777 providers to get alerted about changes of coverage. 779 An implementation SHOULD : 781 o provide an alert system if total coverage (for a node) is below a 782 defined threshold or comes back to a normal situation. 784 o provide an alert system if coverage of a specific link is below a 785 defined threshold or comes back to a normal situation. 787 An implementation MAY : 789 o provide an alert system if a specific destination is not protected 790 anymore or when protection comes back up for this destination 792 Although the procedures for providing alerts are beyond the scope of 793 this document, we recommend that implementations consider standard 794 and well used mechanisms like syslog or SNMP traps. 796 4.5. Deterministic and documents LFA selection behavior 798 The operator may choose to run simulations in order to ensure full 799 coverage of a certain type for the whole network or a given subset of 800 the network. This is particularly likely if he operates the network 801 in the sense of the third backbone profiles described in [RFC6571], 802 that is, he seeks to design and engineer the network topology in a 803 way that a certain coverage is always achieved. Obviously a complete 804 and exact simulation of the IP FRR coverage can only be achieved, if 805 the behavior is deterministic and if the algorithm used is available 806 to the simulation tool. Thus, an implementation SHOULD: 808 o Behave deterministic in its selection LFA process. I.e. in the 809 same topology and with the same policy configuration, the 810 implementation MUST always choose the same alternate for a given 811 prefix. 813 o Document its behavior. The implementation SHOULD provide enough 814 documentation of its behavior that allows an implementer of a 815 simulation tool, to foresee the exact choice of the LFA 816 implementation for every prefix in a given topology. This SHOULD 817 take into account all possible policy configuration options. One 818 possible way to document this behavior is to disclose the 819 algorithm used to choose alternates. 821 5. Security Considerations 823 This document does not introduce any change in security consideration 824 compared to [RFC5286]. 826 6. Contributors 828 Significant contributions were made by Pierre Francois, Hannes 829 Gredler, Chris Bowers, Jeff Tantsura and Mustapha Aissaoui which the 830 authors would like to acknowledge. 832 7. Acknowledgements 834 8. IANA Considerations 836 This document has no action for IANA. 838 9. References 840 9.1. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 846 of Generalized Multi-Protocol Label Switching (GMPLS)", 847 RFC 4203, October 2005. 849 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 850 Intermediate System (IS-IS) Extensions in Support of 851 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 852 4205, October 2005. 854 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 855 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 857 9.2. Informative References 859 [I-D.ietf-rtgwg-remote-lfa] 860 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 861 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-04 862 (work in progress), November 2013. 864 [I-D.litkowski-rtgwg-lfa-rsvpte-cooperation] 865 Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, 866 "Interactions between LFA and RSVP-TE", draft-litkowski- 867 rtgwg-lfa-rsvpte-cooperation-02 (work in progress), August 868 2013. 870 [I-D.psarkar-isis-node-admin-tag] 871 psarkar@juniper.net, p., Gredler, H., Hegde, S., 872 Raghuveer, H., Litkowski, S., and B. Decraene, 873 "Advertising Per-node Admin Tags in IS-IS", draft-psarkar- 874 isis-node-admin-tag-00 (work in progress), October 2013. 876 [I-D.psarkar-rtgwg-rlfa-node-protection] 877 psarkar@juniper.net, p., Gredler, H., Hegde, S., 878 Raghuveer, H., cbowers@juniper.net, c., and S. Litkowski, 879 "Remote-LFA Node Protection and Manageability", draft- 880 psarkar-rtgwg-rlfa-node-protection-03 (work in progress), 881 December 2013. 883 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 884 (TE) Extensions to OSPF Version 2", RFC 3630, September 885 2003. 887 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 888 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 889 RFC 3906, October 2004. 891 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 892 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 893 2005. 895 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 896 Engineering", RFC 5305, October 2008. 898 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 899 5714, January 2010. 901 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 902 Convergence", RFC 5715, January 2010. 904 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 905 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 906 Alternate (LFA) Applicability in Service Provider (SP) 907 Networks", RFC 6571, June 2012. 909 Authors' Addresses 911 Stephane Litkowski 912 Orange 914 Email: stephane.litkowski@orange.com 915 Bruno Decraene 916 Orange 918 Email: bruno.decraene@orange.com 920 Clarence Filsfils 921 Cisco Systems 923 Email: cfilsfil@cisco.com 925 Kamran Raza 926 Cisco Systems 928 Email: skraza@cisco.com 930 Martin Horneffer 931 Deutsche Telekom 933 Email: Martin.Horneffer@telekom.de 935 Pushpasis Sarkar 936 Juniper Networks 938 Email: psarkar@juniper.net