idnits 2.17.00 (12 Aug 2021) /tmp/idnits25265/draft-litkowski-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 (February 18, 2013) is 3372 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: 'RFC3630' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC3906' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC6571' is defined on line 704, but no explicit reference was found in the text == Outdated reference: draft-ietf-rtgwg-remote-lfa has been published as RFC 7490 -- No information found for draft-litkowski-rtgwg-lfa-rsvpte-cooperation - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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: August 22, 2013 C. Filsfils 6 K. Raza 7 Cisco Systems 8 February 18, 2013 10 Operational management of Loop Free Alternates 11 draft-litkowski-rtgwg-lfa-manageability-01 13 Abstract 15 Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast 16 ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic 17 (and MPLS LDP traffic by extension). Following first deployment 18 experiences, this document provides operational feedback on LFA, 19 highlights some limitations, and proposes a set of refinements to 20 address those limitations. It also proposes required management 21 specifications. 23 This proposal is also applicable to remote LFA solution. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 22, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Operational issues with default LFA tie breakers . . . . . . . 3 66 2.1. Case 1: Edge router protecting core failures . . . . . . . 4 67 2.2. Case 2: Edge router choosen to protect core failures 68 while core LFA exists . . . . . . . . . . . . . . . . . . 5 69 2.3. Case 3: suboptimal core alternate choice . . . . . . . . . 6 70 2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 7 71 3. Configuration requirements . . . . . . . . . . . . . . . . . . 7 72 3.1. LFA enabling/disabling scope . . . . . . . . . . . . . . . 7 73 3.2. Policy based LFA selection . . . . . . . . . . . . . . . . 8 74 3.2.1. Mandatory criteria . . . . . . . . . . . . . . . . . . 8 75 3.2.2. Enhanced criteria . . . . . . . . . . . . . . . . . . 9 76 4. Operational aspects . . . . . . . . . . . . . . . . . . . . . 13 77 4.1. ISIS overload bit on LFA computing node . . . . . . . . . 13 78 4.2. Manual triggering of FRR . . . . . . . . . . . . . . . . . 14 79 4.3. Required local information . . . . . . . . . . . . . . . . 14 80 4.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 15 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Following the first deployments of Loop Free Alternates (LFA), this 93 document provides feedback to the community about the management of 94 LFA. 96 Section 2 provides real uses cases illustrating some limitations 97 and suboptimal behavior. 99 Section 3 proposes requirements for activation granularity and 100 policy based selection of the alternate. 102 Section 4 express requirements for the operational management of 103 LFA. 105 2. Operational issues with default LFA tie breakers 107 [RFC5286] introduces the notion of tie breakers when selecting the 108 LFA among multiple candidate alternate next-hops. When multiple LFA 109 exist, RFC 5286 has favored the selection of the LFA providing the 110 best coverage of the failure cases. While this is indeed a goal, 111 this is one among multiple and in some deployment this lead to the 112 selection of a suboptimal LFA. The following sections details real 113 use cases of such limitations. 115 Note that the use case of per-prefix LFA is assumed throughout this 116 analysis. 118 2.1. Case 1: Edge router protecting core failures 120 R1 --------- R2 ---------- R3 --------- R4 121 | 1 100 1 | 122 | | 123 | 100 | 100 124 | | 125 | 1 100 1 | 126 R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1 127 | | | | 128 | 5k | 5k | 5k | 5k 129 | | | | 130 +--- n*PEx ---+ +---- PE2 ----+ 131 | 132 | 133 PEy 135 Figure 1 137 Rx routers are core routers using n*10G links. PEs are connected 138 using links with lower bandwidth. 140 In figure 1, let us consider the traffic flowing from PE1 to PEx. 141 The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of 142 link R7-R8. For R8, R4 is not an LFA and the only available LFA is 143 PE2. 145 When the core link R8-R7 fails, R8 switches all traffic destined to 146 all the PEx towards the edge node PE2. Hence an edge node and edge 147 links are used to protect the failure of a core link. Typically, 148 edge links have less capacity than core links and congestion may 149 occur on PE2 links. Note that although PE2 was not directly affected 150 by the failure, its links become congested and its traffic will 151 suffer from the congestion. 153 In summary, in case of failure, the impact on customer traffic is: 155 o From PE2 point of view : 157 * without LFA: no impact 159 * with LFA: traffic is partially dropped (but possibly 160 prioritized by a QoS mechanism). It must be highlighted that 161 in such situation, traffic not affected by the failure may be 162 affected by the congestion. 164 o From R8 point of view: 166 * without LFA: traffic is totally dropped until convergence 167 occurs. 169 * with LFA: traffic is partially dropped (but possibly 170 prioritized by a QoS mechanism). 172 Besides the congestion aspects of using an Edge router as an 173 alternate to protect a core failure, a service provider may consider 174 this as a bad routing design and would like to prevent it. 176 2.2. Case 2: Edge router choosen to protect core failures while core 177 LFA exists 179 R1 --------- R2 ------------ R3 --------- R4 180 | 1 100 | 1 | 181 | | | 182 | 100 | 30 | 30 183 | | | 184 | 1 50 50 | 10 | 185 R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1 186 | | \ | 187 | 5000 | 5000 \ 5000 | 5000 188 | | \ | 189 +--- n*PEx --+ +----- PE2 ----+ 190 | 191 | 192 PEy 194 Figure 2 196 Rx routers are core routers meshed with n*10G links. PEs are meshed 197 using links with lower bandwidth. 199 In the figure 2, let us consider the traffic coming from PE1 to PEx. 200 Nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of the 201 link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a node- 202 protecting LFA. PE2 is chosen as best LFA due to its better 203 protection type. Just like in case 1, this may lead to congestion on 204 PE2 links upon LFA activation. 206 2.3. Case 3: suboptimal core alternate choice 208 +--- PE3 --+ 209 / \ 210 1000 / \ 1000 211 / \ 212 +----- R1 ---------------- R2 ----+ 213 | | 500 | | 214 | 10 | | | 10 215 | | | | 216 R5 | 10 | 10 R7 217 | | | | 218 | 10 | | | 10 219 | | 500 | | 220 +---- R3 ---------------- R4 -----+ 221 \ / 222 \ / 223 \ / 224 +--- PE1 ---+ 226 Figure 3 228 Rx routers are core routers. R1-R2 and R3-R4 links are 1G links. 229 All others inter Rx links are 10G links. 231 In the figure above, let us consider the failure of link R1-R3. For 232 destination PE3, R3 has two possible alternates: 234 o R4, which is node-protecting 236 o R5, which is link-protecting 238 R4 is chosen as best LFA due to its better protection type. However, 239 it may not be desirable to use R4 for bandwidth capacity reason. A 240 service provider may prefer to use high bandwidth links as prefered 241 LFA. In this example, prefering shortest path over protection type 242 may achieve the expected behavior, but in cases where metric are not 243 reflecting bandwidth, it would not work and some other criteria would 244 need to be involved when selecting the best LFA. 246 2.4. Case 4: ISIS overload bit on LFA computing node 248 P1 P2 249 | \ / | 250 50 | 50 \/ 50 | 50 251 | /\ | 252 PE1-+ +-- PE2 253 \ / 254 45 \ / 45 255 -PE3-+ 256 (OL set) 258 Figure 4 260 In the figure above, PE3 has its overload bit set (permanently, for 261 design reason) and wants to protect traffic using LFA for destination 262 PE2. 264 On PE3, the loopfree condition is not satisified : 100 !< 45 + 45. 265 PE1 is thus not considered as an LFA. However thanks to the overload 266 bit set on PE3, we know that PE1 is loopfree so PE1 is an LFA to 267 reach PE2. 269 In case of overload condition set on a node, LFA behavior must be 270 clarified. 272 3. Configuration requirements 274 Controlling best alternate and LFA activation granularity is a 275 requirement for Service Providers. This section defines 276 configuration requirements for LFA. 278 3.1. LFA enabling/disabling scope 280 The granularity of LFA activation should be controlled (as alternate 281 nexthop consume memory in forwarding plane). 283 An implementation of LFA SHOULD allow its activation with the 284 following criteria: 286 o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast, 287 LDP IPv6 unicast ... 289 o Per routing context : VRF, virtual/logical router, global routing 290 table, ... 292 o Per interface 294 o Per protocol instance, topology, area 296 o Per prefixes: prefix protection SHOULD have a better priority 297 compared to interface protection. This means that if a specific 298 prefix must be protected due to a configuration request, LFA must 299 be computed and installed for this prefix even if the primary 300 outgoing interface is not configured for protection. 302 3.2. Policy based LFA selection 304 When multiple alternates exist, LFA selection algorithm is based on 305 tie breakers. Current tie breakers do not provide sufficient control 306 on how the best alternate is chosen. This document proposes an 307 enhanced tie breaker allowing service providers to manage all 308 specific cases: 310 1. An implementation of LFA SHOULD support policy-based decision for 311 determining the best LFA. 313 2. Policy based decision SHOULD be based on multiple criterions, 314 with each criteria having a level of preference. 316 3. If the defined policy does not permit to determine a unique best 317 LFA, an implementation SHOULD pick only one based on its own 318 decision, as a default behavior. An implementation SHOULD also 319 support election of multiple LFAs, for loadbalancing purposes. 321 4. Policy SHOULD be applicable to a protected interface or to a 322 specific set of destinations. In case of application on the 323 protected interface, all destinations primarily routed on this 324 interface SHOULD use the interface policy. 326 5. It is an implementation choice to reevaluate policy dynamically 327 or not (in case of policy change). If a dynamic approach is 328 chosen, the implementation SHOULD recompute the best LFAs and 329 reinstall them in FIB, without service disruption. If a non- 330 dynamic approach is chosen, the policy would be taken into 331 account upon the next IGP event. In this case, the 332 implementation SHOULD support a command to manually force the 333 recomputation/reinstallation of LFAs. 335 3.2.1. Mandatory criteria 337 An implementation of LFA MUST support the following criteria: 339 o Non candidate link: A link marked as "non candidate" will never be 340 used as LFA. 342 o A primary nexthop being protected by another primary nexthop of 343 the same prefix (ECMP case). 345 o Type of protection provided by the alternate: link protection, 346 node protection. In case of node protection preference, an 347 implementation SHOULD support fallback to link protection if node 348 protection is not available. 350 o Shortest path: lowest IGP metric used to reach the destination. 352 o SRLG (as defined in [RFC5286] Section 3). 354 3.2.2. Enhanced criteria 356 An implementation of LFA SHOULD support the following enhanced 357 criteria: 359 o Downstreamness of a neighbor : preference of a downstream path 360 over a non downstream path SHOULD be configurable. 362 o Link coloring with : include, exclude and preference based system. 364 o Link Bandwidth. 366 o Neighbor preference. 368 o Neighbor type: link or tunnel alternate. This means that user may 369 change preference between link alternate or tunnel alternate (link 370 prefered over tunnel, or considered as equal). 372 3.2.2.1. Link coloring 374 Link coloring is a powerful system to control the choice of 375 alternates. Protecting interfaces are tagged with colors. Protected 376 interfaces are configured to include some colors with a preference 377 level, and exclude others. 379 Link color information SHOULD be signalled in the IGP. How 380 signalling is done is out of scope of the document but it may be 381 useful to reuse existing admin-groups from traffic-engineering 382 extensions. 384 PE2 385 | +---- P4 386 | / 387 PE1 ---- P1 --------- P2 388 | 10Gb 389 1Gb | 390 | 391 P3 393 Figure 5 395 Example : P1 router is connected to three P routers and two PEs. 397 P1 is configured to protect the P1-P4 link. We assume that given the 398 topology, all neighbors are candidate LFA. We would like to enforce 399 a policy in the network where only a core router may protect against 400 the failure of a core link, and where high capacity links are 401 prefered. 403 In this example, we can use the proposed link coloring by: 405 o Marking PEs links with color RED 407 o Marking 10Gb CORE link with color BLUE 409 o Marking 1Gb CORE link with color YELLOW 411 o Configured the protected interface P1->P4 with : 413 * Include BLUE, preference 200 415 * Include YELLOW, preference 100 417 * Exclude RED 419 Using this, PE links will never be used to protect against P1-P4 link 420 failure and 10Gb link will be be preferred. 422 The main advantage of this solution is that it can easily be 423 duplicated on other interfaces and other nodes without change. A 424 Service Provider has only to define the color system (associate color 425 with a significance), as it is done already for TE affinities or BGP 426 communities. 428 An implementation of link coloring: 430 o SHOULD support multiple include and exclude colors on a single 431 protected interface. 433 o SHOULD provide a level of preference between included colors. 435 o SHOULD support multiple colors configuration on a single 436 protecting interface. 438 3.2.2.2. Bandwidth 440 As mentionned in previous sections, not taking into account bandwidth 441 of an alternate could lead to congestion during FRR activation. We 442 propose to base the bandwidth criteria on the link speed information 443 for the following reason : 445 o if a router S has a set of X destinations primarly forwarded to N, 446 using per prefix LFA may lead to have a subset of X protected by a 447 neighbor N1, another subset by N2, another subset by Nx ... 449 o S is not aware about traffic flows to each destination and is not 450 able to evaluate how much traffic will be sent to N1,N2, ... Nx 451 in case of FRR activation. 453 Based on this, it is not useful to gather available bandwidth on 454 alternate paths, as the router does not know how much bandwidth it 455 requires for protection. The proposed link speed approach provides a 456 good approximation with a small cost as information is easily 457 available. 459 The bandwidth criteria of the policy framework SHOULD work in two 460 ways : 462 o PRUNE : exclude a LFA if link speed to reach it is lower than the 463 link speed of the primary nexthop interface. 465 o PREFER : prefer a LFA based on his bandwidth to reach it compared 466 to the link speed of the primary nexthop interface. 468 3.2.2.3. Neighbor preference 470 Rather than tagging interface on each node (using link color) to 471 identify neighbor node type (as example), it would be helpful if 472 routers could be identified in the IGP. This would permit a grouped 473 processing on multiple nodes. Some existing IGP extension like SUB- 474 TLV 1 of TLV 135 may be useful for this purpose. As an 475 implementation must be able to exclude some specific neighbors (see 476 mandatory criterions), an implementation : 478 o SHOULD be able to give a preference to specific neighbor. 480 o SHOULD be able to give a preference to a group of neighbor. 482 o SHOULD be able to exclude a group of neighbor. 484 A specific neighbor may be identified by its interface or IP address 485 and group of neighbors may be identified by a marker like SUB-TLV1 in 486 TLV135. As multiple prefixes may be present in TLVs 135, an 487 heuristic is required to choose the appropriate one that will 488 identify the neighbor and will transport the tag associated with the 489 neighbor preference. 491 We propose the following algorithm to select the prefix : 493 1. Select the prefix in TLV#135 that is equal to TLV#134 value 494 (Router ID) and prefix length is 32. 496 2. Select the prefix in TLV#135 that is equal to TLV#132 value (IP 497 Addresses) and prefix length is 32, it must be noted that TLV#132 498 may transport multiple addresses and so multiple matches may 499 happen. 501 3. If multiple prefixes are matching TLV#132 values, choose the 502 highest one. 504 Consider the following network: 506 PE3 507 | 508 | 509 PE2 510 | +---- P4 511 | / 512 PE1 ---- P1 -------- P2 513 | 10Gb 514 1Gb | 515 | 516 P3 518 Figure 6 520 In the example above, each node is configured with a specific tag 521 flooded through the IGP. 523 o PE1,PE3: 200 (non candidate). 525 o PE2: 100 (edge/core). 527 o P1,P2,P3: 50 (core). 529 A simple policy could be configured on P1 to choose the best 530 alternate for P1->P4 based on router function/role as follows : 532 o criteria 1 -> neighbor preference: exclude tag 100 and 200. 534 o criteria 2 -> bandwidth. 536 3.2.2.4. Link vs remote alternate 538 In addition to LFA, tunnels (IP, LDP or RSVP-TE) to distant routers 539 may be used to complement LFA coverage (tunnel tail used as virtual 540 neighbor). When a router has multiple alternate candidates for a 541 specific destination, it may have connected alternates (link 542 alternates) and remote alternates reachable via a tunnel. Link 543 alternates may not always provide an optimal routing path and it may 544 be preferable to select a remote alternate over a link alternate. 545 The usage of tunnels to extend LFA coverage is described in 546 [I-D.ietf-rtgwg-remote-lfa] and 547 [I-D.litkowski-rtgwg-lfa-rsvpte-cooperation]. 549 In figure 1, there is no core alternate for R8 to reach PEs located 550 behind R6, so R8 is using PE2 as alternate, which may generate 551 congestion when FRR is activated. Instead, we could have a remote 552 core alternate for R8 to protect PEs destinations. For example, a 553 tunnel from R8 to R3 would ensure a LFA protection without any 554 impact. 556 There is a requirement to be able to compare remote alternates 557 (reachable through a tunnel) to link alternates (a remote alternate 558 may provide a better protection than a link alternate based on 559 service provider's criteria). Policy will associate a preference to 560 each alternate whatever their type (link or remote) and will elect 561 the best one. 563 4. Operational aspects 565 4.1. ISIS overload bit on LFA computing node 567 In [RFC5286], Section 3.5, the setting of the overload bit condition 568 in LFA computation is only taken into account for the case where a 569 neighbor has the overload bit set. 571 In addition to RFC 5286 inequality 1 Loop-Free Criterion 572 (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the 573 IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be 574 taken into account. Indeed, if it has the overload bit set, no 575 neighbor will loop back to traffic to itself. 577 4.2. Manual triggering of FRR 579 Service providers often use using manual link shutdown (using router 580 CLI) to perform some network changes/tests. Especially testing or 581 troubleshooting FRR requires to perform the manual shutdown on the 582 remote end of the link as generally a local shutdown would not 583 trigger FRR. To enhance such situation, an implementation SHOULD 584 support triggering/activating LFA Fast Reroute for a given link when 585 a manual shutdown is done. 587 4.3. Required local information 589 LFA introduction requires some enhancement in standard routing 590 information provided by implementations. Moreover, due to the non 591 100% coverage, coverage informations is also required. 593 Hence an implementation : 595 o MUST be able to display, for every prefixes, the primary nexthop 596 as well as the alternate nexthop information. 598 o MUST provide coverage information per activation domain of LFA 599 (area, level, topology, instance, virtual router, address family 600 ...). 602 o MUST provide number of protected prefixes as well as non protected 603 prefixes globally. 605 o SHOULD provide number of protected prefixes as well as non 606 protected prefixes per link. 608 o MAY provide number of protected prefixes as well as non protected 609 prefixes per priority if implementation supports prefix-priority 610 insertion in RIB/FIB. 612 o SHOULD provide a reason for chosing an alternate (policy and 613 criteria) and for excluding an alternate. 615 o SHOULD provide the list of non protected prefixes and the reason 616 why they are not protected (no protection required or no alternate 617 available). 619 4.4. Coverage monitoring 621 It is pretty easy to evaluate the coverage of a network in a nominal 622 situation, but topology changes may change the coverage. In some 623 situations, the network may no longer be able to provide the required 624 level of protection. Hence, it becomes very important for service 625 providers to get alerted about changes of coverage. 627 An implementation SHOULD : 629 o provide an alert system if total coverage (for a node) is below a 630 defined threshold or comes back to a normal situation. 632 o provide an alert system if coverage of a specific link is below a 633 defined threshold or comes back to a normal situation. 635 An implementation MAY : 637 o provide an alert system if a specific destination is not protected 638 anymore or when protection comes back up for this destination 640 Although the procedures for providing alerts are beyond the scope of 641 this document, we recommend that implementations consider standard 642 and well used mechanisms like syslog or SNMP traps. 644 5. Security Considerations 646 This document does not introduce any change in security consideration 647 compared to [RFC5286]. 649 6. Contributors 651 Significant contributions were made by Pierre Francois, Hannes 652 Gredler and Mustapha Aissaoui which the authors would like to 653 acknowledge. 655 7. Acknowledgements 657 8. IANA Considerations 659 This document has no action for IANA. 661 9. References 662 9.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 668 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 670 9.2. Informative References 672 [I-D.ietf-rtgwg-remote-lfa] 673 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 674 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01 675 (work in progress), December 2012. 677 [I-D.litkowski-rtgwg-lfa-rsvpte-cooperation] 678 Litkowski, S., Decraene, B., Filsfils, C., and K. Raza, 679 "Interactions between LFA and RSVP-TE", 680 draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01 (work in 681 progress), February 2013. 683 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 684 (TE) Extensions to OSPF Version 2", RFC 3630, 685 September 2003. 687 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 688 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 689 RFC 3906, October 2004. 691 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 692 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 693 May 2005. 695 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 696 Engineering", RFC 5305, October 2008. 698 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 699 RFC 5714, January 2010. 701 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 702 Convergence", RFC 5715, January 2010. 704 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 705 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 706 Alternate (LFA) Applicability in Service Provider (SP) 707 Networks", RFC 6571, June 2012. 709 Authors' Addresses 711 Stephane Litkowski 712 Orange 714 Email: stephane.litkowski@orange.com 716 Bruno Decraene 717 Orange 719 Email: bruno.decraene@orange.com 721 Clarence Filsfils 722 Cisco Systems 724 Email: cfilsfil@cisco.com 726 Kamran Raza 727 Cisco Systems 729 Email: skraza@cisco.com