idnits 2.17.1 draft-spallagatti-rtgwg-bandwidth-based-metric-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 212 has weird spacing: '...fied in this ...' == 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: +------------+------------------------------------------------------+ | Attribute | Value and Significance | +------------+------------------------------------------------------+ | Min_BW | This is the minimum bandwidth below which outgoing | | | traffic MUST not be carried on this interface-group. | | | It needs to load-balance across links of best/non- | | | best interface-groups as well. | | | | | Restore_BW | This is the bandwidth above which the outgoing | | | traffic MUST entirely be carried over the members of | | | this interface-group not needing to load-balance | | | across member links of other non-best interface- | | | groups, provided it provides a path with shortest | | | metric. | +------------+------------------------------------------------------+ -- The document date (August 19, 2015) is 3166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Pallagatti, Ed. 3 Internet-Draft P. Sarkar, Ed. 4 Intended status: Informational H. Gredler 5 Expires: February 20, 2016 Juniper Networks 6 S. Litkowski 7 Orange Business Service 8 August 19, 2015 10 IGP bandwidth based metric. 11 draft-spallagatti-rtgwg-bandwidth-based-metric-01 13 Abstract 15 This document describes a method to group multiple interfaces and 16 assign metric to that group based on the cumulative bandwidth of all 17 the interfaces in that group. Each link in a group takes same group 18 metric irrespective of its own bandwidth. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 20, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. BBM Concepts . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Interface-Group . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. BBM Metric Configurations . . . . . . . . . . . . . . . . 4 64 2.3. BBM Terminologies . . . . . . . . . . . . . . . . . . . . 5 65 2.4. Metric Derivation . . . . . . . . . . . . . . . . . . . . 5 66 3. Bandwidth Based Routing . . . . . . . . . . . . . . . . . . . 6 67 4. Bandwidth-based Fast Reroute . . . . . . . . . . . . . . . . 7 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. Assumptions and Pre-requisites . . . . . . . . . . . . . 8 70 4.3. Additional Configuration and Attributes . . . . . . . . . 9 71 4.4. Enhancements to Local Repair in Forwarding Plane . . . . 11 72 4.5. Influencing Path Preferences . . . . . . . . . . . . . . 12 73 4.6. Path Selection and Preference . . . . . . . . . . . . . . 12 74 5. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Consideration . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 14 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 8.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 A low cost path is always preferred to carry traffic from source to 85 destination. If a application is more interested in bandwidth than 86 the cost itself and most preferred path does not satisfy bandwidth 87 then this could potentially lead to congestion and packet loss for an 88 application. Bandwidth critical applications needs minimum bandwidth 89 to be satisfied even if traffic is carried over multiple alternative 90 paths to reach a destination. 92 +--------+ +--------+ 93 | |----------10---------| | 94 | R2 |----------10---------| R3 | 95 D1-----------| |----------10---------| |-----------D2 96 +--------+ +--------+ 97 | | | | | | 98 | | | | | | 99 | | | +--------+ | | | 100 | | +--10---|L1 L4|---10---+ | | 101 | +----10---|L2 R1 L5|---10-----+ | 102 +-------10---|L3 L6|---10--------+ 103 +--------+ 105 Figure 1: Example Topology 107 Consider the topology as show in Figure 1. The device R1 uses a 108 links L1, L2 and L3 to carry traffic to destination D1. Similarly it 109 uses links L4, L5 and L6 for destination D2. However in the event of 110 links L1 and/or L2 fails traffic is still forwarded on link L3 111 causing traffic congestion. 113 In such situations operators will prefer the traffic for destination 114 D1 is forwarded on L4, L5 and L6, as there is lesser chance of 115 congestion. Similarly when links L4 and L5 also fails, the operator 116 will prefer the traffic for D1 is forwarded is switched back on link 117 L3 again. This document proposes a method called Bandwidth Based 118 Metrics (hereafter referred as BBM), which helps achieving this 119 desired behaviour. 121 BBM, on detecting a local link event, attempts to re-route traffic, 122 based on remaining bandwidth across the links on the primary and 123 alternate paths. When the remaining available bandwidth on the 124 primary link(s) goes below a permissible limit (to be specified by 125 the operator), traffic should be re-routed to one or more groups of 126 alternative paths, and re-distributed onto multiple alternate paths 127 with lesser likeliness of congesting them. 129 This document also specifies how to extend Fast Re-Route (FRR) for 130 BBM to meet stringent re-convergence time constraints, and minimize 131 traffic loss due to network congestion caused by standard FRR 132 mechanisms. 134 2. BBM Concepts 135 2.1. Interface-Group 137 BBM method proposed in this document requires grouping of all the 138 local links (or interfaces) attached to a node into one or more 139 logical bundles. Such a logical grouping of multiple local 140 interfaces is called an interface-group, and needs to be provisioned 141 manually by the operator on each node. While assigning the local 142 interfaces to a interface-group, all links connecting the local node 143 to the same one-hop neighbor, SHOULD be assigned to a single 144 interface-group. In other words the number of interface-group to be 145 created on a node SHOULD be at the least, the number of one-hop 146 neighbor nodes the particular node is connected to. 148 In Figure 1 links L1, L2, and L3 connecting R1 and R2 can be grouped 149 into a single interface group (say IG1) on both R1 and R2. Similarly 150 links L4, L5 and L6 connecting R1 and R3 can be grouped into another 151 single interface-group (say IG2) on both R1 and R3. 153 2.2. BBM Metric Configurations 155 All the interfaces under a given interface-group shall share a metric 156 that is proportionate to the cumulative bandwidth available using the 157 individual links under the interface-group. if a link is associated 158 with interface-group then interface-group metric MUST override 159 individual link metric configuration. Implementations SHOULD allow 160 operator to specify what metric should be associated for a given 161 total remaining available bandwidth for each interface group. 162 Implementations SHOULD also allow operator specify the default metric 163 to be used for each interface-group. 165 In Figure 1, considering all the links L1 to L6 having bandwidth 166 capacity of 100G each, and assigned into two interface-groups IG1 and 167 IG2 (as shown in Section 2.1), following is an example of simple BBM 168 config for each of these interface-group. 170 IG1: 171 Member-Links: L1,L2,L3 172 Total-Available-BW: 200G, Metric: 10 173 Total-Available-BW: 100G, Metric: 50 174 Default-Metric: 1000 176 IG2: 177 Member-Links: L4,L5,L6 178 Total-Available-BW: 200G, Metric: 10 179 Total-Available-BW: 100G, Metric: 50 180 Default-Metric: 1000 182 Figure 2: Example BBM Configuration 184 2.3. BBM Terminologies 186 This document also defines the following attributes to be associated 187 with each interface-group. 189 +----------------------+--------------------------------------------+ 190 | Attribute | Value and Significance | 191 +----------------------+--------------------------------------------+ 192 | Intf_List | The list of interfaces assigned to this | 193 | | group as per configuration. | 194 | | | 195 | BW_Curr | Total available bandwidth across all | 196 | | active member interfaces of this group. | 197 | | | 198 | BBM_Metric_Cfg_List | This is an array of "BBM_Metric_Cfg_Entry" | 199 | | (defined below). The key to the list is | 200 | | "bandwidth" and is always sorted in | 201 | | descending order (i.e. entries with higher | 202 | | "bandwidth" appears before entries with | 203 | | lower "bandwidth". | 204 | | | 205 | BBM_Metric_Cfg_Entry | This defines a single entry in | 206 | | "BBM_Metric_Cfg_List" array (defined | 207 | | above). It is a tuple ["Bandwidth", | 208 | | "Metric"], and defines the metric that | 209 | | should be associated with the individual | 210 | | interfaces of this group, when the total | 211 | | available bandwidth for the group matches | 212 | | "bandwidth" range specified in this | 213 | | entry. Refer to Table 2 for more details. | 214 | | | 215 | Default_Metric | The default metric as per configuration. | 216 | | Default metric will be assigned to all | 217 | | interfaces under this group if total | 218 | | available bandwidth for the group Does not | 219 | | match the "Bandwidth" range specified in | 220 | | any "BBM_Metric_Cfg_Entry" for this group. | 221 | | Refer to Table 2 for more details. | 222 +----------------------+--------------------------------------------+ 224 Table 1: Interface Group Attributes 226 2.4. Metric Derivation 228 Once a interface has been assigned to a interface-group, and the 229 corresponding BBM metric configurations has been provisioned, metric 230 to be associated with the member interfaces can be derived as 231 follows: 233 Sort igp.BBM_Metric_Cfg_List in descending order based on BBM_Metric_Cfg_Entry.Bandwidth 234 Set Intf.Metric = 0 235 For (all BBM_Metric_Cfg_Entry in igp.BBM_Metric_Cfg_List 236 in descending order) 237 - If (igp.BW_Curr >= 238 igp.BBM_Metric_Cfg_List.BBM_Metric_Cfg_Entry.Bandwidth) 239 - Set Intf.Metric = 240 igp.BBM_Metric_Cfg_List.BBM_Metric_Cfg_Entry.Metric. 241 end the loop. 242 If (Intf.Metric == 0) 243 - Set Intf.Metric = igp.Default_Metric. 245 Considering the BBM metric configurations for interface-group IG1 in 246 Figure 2, Table 2 below shows how metric for individual interfaces of 247 IG1 SHALL be computed at any point of time. 249 +-------------+--------------------+------------+-------------------+ 250 | Active- | Total-Available-BW | BBM-Metric | Remarks | 251 | Links | | | | 252 +-------------+--------------------+------------+-------------------+ 253 | L1, L2, L3 | 300G | 10 | Total-Avaiable-BW | 254 | | | | >= 200 | 255 | | | | | 256 | L1, L2, | 200G | 10 | Total-Avaiable-BW | 257 | L3(down) | | | >= 200 | 258 | | | | | 259 | L1, | 100G | 50 | 200 > Total- | 260 | L2(down), | | | Avaiable-BW >= | 261 | L3(down) | | | 100 | 262 +-------------+--------------------+------------+-------------------+ 264 Table 2: BBM Metric Calculation 266 3. Bandwidth Based Routing 268 Once the metric of individual interfaces are derived from the 269 corresponding interface-group BBM configuration, the same are used in 270 the local IGP SPF computations. In addition to using the metrics in 271 SPF computations, the same are also advertised as the corresponding 272 link cost (instead of the original cost associated with the 273 individual links) in the locally-generated IGP link-state 274 advertisements. This is done to eliminate any looping possible 275 otherwise. 277 Considering the topology in Figure 1, Table 3 below shows how traffic 278 for destination D1 shall be re-routed based on a series of events and 279 BBM metric configurations as shown in Figure 2. 281 +--------+------------+------------------------+-----------+--------+ 282 | Event | Interface- | Active-Links/Total- | Total- | Shorte | 283 | | Group | Available-BW | Metric | st | 284 | | | | | Path | 285 +--------+------------+------------------------+-----------+--------+ 286 | Initia | IG1 | {L1, L2, L3} / 300G | 10 + Dopt | YES | 287 | lly | | | (R2,D1) | | 288 | | IG2 | {L4, L5, L6} / 300G | 20 + Dopt | NO | 289 | | | | (R2,D1) | | 290 | | | | | | 291 | L1 | IG1 | {L2, L3} / 200G | 10 + Dopt | YES | 292 | goes | | | (R2,D1) | | 293 | down | | | | | 294 | | IG2 | {L4, L5, L6} / 300G | 20 + Dopt | NO | 295 | | | | (R2,D1) | | 296 | | | | | | 297 | L2 | IG1 | {L2, L3} / 200G | 50 + Dopt | NO | 298 | goes | | | (R2,D1) | | 299 | down | | | | | 300 | | IG2 | {L5, L6} / 200G | 20 + Dopt | YES | 301 | | | | (R2,D1) | | 302 | | | | | | 303 | L4 | IG1 | {L3} / 100G | 50 + Dopt | NO | 304 | goes | | | (R2,D1) | | 305 | down | | | | | 306 | | IG2 | {L5, L6} / 200G | 20 + Dopt | YES | 307 | | | | (R2,D1) | | 308 | | | | | | 309 | L5 | IG1 | {L3} / 100G | 50 + Dopt | YES | 310 | goes | | | (R2,D1) | | 311 | down | | | | | 312 | | IG2 | {L6} / 100G | 60 + Dopt | NO | 313 | | | | (R2,D1) | | 314 +--------+------------+------------------------+-----------+--------+ 316 Table 3: BBM based Routing 318 4. Bandwidth-based Fast Reroute 320 4.1. Overview 322 The BBM solution described in Section 2 requires IGPs running on the 323 control plane of the network device, to detect the link failures, 324 determine remaining available bandwidth, re-compute new optimum 325 paths, and finally install the new best paths to the forwarding 326 plane. This may take some time (in the order of 500 ms) for the 327 traffic to switch to a better path. 329 Also, even if regular FRR mechanism using LFA [RFC5286] and Remote- 330 LFA [I-D.ietf-rtgwg-remote-lfa] has been deployed, the alternate 331 paths chosen is not guaranteed to meet bandwidth constraints. Also, 332 though, [RFC5286] does not specify anything, most LFA implementations 333 in link-state protocols running on the network devices around the 334 world, employs use of a single backup link. Also if there are 335 multiple primary interfaces for a specific destinations, most 336 implementations do not install a alternate path in the forwarding 337 plane. So in the event of the primary link (or one of the multiple 338 primary links) going down, traffic is either switched to a single 339 interface, or not switched to any other link at all. In the first 340 case, there is more likeliness of the single alternate path getting 341 congested (as it might be already carrying some primary traffic for 342 other destinations already). In the latter case, there is more 343 likeliness of causing a congestion on the remaining primary links 344 (e.g. for destination D1, if both L1 and L2 goes down R1 still keeps 345 the traffic on L3 during local repair, trying to push 300G traffic on 346 a single 100G link L5). 348 Service providers who have stringent bandwidth requirements would 349 need the device to switch the traffic during local repair to multiple 350 alternate paths that have bandwidth constraints satisfied. When the 351 remaining primary OR alternate paths alone cannot satisfy bandwidth 352 requirements, it will also be desirable, to redistribute the traffic 353 over a combination of primary AND alternate paths, during local 354 repair as well as next SPF computations in IGP. 356 This document proposes a solution the above problem, based on 357 combination of BBM logic (referred to in Section 2) and protection 358 using LFA [RFC5286] and Remote-LFA [I-D.ietf-rtgwg-remote-lfa]. It 359 requires a group of primary links to be protected using multiple non- 360 best feasible alternate paths. The same group of alternate links 361 shall also be pre-installed in forwarding table to facilitate fast 362 re-route (FRR). The details of the solution is specified in the 363 following sub-sections. 365 4.2. Assumptions and Pre-requisites 367 Following are some of the assumptions that the solution proposed in 368 this document is based on. 370 The forwarding plane SHOULD be able handle multiple paths per 371 route and let control plane set the preference for each path over 372 the others. The forwarding machinery shall utilize this, to 373 select a subset of preferred paths, and use them to forward actual 374 traffic at any given point in time. Forwarding machinery SHOULD 375 also load balance traffic with next-hops having same preference 376 All the links attached to the network device are bundled to create 377 one or more interface-group(s). Also a link MUST belong to one 378 and only one interface-group. 380 Loops are possible if protection is enabled on all three routes 381 R1, R2 and R3 as shown in Figure 1. To avoid loops implementation 382 MUST have downstream Path Criterion as explained in LFA [RFC5286] 384 For each interface-group, operator MAY enable protection by 385 configuring the following two parameters. 387 Minimum-bandwidth: When the remaining bandwidth goes below this 388 the outgoing traffic can no more be carried entirely on this 389 bundle. Some of it shall be distributed across links of other 390 best/non-best interface-groups. 392 Restore-bandwidth: When the remaining bandwidth exceeds this, 393 the outgoing traffic can entirely be back over the members of 394 this bundle and there is no need to use any other backup for 395 all destinations reachable over the links of the bundle. 397 4.3. Additional Configuration and Attributes 399 This document defines the following configuration parameters to be 400 associated with each interface-group for facilitating Bandwidth-based 401 Fast Re-Route. Implementations MUST allow operators to configure 402 these parameters for each interface-group on a network device that 403 implements this solution. 405 +------------+------------------------------------------------------+ 406 | Attribute | Value and Significance | 407 +------------+------------------------------------------------------+ 408 | Min_BW | This is the minimum bandwidth below which outgoing | 409 | | traffic MUST not be carried on this interface-group. | 410 | | It needs to load-balance across links of best/non- | 411 | | best interface-groups as well. | 412 | | | 413 | Restore_BW | This is the bandwidth above which the outgoing | 414 | | traffic MUST entirely be carried over the members of | 415 | | this interface-group not needing to load-balance | 416 | | across member links of other non-best interface- | 417 | | groups, provided it provides a path with shortest | 418 | | metric. | 419 +------------+------------------------------------------------------+ 421 Table 4: BBM FRR Configurations 423 In Figure 1, considering all the links L1 to L6 having bandwidth 424 capacity of 100G each, and assigned into two interface-groups IG1 and 425 IG2 (as shown in Section 2.1), following is an example of simple BBM 426 FRR config for each of these interface-group. 428 IG1: 429 Member-Links: L1,L2,L3 430 Total-Available-BW: 200G, Metric: 10 431 Total-Available-BW: 100G, Metric: 50 432 Default-Metric: 1000 433 Protection: Enbaled 434 Restore-Bandwidth: 200G 435 Min-Bandwidth: 100G 437 IG2: 438 Member-Links: L4,L5,L6 439 Total-Available-BW: 200G, Metric: 10 440 Total-Available-BW: 100G, Metric: 50 441 Default-Metric: 1000 442 Protection: Enbaled 443 Restore-Bandwidth: 200G 444 Min-Bandwidth: 100G 446 Figure 3: Example BBM FRR Configuration 448 This document defines the following attributes to be associated with 449 each interface-group for facilitating Bandwidth-based Fast Re-Route. 451 +-----------------+-------------------------------------------------+ 452 | Attribute | Value and Significance | 453 +-----------------+-------------------------------------------------+ 454 | BW_PostFail | Cumulative bandwidth through all the remaining | 455 | | primary next-hops considering the primary next- | 456 | | hop with highest bandwidth goes down. | 457 | | | 458 | Metric_PostFail | Bandwidth based metric after a link goes down. | 459 +-----------------+-------------------------------------------------+ 461 Table 5: Additional Interface-Group Attributes 463 This solution proposed in this document also requires IGPs to define 464 and associated the following attributes for each destination node in 465 the IGP link-state database. 467 +-----------------+-------------------------------------------------+ 468 | Attribute | Value and Significance | 469 +-----------------+-------------------------------------------------+ 470 | | | 471 | Pri_Nh_Count | Number of primary next-hops found for the | 472 | | destination. | 473 | | | 474 | Pri_BW_Curr | Cumulative bandwidth across all the remaining | 475 | | primary next-hops. | 476 | | | 477 | Pri_BW_PostFail | Cumulative bandwidth through all the remaining | 478 | | primary nexthops considering the primary | 479 | | nexthop with highest bandwidth goes down. | 480 | | | 481 | Pri_BW_Restore | Cumulative restore-bandwidth for all the | 482 | | interface-groups considered for primary | 483 | | nexthops. | 484 | | | 485 | Pri_BW_Min | Cumulative minimum-bandwidth for all the | 486 | | interface-groups considered for primary | 487 | | nexthops. | 488 +-----------------+-------------------------------------------------+ 490 Table 6: Per-node Attributes 492 4.4. Enhancements to Local Repair in Forwarding Plane 494 Additionally, the solution proposed in this document also mandates, 495 that the forwarding plane SHOULD implement the following enhanced 496 local-repair logic, to facilitate BBM based fast-re-route, on 497 detecting a link-down event. 499 For each affected prefix (a prefix is affected if the fated link was 500 one of the preferred active paths used for forwarding). 501 - Find the actual affected path, and mark it unusable. 502 - For all other paths downloaded from control-plane, 503 - If the preference is same as that of the affected path, 504 - Modify its preference to value even lower than normal backup paths. 505 Finally, go through all remaining active paths 506 - Select a subset of paths (that share the same highest preference among all), 507 - Use the selected subset of paths to actually forward traffic. 509 Figure 4: Enhanced Local Repair in Forwarding Plane 511 4.5. Influencing Path Preferences 513 Like mentioned in Section 4.2 the solution proposed in this document 514 relies on the preference-based local-repair logic implemented in 515 forwarding-plane to facilitate fast re-route. This solution requires 516 IGPs to indirectly influence the local-repair action taken by the 517 forwarding-plane by choosing an suitable alternate path with an 518 appropriate preference-value pre-computed and installed in the 519 forwarding-plane, well ahead of the actual link failure event. 521 Table 7 below, specifies a set path-preference types that this 522 document proposes IGP to define and use while downloading any path 523 for a given destination in the forwarding table. 525 +---------------------+---------------------------------------------+ 526 | Preference-Type | Significance | 527 +---------------------+---------------------------------------------+ 528 | | | 529 | Pri_Nh_Pref | Preference type for normal primary paths. | 530 | | | 531 | Bkup_Nh_Pref_High | Preference type for paths, which are | 532 | | preferred, more than normal backup paths | 533 | | but less compared to normal primary paths. | 534 | | | 535 | Bkup_Nh_Pref_Normal | Preference type for normal backup paths. | 536 +---------------------+---------------------------------------------+ 538 Table 7: Path-Preference Types 540 4.6. Path Selection and Preference 542 Based on the above assumptions, additional configuration parameters 543 and attributes the document proposes IGPs to implement the following 544 logic for computing primary and alternate paths for each destination, 545 and determine their corresponding path-preference value as well 546 Step 1: 547 ======= 548 - For each interface-group "igp" 549 - Update "igp.BW_Curr" by adding the bandwidths 550 of the individual active member interfaces. 551 - Update "igp.BW_PostFail", assuming one of the active 552 member interfaces with highest bandwidth goes down next. 554 Step 2: 555 ======= 556 - For each destination node "D" in the network (Pass-1) 557 - Update D.Pri_BW_Restore and D.Pri_BW_Min from the SPF results. 558 - Reset D.Pri_Nh_Count to 0. 559 - For each corresponding primary path N, 560 - Set "igp" -> Interface-group N belongs to. 561 - If igp.BW_Curr > D.Min_BW 562 - Set preference of N to Pri_Nh_Pref. 563 - Increment the D.Pri_Nh_Count by 1. 564 - Else 565 - Set preference of N to Bkup_Nh_Pref_Normal. 567 Step 3: 568 ======= 569 - For each destination node "D" in the network (Pass-2) 570 - Update D.Pri_BW_Restore and D.Pri_BW_Min. 571 - For each corresponding primary path N, 572 - Set "Pri_Igp" -> Interface-group N belongs to. 573 - If protection configured on "Pri_Igp" 574 - If igp.Pri_BW_PostFail < D.Pri_BW_Restore, 575 OR igp.Pri_BW_PostFail <= D.Pri_BW_Min 576 - For all backup paths M, 577 - Set "Alt_Igp" -> Interface-group N belongs to. 578 - Select M for installing in forwarding plane. 579 - If D.Pri_Nh_Count == 0 580 - If Alt_igp.BW_Curr >= D.Pri_BW_Restore, 581 AND Alt_Igp.BW_Curr > D.Pri_BW_Min 582 - Set preference of M to Pri_Nh_Pref. 583 - Else 584 - Set preference of M to Bkup_Nh_Pref_Normal. 585 - Else 586 - If Alt_Igp.BW_Curr >= D.Pri_BW_Restore, 587 AND Alt_Igp.BW_Curr > D.Pri_BW_Min 588 - Set preference of M to Bkup_Nh_Pref_High. 589 - Else 590 - Set preference of M to Bkup_Nh_Pref_Normal. 592 5. Limitations 594 The BBM method proposed in this document does NOT ensure end to end 595 bandwidth requirement. It, only ensures that the metric is altered 596 only on local interfaces, based on the BBM metric configurations and 597 remaining available bandwidth. 599 The solution proposed in this documents attempts to provide 600 protection for single link failures only. It always assumes that 601 link with the highest individual bandwidth capacity shall fail next. 602 In case if any other link with lesser individual bandwidth capacity 603 fails instead, the local repair action taken by the forwarding plane 604 may not be exactly as expected, even though the forwarding plane will 605 still take care of protecting the traffic. 607 6. Security Consideration 609 Changes suggested in the draft does not raise any security concerns. 611 7. IANA Consideration 613 This draft does not have any request from IANA. 615 8. References 617 8.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 8.2. Informative References 626 [I-D.ietf-rtgwg-remote-lfa] 627 Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 628 So, "Remote Loop-Free Alternate (LFA) Fast Re-Route 629 (FRR)", draft-ietf-rtgwg-remote-lfa-11 (work in progress), 630 January 2015. 632 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 633 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 634 DOI 10.17487/RFC5286, September 2008, 635 . 637 Authors' Addresses 639 Santosh Pallagatti (editor) 640 Juniper Networks 641 Embassy Business Park 642 Bangalore, KA 560093 643 India 645 Email: santoshpk@juniper.net 647 Pushpasis Sarkar (editor) 648 Juniper Networks 649 Embassy Business Park 650 Bangalore, KA 560093 651 India 653 Email: psarkar@juniper.net 655 Hannes Gredler 656 Juniper Networks 657 1194 N. Mathilda Ave. 658 Sunnyvale, California 94089-1206 659 USA 661 Email: hannes@juniper.net 663 Stephane Litkowski 664 Orange Business Service 666 Email: stephane.litkowski@orange.com