idnits 2.17.1 draft-litkowski-rtgwg-lfa-rsvpte-cooperation-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In other words, if a node S has an IGP/LDP forwarding entry F1 with outgoing interface i1 and S originates a TE tunnel T1 terminating at node Y, then an implementation SHOULD support a local policy which instructs node S to consider Y as a virtual neighbor and hence include Y as part of the LFA FRR alternate computation. In such case, an implementation MUST not use Y as an LFA for F1 if T1's outgoing interface is i1. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o MPLS TE forwarding entries MUST not be protected by LFA (if an operator wants protection, TE FRR could be enabled). -- The document date (August 19, 2013) is 3896 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.bryant-ipfrr-tunnels' is defined on line 468, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3906 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-remote-lfa-02 Summary: 1 error (**), 0 flaws (~~), 5 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: February 20, 2014 C. FilsFils 6 K. Raza 7 Cisco Systems 8 August 19, 2013 10 Interactions between LFA and RSVP-TE 11 draft-litkowski-rtgwg-lfa-rsvpte-cooperation-02 13 Abstract 15 This document defines the behavior of a node supporting Loopfree 16 Alternates (LFA) when the node has established RSVP TE tunnels. It 17 first describes the decisions to be made by the LFA mechanism with 18 respect to the use of TE tunnels as LFA candidates. Second, it 19 discusses the use of RSVP TE tunnels as a way to complement the LFA 20 coverage, illustrating how these technologies can benefit from each 21 other. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 20, 2014. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. LFA FRR and MPLS-TE interactions . . . . . . . . . . . . . . 3 64 2.1. Use case : using MPLS LSP as LFA candidates . . . . . . . 3 65 2.2. Specifications of interactions between LFA and TE LSP . . 4 66 2.2.1. Having both a physical interface and a TE tunnel 67 toward a LFA . . . . . . . . . . . . . . . . . . . . 4 68 2.2.2. TE ingress LSP as LFA candidate . . . . . . . . . . . 4 69 2.2.3. Independence between LFA and TE FRR . . . . . . . . . 5 70 3. Operational considerations . . . . . . . . . . . . . . . . . 7 71 3.1. Relevance of joint LFA FRR and RSVP-TE FRR deployments . 7 72 3.2. Extending LFA coverage using RSVP-TE tunnels . . . . . . 8 73 3.2.1. Creating multihop tunnel to extend topology . . . . . 8 74 3.2.2. Selecting multihop tunnels to extend topology . . . . 9 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 When a failure occurs in an IP network, the subsequent converge 86 process often leads to traffic disruption. Some mechanisms are 87 available to limit traffic disruptions by pre-computing alternate 88 paths and locally reroute over these as soon as the failure is 89 detected. Such techniques are commonly known as "protection 90 mechanisms". Currently, the protection mechanisms widely used in 91 Service Provider networks are RSVP-TE Fast Reroute [RFC4090] and Loop 92 Free Alternates [RFC5286]. RSVP-TE FRR permits full network coverage 93 but with a quite high complexity in terms of operation, as well as 94 potential scaling issues. On the other hand, LFA offer a very easy, 95 manageable, and scalable mechanism, but does not provide full 96 coverage. 98 This document discusses how LFA and RSVP-TE should interact. It 99 first describes how an LFA implementation should deal with existing 100 RSVP TE tunnels established by the LFA node, as well as its behavior 101 with respect to established IGP Shortcut tunnels [RFC3906]. Second, 102 the document suggets the use of RSVP-TE tunnels to extend LFA 103 coverage, and discusses the management and operational aspects of 104 such a practice. 106 2. LFA FRR and MPLS-TE interactions 108 This section discusses the various interactions among LFA FRR and 109 MPLS-TE FRR. It starts with a simple example emphasizing the 110 benefits of jointly using of LFA-FRR and MPLS-TE FRR, and then 111 summarizes the requirements for the interactions between LFAs and 112 MPLS-FRR. 114 2.1. Use case : using MPLS LSP as LFA candidates 116 In some cases, typically in ring shapped parts of network topologies, 117 links cannot be protected by LFAs. In the following topology, from 118 the point of view of R5, LFAs are able to partiatlly protect (49% of 119 the destination routers) from the failure of R3, while the failure of 120 R4 is not covered at all. 122 (30 routers) --- R1 ----(30)---- R2 --- (50 routers) 123 | | 124 (5) (30) 125 | | 126 R3 R4 --- (20 routers) 127 | | 128 (10) (30) 129 | | 130 ------- R5 ------ 132 Figure 1 134 Many networks deploy MPLS tunnels for traffic engineering and 135 resiliency reasons. To extend its benefit, an LFA implementation 136 could take advantage of such existing MPLS tunnels. In the exemple 137 above, if R5 has established TE tunnels bypassing R4 and R3, these 138 could be considerd as LFA candidates respectively protecting links 139 from R5 to R4 and R3. 141 In the following section, we provide a detailed summary of the 142 behavior to be applied by an LFA implementation which would consider 143 the existence of MPLS TE tunnels to improve its applicability. The 144 explicit configuration of such tunnels with the intent of improving 145 LFA applicability is discussed in later sections. 147 2.2. Specifications of interactions between LFA and TE LSP 149 Here we summarize the normative requirements for the interaction 150 between LFA FRR and MPLS TE tunnels. 152 2.2.1. Having both a physical interface and a TE tunnel toward a LFA 154 If a node S has both a physical interface and a TE tunnel to reach a 155 LFA, it SHOULD use the physical interface unless : 157 1. The tunnel has been explicitly configured as an LFA candidate. 159 2. The tunnel does not pass through the link subject to LFA 160 protection. 162 In other words, if a node S has an IGP/LDP forwarding entry F1 with 163 outgoing interface i1, and S originates a TE tunnel T2 terminating on 164 direct neighbor N2 (for example : if a TE tunnel is provisionned for 165 link protection), T2 has an outgoing interface i2 and N2 is best LFA 166 for F1, then an implementation MUST NOT use T2 when programming LFA 167 repair for F1 unless T2 is configured as an LFA candidate. 169 2.2.2. TE ingress LSP as LFA candidate 171 A TE LSP can be used as a virtual interface to reach a LFA if 173 1. The TE tunnel has been configured to allow its use as an LFA 174 candidate. 176 2. The TE tunnel does not pass through the primary outgoing 177 interface of D. 179 This would permit to extend LFA coverage as described in 180 [I-D.ietf-rtgwg-remote-lfa], in a controlled fashioned, as the 181 tunnels used by the fast reroute mechanism are defined by 182 configuration. 184 In other words, if a node S has an IGP/LDP forwarding entry F1 with 185 outgoing interface i1 and S originates a TE tunnel T1 terminating at 186 node Y, then an implementation SHOULD support a local policy which 187 instructs node S to consider Y as a virtual neighbor and hence 188 include Y as part of the LFA FRR alternate computation. In such 189 case, an implementation MUST not use Y as an LFA for F1 if T1's 190 outgoing interface is i1. 192 2.2.3. Independence between LFA and TE FRR 194 2.2.3.1. Tunnel head-end case 196 Similar requirements can be expressed for TE IGP shortcut tunnels. 198 -----C1 --------- 199 / | \ 200 / | \ 201 PE1 ---- C2 --- C3 ---- PE2 202 | / 203 PE3 205 Figure 2 207 PE to Cx metrics are 50, Cx to Cx are 1 209 A service provider is often providing traffic-engineered path for 210 specific customer traffic (L3VPN, PW ...) to ensure path diversity or 211 traffic constraints. In the diagram above, we consider a TE tunnel 212 T2 built on a non shortest path as follows : PE1->C2->C3->PE2 and IGP 213 shortcut is activated on PE1 to make traffic to PE2 using T2. Based 214 on operational feedback, some implementations prevent LFA computation 215 to run for an interface where a TE tunnel exists. In our example, if 216 LFA is activated on N, we would not be able to have a protection for 217 PE3 destination as a tunnel exists on the interface. This current 218 observed behavior leads to a very limited coverage for LFA. In the 219 other hand, it is important to keep protection mechanisms independant 220 as much as possible to keep implementation simple. We propose the 221 following approach : 223 o If an IP prefix is reachable through a TE tunnel, LFA must not 224 compute a protection for it. 226 o If an IP prefix is reachable through a native IP path, LFA MUST 227 compute a protection for it disregarding the presence of a tunnel 228 or not on the primary interface. 230 In other words, if a node S has an IGP/LDP forwarding entry F1 with 231 outgoing interface i1 and an IGP/LDP forwarding entry F2 with 232 outgoing interface onto a TE tunnel T2 (due to IGP shortcut 233 [RFC3906]) and tunnel T2 has outgoing interface i2, then an 234 implementation MUST support enabling LFA FRR for F1 and using TE FRR 235 for F2 as long as i1 != i2. 237 If i1 == i2, an implementation SHOULD allow for using LFA FRR backup 238 for F1 and TE FRR backup for F2. 240 The mechanisms for using TE tunnel as an LFA candidate, and RFC3906 241 mechanisms MUST be de-correlated -- i.e an implementation MUST 242 support TE tunnel configuration with RFC3906 only, as LFA candidate 243 only, or both at the same time. 245 2.2.3.2. Tunnel midpoint case 247 -----C1 --------- 248 / | \ 249 / | \ 250 PE1 ---- C2 --- C3 ---- PE2 251 | / 252 PE3 254 Figure 3 256 PE to Cx metrics are 50, except PE3-C3 (60), Cx to Cx are 1 258 In the diagram above, we consider a TE tunnel T2 built on a non 259 shortest path as follows : PE1->C2->C3->PE2 and IGP shortcut is 260 activated on PE1 to make traffic to PE2 using T2. C2 is a TE tunnel 261 midpoint router. In terms of forwarding, C2 has a MPLS TE forwarding 262 entry for T2, as well as an IP forwarding entry to PE2. As explained 263 in previous sections, it would be too restrictive and would limit LFA 264 benefit on C2 if C2 would not be able to compute an LFA for the IP 265 forwarding entry to PE2 due to the presence of a transit tunnel. 267 We propose the following approach for a midpoint router of a TE 268 tunnel : 270 o MPLS TE forwarding entries MUST not be protected by LFA (if an 271 operator wants protection, TE FRR could be enabled). 273 o IP forwarding entries MUST be protected by LFA disregarding the 274 presence of a TE tunnel transiting through the primary interface 275 of the destination. 277 In our example : 279 o MPLS TE forwarding entry for T2 (ending on PE2) would be protected 280 by TE-FRR (if enabled). 282 o IP forwarding entry for PE2 would be protected by LFA. 284 In case of failure of C2-C3 : 286 o traffic from PE1 to PE2 (encapsulated in T2), would be protected 287 by TE FRR. 289 o traffic from PE3 to PE2 (native IP), would be protected by LFA. 291 In other words, if a node S has an IGP/LDP forwarding entry F1 with 292 outgoing interface i1 and a MPLS TE midpoint forwarding entry F2 with 293 outgoing interface i2, then an implementation MUST support using LFA 294 FRR for F1 and TE FRR for F2 as long as i1 != i2. 296 If i1 == i2, an implementation SHOULD allow for using LFA FRR backup 297 for F1 and TE FRR backup for F2. 299 3. Operational considerations 301 In this section, we first discuss the benefit of considering a joint 302 deployment of LFA and MPLS tunnels to achieve resiliency. We then 303 discuss one approach aiming at defining MPLS tunnels for the purpose 304 of complementing LFA coverage. 306 3.1. Relevance of joint LFA FRR and RSVP-TE FRR deployments 308 This section describes the deployment scenarios where it can be 309 beneficial to jointly use LFAs and RSVP-TE FRR. 311 There are many networks where RSVP-TE is already deployed. The 312 deployment of RSVP-TE is typically for two main reasons : 314 o Traffic engineering : a provider wants to route some flows on some 315 specific paths using constraints; 317 o Traffic protection using Fast-reroute ability 319 LFA is a feature that may bring benefits on RSVP-TE enabled networks, 320 with no/minimal operational cost (compared to RSVP-TE FRR global roll 321 out). These benefits include: 323 o Should increase protection on network where FRR is not available 324 everywhere. Although it may not provide full coverage, it will 325 increase the protection significantly. 327 o May provide better protection in specific cases than RSVP-TE FRR 329 For IP networks that do not have any traffic protection mechanism, 330 LFA is a very good first step to provide traffic protection even if 331 its coverage is not 100%. Providers may want to increase protection 332 coverage if LFA benefit is not sufficient for some destinations, in 333 some parts of the network. The following sections discusses the use 334 of basic RSVP-TE tunnels to extend protection coverage. 336 3.2. Extending LFA coverage using RSVP-TE tunnels 338 We already have seen in previous sections that RSVP-TE tunnels could 339 be established by an operator to complement LFA coverage. The method 340 of tunnel placement depends on what type of protection (link or node) 341 is required, as well as on the set of destinations or network parts 342 which requires better protection than what LFA can provide. 344 3.2.1. Creating multihop tunnel to extend topology 346 To extend the coverage, the idea is to use a mechanism extending LFA 347 by turning TE tunnels into LFA candidates. This mechanism is of a 348 local significance only. 350 When explicitly establishing tunnels for that purpose, choices have 351 to be made for the endpoints of such tunnels, in order to maximize 352 coverage while preserving management simplicity. Requirements are 353 that: 355 o Endpoints must satisfy equations from [RFC5286], otherwise it will 356 not be a valide LFA candidate: so when releasing traffic from 357 tunnel, the traffic will go to the destination without flowing 358 through the protected link or node. Depending on which equations 359 are satisfied, node or link protection will be provided by the 360 tunnel hop. 362 o Tunnel must not flow though the link or node to be protected, 363 explicit routing of tunnel is recommended to enforce this 364 condition. 366 The approach to choose tunnel endpoints might be different here when 367 compared to [I-D.ietf-rtgwg-remote-lfa] as endpoint choice is a 368 manual one. Automatic behavior and scaling of 369 [I-D.ietf-rtgwg-remote-lfa] requires: 371 o Non null intersection of Extended P-Space and Q-Space 373 o Computation of PQ node only for the remote end of the link 375 Based on this, [I-D.ietf-rtgwg-remote-lfa] may: 377 o Not find a tunnel endpoint; 379 o Not provide the more efficient protection : -- i.e. provides only 380 link protection, while there is node protection possible for a 381 specific destination 383 The proposed solution of manual explicitly routed tunnels is a good 384 complement for [I-D.ietf-rtgwg-remote-lfa] and provides more 385 flexibility: 387 o Always a possibility to find a tunnel endpoint for a specific 388 destination. 390 o Possibility to provide a better protection type (link vs. node). 392 3.2.2. Selecting multihop tunnels to extend topology 394 From a manageability point of view, computing a best Q node for each 395 destination could lead to have one different Q node for each 396 destination. This is not optimal in terms of number of tunnels, 397 given that possibly one Q node may be able to serve multiple non 398 covered destinations. 400 Rather than computing the best Q node per non covered destination, we 401 would prefer to find best compromise Q nodes (best for multiple 402 destinations). To find the best compromise between coverage increase 403 and number of tunnels, we recommend to use a simulator performing the 404 following computations per link: 406 Step 1 : Compute for each not covered destination (routed on the 407 link) the list of endpoints that are satisfying equations from 408 [RFC5286] (node or link protection equations depending of required 409 level of protection) : nodes in Q-Space 411 Step 2 : Remove endpoints that are not eligible for repair (Edge 412 nodes, low bandwidth meshed nodes, number of hops ...) : multiple 413 attributes could be specified to exclude some nodes from Q-Space : 414 The example of attributes include router type, metric to node, 415 bandwidth, packet loss, RTD ... 417 Step 3 : Within the list of endpoints (one list per destination), 418 order the endpoints by number of destination covered 420 Step 4 : Choose the endpoint that has the highest number of 421 destination covered : some other criteria could be used to prefer 422 an endpoint from another (same type of criteria that excluded some 423 nodes from Q-Space) 425 Step 5 : Remove destinations covered by this endpoint from non 426 covered list 428 Step 6 : If non covered list is not empty, restart from Step 1 430 Multiple endpoint (and so tunnels) could be necessary to have 100% 431 coverage. But the idea is to find a tradeoff between number of 432 tunnels configured (complexity) and number of destination covered, 433 combining with traffic information would also provide a better view. 435 4. Security Considerations 437 TBD. 439 5. Contributors 441 Significant contribution was made by Pierre Francois which the 442 authors would like to acknowledge. 444 6. IANA Considerations 446 This document has no actions for IANA. 448 7. References 450 7.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 456 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 457 RFC 3906, October 2004. 459 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 460 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 461 2005. 463 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 464 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 466 7.2. Informative References 468 [I-D.bryant-ipfrr-tunnels] 469 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 470 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 471 (work in progress), November 2007. 473 [I-D.ietf-rtgwg-remote-lfa] 474 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S. 475 Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02 476 (work in progress), May 2013. 478 Authors' Addresses 480 Stephane Litkowski 481 Orange 483 Email: stephane.litkowski@orange.com 485 Bruno Decraene 486 Orange 488 Email: bruno.decraene@orange.com 490 Clarence FilsFils 491 Cisco Systems 493 Email: cfilsfil@cisco.com 495 Kamran Raza 496 Cisco Systems 498 Email: skraza@cisco.com