idnits 2.17.00 (12 Aug 2021) /tmp/idnits16753/draft-papneja-mpls-protection-meth-merge-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.3 on line 26. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 251 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 60 has weird spacing: '... media type ...' == Line 128 has weird spacing: '... The follo...' == Line 130 has weird spacing: '... the failo...' == Line 204 has weird spacing: '... type of f...' == Line 288 has weird spacing: '...failure as w...' == (11 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2006) is 5812 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) -- Missing reference section? 'RFC2119' on line 68 looks like a reference -- Missing reference section? 'IGP-METH' on line 915 looks like a reference -- Missing reference section? 'FRR-METH' on line 910 looks like a reference -- Missing reference section? 'RFC-4090' on line 193 looks like a reference -- Missing reference section? 'MPLS-RSVP' on line 879 looks like a reference -- Missing reference section? 'MPLS-RSVP-TE' on line 883 looks like a reference -- Missing reference section? 'MPLS-FRR-EXT' on line 886 looks like a reference -- Missing reference section? 'TERMID' on line 336 looks like a reference -- Missing reference section? 'MPLS-LDP' on line 875 looks like a reference -- Missing reference section? 'MPLS-ARCH' on line 890 looks like a reference -- Missing reference section? 'RFC-WORDS' on line 894 looks like a reference -- Missing reference section? 'RFC-IANA' on line 898 looks like a reference -- Missing reference section? 'TERM-ID' on line 905 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Papneja 3 Internet Draft Isocore 4 Expires: December 2006 S.Vapiwala 5 J.Karthik 6 Cisco Systems 7 S. Poretsky 8 Reef Point 9 S. Rao 10 Qwest Communications 11 Jean-Louis Le Roux 12 France Telecom 13 June 21, 2006 15 Methodology for benchmarking MPLS Protection mechanisms 16 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that 21 any applicable patent or other IPR claims of which he or she is 22 aware have been or will be disclosed, and any of which he or she 23 becomes aware will be disclosed, in accordance with Section 6 of 24 BCP 79. 26 This document may only be posted in an Internet-Draft. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Poretsky, Rao, Le Roux 45 Protection Mechanisms 47 Abstract 49 This draft provides the methodology for benchmarking MPLS Protection 50 mechanisms especially the failover time of local protection (MPLS Fast 51 Reroute as defined in RFC-4090). The failover to a backup tunnel could 52 happen at the headend of the primary tunnel or a midpoint and the backup 53 could offer link or node protection. It becomes vital to benchmark the 54 failover time for all the cases and combinations. The failover time 55 could also greatly differ based on the design and implementation and by 56 factors like the number of prefixes carried by the tunnel, the routing 57 protocols that installed these prefixes (IGP, BGP...), the number of 58 primary tunnels affected by the event that caused the failover, number 59 of primary tunnels the backup protects and type of failure, the physical 60 media type on which the failover occurs etc. All the required 61 benchmarking criteria and benchmarking topology required for measuring 62 failover time of local protection is described Conventions used in this 63 document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Existing definitions...........................................5 73 3. Test Considerations............................................6 74 3.1. Failover Events...........................................6 75 3.2. Failure Detection [TERMID]................................7 76 3.3. Use of Data Traffic for MPLS Protection Benchmarking......7 77 3.4. LSP and Route Scaling.....................................8 78 3.5. Selection of IGP..........................................8 79 3.6. Reversion [TERMID]........................................8 80 3.7. Traffic generation........................................8 81 3.8. Motivation for topologies.................................9 82 4. Test Setup.....................................................9 83 4.1. Link Protection with 1 hop primary (from PLR) and 1 hop 84 backup.........................................................9 85 TE tunnels.....................................................9 86 4.2. Link Protection with 1 hop primary (from PLR) and 2 hop 87 backup TE tunnels.............................................10 88 4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop 89 backup TE tunnels.............................................10 91 Poretsky, Rao, Le Roux 92 Protection Mechanisms 93 4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop 94 backup TE tunnels.............................................12 95 4.5. Node Protection with 2 hop primary (from PLR) and 1 hop 96 backup TE tunnels.............................................12 97 4.6. Node Protection with 2 hop primary (from PLR) and 2 hop 98 backup TE tunnels.............................................13 99 4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop 100 backup TE tunnels.............................................14 101 4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop 102 backup TE tunnels.............................................15 103 5. Test Methodology..............................................15 104 5.1. Headend as PLR with link failure.........................16 105 5.2. Mid-Point as PLR with link failure.......................17 106 5.3. Headend as PLR with Node failure.........................18 107 5.4. Mid-Point as PLR with Node failure.......................19 108 6. Reporting Format..............................................21 109 7. Security Considerations.......................................22 110 8. Acknowledgements..............................................22 111 9. References....................................................22 112 10. Author's Address.............................................23 113 Appendix A: Fast Reroute Scalability Table.......................25 115 1. Introduction 117 A link or a node failure could occur at the headend or the mid point 118 node of a given primary tunnel. The time it takes to failover to the 119 backup tunnel is a key measurement since it directly affects the traffic 120 carried over the tunnel. The failover could occur at the headend or the 121 midpoint of a primary tunnel and the time it takes to failover depends 122 on a variety of factors like the type of physical media, method of FRR 123 solution (detour vs facility), number of primary tunnels, number of 124 prefixes carried over the tunnel etc. Given all this service providers 125 certainly like to see a methodology to measure the failover time under 126 all possible conditions. 128 The following sections describe all the different topologies and 129 scenarios that should be used and considered to effectively benchmark 130 the failover time. The failure triggers, procedures, scaling 131 considerations and reporting format of the results are discussed as 132 well. 134 Poretsky, Rao, Le Roux 135 Protection Mechanisms 136 In order to benchmark failover time, data plane traffic is used as 137 mentioned in [IGP-METH] since traffic loss is measured in a black-box 138 test and is a widely accepted way to measure convergence. 140 Important point to be noted when benchmarking the failover time is that 141 depending on whether PHP is happening (whether or not implicit null is 142 advertised by the tail-end), and on the number of hops of primary and 143 backup tunnel, we could have different situations where the packets 144 switched over to the backup tunnel may have one, more or 0 labels. 146 All the benchmarking cases mentioned in this document could apply to 147 facility backup as well as local protection enabled in the detour mode. 148 The test cases and the procedures described here should completely 149 benchmark the failover time of a device under test in all possible 150 scenarios and configuration. 152 The additional scenarios defined in this document, are in addition to 153 those considered in [FRR-METH]. All the cases enlisted in this document 154 could be verified in a single topology that is similar to this. 156 --------------------------- 157 | ------------|--------------- 158 | | | | 159 | | | | 160 -------- -------- -------- -------- -------- 161 TG-| R1 |-----| R2 |----| R3 | | R4 | | R5 |-TA 162 | |-----| |----| |----| |---| | 163 -------- -------- -------- -------- -------- 164 | | | | 165 | | | | 166 | -------- | | 167 ---------| R6 |-------- | 168 | |-------------------- 169 -------- 171 Fig.1: Fast Reroute Topology. 173 In figure 1, TG & TA are Traffic Generator & Analyzer respectively. 174 A tester is set outside the node as it sends and receives IP traffic 175 along the working Path, run protocol emulations simulating real world 176 peering scenarios. The tester MUST record the number of lost packets, 178 Poretsky, Rao, Le Roux 179 Protection Mechanisms 180 duplicate packet count, reordered packet count, departure time, and 181 arrival time so that the metrics of Failover Time, Additive Latency, and 182 Reversion Time can be measured. The tester may be a single device or a 183 test system. 185 Two or more failures are considered correlated if those failures occur 186 more or less simultaneously. Correlated failures are often expected 187 where two or more logical resources, such as layer-2 links, rely on a 188 common physical resource, such as common transport. TDM and WDM provide 189 multiplexing at layer-2 and layer-1 that are often the cause of 190 correlated failures. Where such correlations are known, such as knowing 191 that two logical links share a common fiber segment, the expectation of 192 a common failure can be compensated for by specifying Shared Risk Link 193 Groups [RFC-4090]. Not all correlated failures are anticipated in 194 advance of their occurrence. Failures due to natural disasters or due 195 to certain man-made disasters or mistakes are the most notable causes. 196 Failures of this type occur many times a year and generally a quite 197 spectacular failure occurs every few years. 199 There are two factors impacting service availability. One is the 200 frequency of failure. The other is the duration of failure. FRR 201 improves availability by minimizing the duration of the most common 202 failures. Unexpected correlated failures are less common. Some routers 203 recover much more quickly than others and therefore benchmarking this 204 type of failure may also be useful. Benchmarking of unexpected 205 correlated failures should include measurement of restoration with and 206 without the availability of IP fallback. The use BGP free core may be 207 growing, making the latter case an important test case. This document 208 focuses on FRR failover benchmarking with MPLS TE. Benchmarking of 209 unexpected correlated failures is out of scope but may be covered by a 210 later document. 212 2. Existing definitions 214 For the sake of clarity and continuity this RFC adopts the template 215 for definitions set out in Section 2 of RFC 1242. Definitions are 216 indexed and grouped together in sections for ease of reference. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 221 Poretsky, Rao, Le Roux 222 Protection Mechanisms 223 this document are to be interpreted as described in RFC 2119. 225 The reader is assumed to be familiar with the commonly used MPLS 226 terminology, some of which is defined in [MPLS-RSVP], [MPLS-RSVP-TE], 227 and [MPLS-FRR-EXT]. 229 3. Test Considerations 231 This section discusses the fundamentals of MPLS Protection testing: 233 -The types of network events that causes failover 234 -Indications for failover 235 -the use of data traffic 236 -Traffic generation 237 -LSP Scaling 238 -Reversion of LSP 239 -IGP Selection 241 3.1. Failover Events 243 Triggers for failover to a backup tunnel are link and node failures 244 seen downstream of the PLR as follows. 246 Link failure events 248 - Shutdown interface on PLR side with POS Alarm 249 - Shutdown interface on remote side with POS Alarm 250 - Shutdown interface on PLR side with RSVP hello 251 - Shutdown interface on remote side with RSVP hello 252 - Shutdown interface on PLR side with BFD 253 - Shutdown interface on remote side with BFD 254 - Fiber Pull on PLR side (Both TX & RX or just the Tx) 255 - Fiber Pull on remote side (Both TX & RX or just the Rx) 256 - OIR on PLR side 257 - OIR on remote side 258 - Sub-interface failure (shutting down of a VLAN) 259 - Interface bearing multiple sub-interfaces 261 Node failure events 262 A Reload is a graceful shutdown or a power failure. We refer to Crash 263 as a software failure or an assert. 265 Poretsky, Rao, Le Roux 266 Protection Mechanisms 268 - Reload protected Node, when RSVP Hello are enable 269 - Crash Protected Node, when RSVP Hello are enable 270 - Reload Protected Node, when BFD is enable 271 - Crash Protected Node, when BFD is enable 273 3.2. Failure Detection [TERMID] 275 Local failures can be detected via SONET/SDH failure with directly 276 connected LSR. Failure indication may vary with the type of alarm - 277 LOS, AIS, or RDI. Failures on Ethernet technology links such as 278 Gigabit Ethernet rely upon Layer 3 signaling indication for failure. 280 Different MPLS protection mechanisms and different implementations 281 use different failure indications such as RSVP hellos, BFD etc. 282 Ethernet technologies such as Gigabit Ethernet rely upon layer 3 283 failure indication mechanisms since there is no Layer 2 failure 284 indication mechanism. The failure detection time may not always be 285 negligible and it could impact the overall failover time. 287 The test procedures in this document can be used against a local 288 failure as well as against a remote failure to account for 289 completeness of benchmarking and to evaluate failover performance 290 independent of the implemented signaling indication mechanism. 292 3.3. Use of Data Traffic for MPLS Protection Benchmarking 294 Customers of service providers use packet loss as the metric for 295 failover time. Packet loss is an externally observable event having 296 direct impact on customers' application performance. MPLS protection 297 mechanism is expected to minimize the packet loss in the event of a 298 failure. For this reason it is important to develop a standard router 299 benchmarking methodology for measuring MPLS protection that uses 300 packet loss as a metric. At a known rate for forwarding, packet loss 301 can be measured and used to calculate the Failover time. Measurement 302 of control plane signaling to establish backup paths is not enough 303 to verify failover. Failover is best determined when packets are 304 actually traversing the backup path. 306 An additional benefit of using packet loss for calculation of 307 Failover time is that it enables black-box tests to be designed. Data 308 traffic can be offered at line-rate to the device under test (DUT), 309 an emulated network event as described above can be forced to occur, 311 Poretsky, Rao, Le Roux 312 Protection Mechanisms 313 and packet loss can be externally measured to calculate the 314 convergence time. Knowledge of DUT architecture is not required. 315 There is no need to rely on the understanding of the implementation 316 details of the DUT to get the required test results. 318 In addition, this methodology will consider the errored packets and 319 duplicate packets that could have been generated during the failover 320 process. In extreme cases, where measurement of errored and duplicate 321 packets is difficult, these packets could be attributed to lost 322 packets. 324 3.4. LSP and Route Scaling 326 Failover time performance may vary with the number of established 327 primary and backup LSPs and routes learned. However the procedure 328 outlined here may be used for any number of LSPs, L, and number of 329 routes, R. L and R must be recorded. 331 3.5. Selection of IGP 333 The underlying IGP could be ISIS-TE or OSPF-TE for the methodology 334 proposed here. 336 3.6. Reversion [TERMID] 338 Fast Reroute provides a method to return or restore a backup path to 339 original primary LSP upon recovery from the failure. This is referred 340 to as Reversion, which can be implemented as Global Reversion or 341 Local Reversion. In all test cases listed here Reversion should not 342 produce any packet loss, out of order or duplicate packets. Each of 343 the test cases in this methodology document provides a step to verify 344 that there is no packet loss. 346 3.7. Traffic generation 348 It is suggested that there be one or more traffic streams as long as 349 there is a steady and constant rate of flow for all the streams. In 350 order to monitor the DUT performance for recovery times a set of 351 route prefixes should be advertised before traffic is sent. The 352 traffic should be configured towards these routes. 354 A typical example would be configuring the traffic generator to send 355 the traffic to the first, middle and last of the advertised routes. 356 (First, middle and last could be decided by the numerically smallest, 357 median and the largest respectively of the advertised prefix). 358 Generating traffic to all of the prefixes reachable by the protected 360 Poretsky, Rao, Le Roux 361 Protection Mechanisms 362 tunnel (probably in a Round-Robin fashion, where the traffic is 363 destined to all the prefixes but one prefix at a time in a cyclic 364 manner) is not recommended. 366 3.8. Motivation for topologies 368 Given that the label stack is dependent on the following 3 entities 369 it is recommended that the benchmarking of failover time be performed 370 on all the 8 topologies enlisted in section 4 372 - Type of protection (Link Vs Node) 374 - # of remaining hops of the primary tunnel from the PLR 376 - # of remaining hops of the backup tunnel from the PLR 378 4. Test Setup 380 Topologies to be used for benchmarking the failover time: 382 This section proposes a set of topologies that covers the scenarios 383 for local protection. All of these 8 topologies shown (figure 2- 384 figure 9) can be mapped to the master FRR topology shown in figure 1. 385 Topologies shown in section 4.1 to 4.8 refer to the network 386 topologies required to benchmark failover time when DUT is configured 387 as a PLR either in headend or midpoint role. The number of labels 388 listed below are all w.r.t the PLR. 390 The label stacks shown below each figure in section 4.1 to 4.9 391 considers the scenario when PHP is enabled. 393 4.1. Link Protection with 1 hop primary (from PLR) and 1 hop backup 395 TE tunnels 397 ------- -------- P -------- 398 | R1 | R2 | | R3 | 399 TG-|Ingress|--| Mid-pt |----| Egress |-TA 400 | | | DUT/PLR|----| Node | 401 ------- -------- B -------- 402 Figure 10: Represents the setup for section 4.1 404 Traffic No of Labels No of labels after 405 before failure failure 407 Poretsky, Rao, Le Roux 409 Protection Mechanisms 410 IP TRAFFIC (P-P) 0 0 411 Layer3 VPN (PE-PE) 1 1 412 Layer3 VPN (PE-P) 2 2 413 Layer2 VC (PE-PE) 1 1 414 Layer2 VC (PE-P) 2 2 415 Mid-point LSPs 0 0 417 4.2. Link Protection with 1 hop primary (from PLR) and 2 hop backup TE 418 tunnels 420 ------- -------- -------- 421 | R1 | R2 | | R3 | 422 TG-|Ingress| | Mid-pt | P |Egress |-TA 423 | |----| DUT/PLR|----| Node | 424 ------- -------- -------- 425 |B | 426 | -------- | 427 | | R6 | | 428 |----|Backup |----| 429 |Midpoint| 430 -------- 431 Figure 11: Representing setup for section 4.2 433 Traffic No of Labels No of labels 434 before failure after failure 435 IP TRAFFIC (P-P) 0 1 436 Layer3 VPN (PE-PE) 1 2 437 Layer3 VPN (PE-P) 2 3 438 Layer2 VC (PE-PE) 1 2 439 Layer2 VC (PE-P) 2 3 440 Mid-point LSPs 0 1 442 4.3. Link Protection with 2+ hop (from PLR) primary and 1 hop backup TE 443 tunnels 445 -------- -------- -------- -------- 446 | R1 | | R2 | P | R3 | P | R4 | 447 TG-|Ingress |----| Mid-pt |----| Midpt |------| Egress |-TA 449 Poretsky, Rao, Le Roux 450 Protection Mechanisms 451 | | | DUT/PLR|----| Node | | Node | 452 -------- -------- B -------- -------- 453 Figure 12: Representing setup for section 4.3 455 Traffic No of Labels No of labels 456 before failure after failure 458 IP TRAFFIC (P-P) 1 1 459 Layer3 VPN (PE-PE) 2 2 460 Layer3 VPN (PE-P) 3 3 461 Layer2 VC (PE-PE) 2 2 462 Layer2 VC (PE-P) 3 3 463 Mid-point LSPs 1 1 465 Poretsky, Rao, Le Roux 466 Protection Mechanisms 468 4.4. Link Protection with 2+ hop (from PLR) primary and 2 hop backup TE 469 tunnels 471 -------- -------- P -------- P -------- 472 | R1 | | R2 | | R3 | | R4 | 473 TG-|Ingress |----| Mid-pt |----|Midpt |------| Egress |-TA 474 | | | DUT/PLR| | Node | | Node | 475 -------- -------- -------- -------- 476 B| | 477 | -------- | 478 | | R6 | | 479 ---|Backup |- 480 |Midpoint| 481 -------- 482 Figure 13: Representing the setup for section 4.4 484 Traffic No of Labels No of labels 485 before failure after failure 487 IP TRAFFIC (P-P) 1 2 488 Layer3 VPN (PE-PE) 2 3 489 Layer3 VPN (PE-P) 3 4 490 Layer2 VC (PE-PE) 2 3 491 Layer2 VC (PE-P) 3 4 492 Mid-point LSPs 1 2 494 4.5. Node Protection with 2 hop primary (from PLR) and 1 hop backup TE 495 tunnels 497 -------- -------- P -------- P -------- 498 | R1 | | R2 | | R3 | | R4 | 499 TG-|Ingress |----| Mid-pt |----|Midpt |------| Egress |-TA 500 | | | DUT/PLR| | Node | | Node | 501 -------- -------- -------- -------- 502 B| | 503 ----------------------------- 504 Figure 14: Representing the setup for section 4.5 506 Poretsky, Rao, Le Roux 507 Protection Mechanisms 508 Traffic No of Labels No of labels 509 before failure after failure 511 IP TRAFFIC (P-P) 1 0 512 Layer3 VPN (PE-PE) 2 1 513 Layer3 VPN (PE-P) 3 2 514 Layer2 VC (PE-PE) 2 1 515 Layer2 VC (PE-P) 3 2 516 Mid-point LSPs 1 0 518 4.6. Node Protection with 2 hop primary (from PLR) and 2 hop backup TE 519 tunnels 521 -------- -------- -------- -------- 522 | R1 | | R2 | | R3 | | R4 | 523 G-|Ingress | | Mid-pt | P |MidPoint| P | Egress |-TA 524 | |----| DUT/PLR|----| Node |----| Node | 525 -------- -------- -------- -------- 526 | | 527 B | -------- | 528 | | R6 | | 529 ---------|Backup |--------- 530 |Midpoint| 531 -------- 532 Figure 15: Representing setup for section 4.6 534 Traffic No of Labels No of labels 535 before failure after failure 537 IP TRAFFIC (P-P) 1 1 538 Layer3 VPN (PE-PE) 2 2 539 Layer3 VPN (PE-P) 3 3 540 Layer2 VC (PE-PE) 2 2 541 Layer2 VC (PE-P) 3 3 542 Mid-point LSPs 1 1 544 Poretsky, Rao, Le Roux 545 Protection Mechanisms 546 4.7. Node Protection with 3+ hop primary (from PLR) and 1 hop backup TE 547 tunnels 549 -------- -------- P -------- P -------- P -------- 550 | R1 | | R2 | | R3 | | R4 | | R5 | 551 TG-| Ingress|--| Mid-pt |---|Midpt |---| Merge |---| Egress |-TA 552 | | | DUT/PLR| | Node | | Node | | Node | 553 -------- -------- -------- -------- -------- 554 B | | 555 -------------------------- 556 Figure 16: Representing setup for section 4.7 558 Traffic No of Labels No of labels 559 before failure after failure 561 IP TRAFFIC (P-P) 1 1 562 Layer3 VPN (PE-PE) 2 2 563 Layer3 VPN (PE-P) 3 3 564 Layer2 VC (PE-PE) 2 2 565 Layer2 VC (PE-P) 3 3 566 Mid-point LSPs 1 1 568 Poretsky, Rao, Le Roux 569 Protection Mechanisms 571 4.8. Node Protection with 3+ hop primary (from PLR) and 2 hop backup 572 TE tunnels 574 -------- -------- -------- -------- -------- 575 | R1 | | R2 | | R3 | | R4 | | R5 | 576 TG-|Ingress | | Mid-pt | P |MidPoint|P | Merge | P | Egress |-TA 577 | |-- | DUT/PLR|---| Node |---| Node |---| Node | 578 -------- -------- -------- -------- -------- 579 B | | 580 | -------- | 581 | | R6 | | 582 ---------|Backup |------- 583 |Midpoint| 584 -------- 585 Figure 17: Representing setup for section 4.8 587 Traffic No of Labels No of labels 588 before failure after failure 590 IP TRAFFIC (P-P) 1 2 591 Layer3 VPN (PE-PE) 2 3 592 Layer3 VPN (PE-P) 3 4 593 Layer2 VC (PE-PE) 2 3 594 Layer2 VC (PE-P) 3 4 595 Any 1 2 597 5. Test Methodology 599 The procedure described in this section can be applied to all the 8 600 base test cases and the associated topologies. The backup as well as 601 the primary tunnel are configured to be alike in terms of any lsp 602 attributes or resources such as bandwidth. In order to benchmark 603 failover with all possible label stack depth applicable as seen with 604 current deployments, it is suggested that the methodology includes 605 all the scenarios listed here 607 Poretsky, Rao, Le Roux 608 Protection Mechanisms 609 5.1. Headend as PLR with link failure 611 Objective 613 To benchmark the MPLS failover time due to Link failure events 614 described in section 3.1 experienced by the DUT which is the point 615 of local repair (PLR). 617 Test Setup 619 - select any one topology out of 8 from section 4 620 - select overlay technology for FRR test e.g IGP,VPN,or VC 621 - The DUT will also have 2 interfaces connected to the traffic 622 Generator/analyzer. (If the node downstream of the PLR is not 623 A simulated node, then the Ingress of the tunnel should have 624 one link connected to the traffic generator and the node 625 downstream to the PLR or the egress of the tunnel should have 626 a link connected to the traffic analyzer). 628 Test Configuration 630 1. Configure the number of primaries on R2 and the backups on 631 R2 as required by the topology selected. 632 2. Advertise prefixes (as per FRR Scalability table describe in 633 Appendix A) by the tail end. 635 Procedure 637 1. Establish the primary lsp on R2 required by the topology 638 selected 639 2. Establish the backup lsp on R2 required by the selected 640 topology 641 3. Verify primary and backup lsps are up and that primary is 642 protected 643 4. Verify Fast Reroute protection 644 5. Setup traffic streams as described in section 3.7 645 6. Send IP traffic at maximum Forwarding Rate to DUT. 646 7. Verify traffic switched over Primary LSP. 647 8. Trigger any choice of Link failure as describe in section 648 3.1 650 Poretsky, Rao, Le Roux 651 Protection Mechanisms 652 9. Verify that primary tunnel and prefixes gets mapped to 653 backup tunnels 654 10. Stop traffic stream and measure the traffic loss. 655 11. Failover time is calculated as per defined in section 6, 656 Reporting format. 657 12. Start traffic stream again to verify reversion when 658 protected interface comes up. Traffic loss should be 0 due 659 to make before break or reversion. 660 13. Enable protected interface that was down (Node in the case 661 of NNHOP) 662 14. Verify head-end signals new LSP and protection should be in 663 place again 665 5.2. Mid-Point as PLR with link failure 667 Objective 669 To benchmark the MPLS failover time due to Link failure events 670 described in section 3.1 experienced by the device under test which 671 is the point of local repair (PLR). 673 Test Setup 675 - select any one topology out of 8 from section 4 676 - select overlay technology for FRR test as Mid-Point lsps 677 - The DUT will also have 2 interfaces connected to the traffic 678 generator. 680 Test Configuration 682 1. Configure the number of primaries on R1 and the backups on 683 R2 as required by the topology selected 684 2. Advertise prefixes (as per FRR Scalability table describe in 685 Appendix A) by the tail end. 687 Procedure 689 1. Establish the primary lsp on R1 required by the topology 690 selected 692 Poretsky, Rao, Le Roux 693 Protection Mechanisms 694 2. Establish the backup lsp on R2 required by the selected 695 topology 696 3. Verify primary and backup lsps are up and that primary is 697 protected 698 4. Verify Fast Reroute protection 699 5. Setup traffic streams as described in section 3.7 700 6. Send IP traffic at maximum Forwarding Rate to DUT. 701 7. Verify traffic switched over Primary LSP. 702 8. Trigger any choice of Link failure as describe in section 703 3.1 704 9. Verify that primary tunnel and prefixes gets mapped to 705 backup tunnels 706 10. Stop traffic stream and measure the traffic loss. 707 11. Failover time is calculated as per defined in section 6, 708 Reporting format. 709 12. Start traffic stream again to verify reversion when 710 protected interface comes up. Traffic loss should be 0 due 711 to make before break or reversion 712 13. Enable protected interface that was down (Node in the case 713 of NNHOP) 714 14. Verify head-end signals new LSP and protection should be in 715 place again 717 5.3. Headend as PLR with Node failure 719 Objective 721 To benchmark the MPLS failover time due to Node failure events 722 described in section 3.1 experienced by the device under test which 723 is the point of local repair (PLR). 725 Test Setup 727 - select any one topology from section 4.5 to 4.8 728 - select overlay technology for FRR test e.g IGP,VPN,or VC 729 - The DUT will also have 2 interfaces connected to the traffic 730 generator. 732 Test Configuration 734 Poretsky, Rao, Le Roux 735 Protection Mechanisms 736 1. Configure the number of primaries on R2 and the backups on 737 R2 as required by the topology selected 738 2. Advertise prefixes (as per FRR Scalability table describe in 739 Appendix A) by the tail end. 741 Procedure 743 1. Establish the primary lsp on R2 required by the topology 744 selected 745 2. Establish the backup lsp on R2 required by the selected 746 topology 747 3. Verify primary and backup lsps are up and that primary is 748 protected 749 4. Verify Fast Reroute protection 750 5. Setup traffic streams as described in section 3.7 751 6. Send IP traffic at maximum Forwarding Rate to DUT. 752 7. Verify traffic switched over Primary LSP. 753 8. Trigger any choice of Node failure as describe in section 754 3.1 755 9. Verify that primary tunnel and prefixes gets mapped to 756 backup tunnels 757 10. Stop traffic stream and measure the traffic loss. 758 11. Failover time is calculated as per defined in section 6, 759 Reporting format. 760 12. Start traffic stream again to verify reversion when 761 protected interface comes up. Traffic loss should be 0 due 762 to make before break or reversion 763 13. Boot protected Node that was down. 764 14. Verify head-end signals new LSP and protection should be in 765 place again 767 5.4. Mid-Point as PLR with Node failure 769 Objective 771 To benchmark the MPLS failover time due to Node failure events 772 described in section 3.1 experienced by the device under test which 773 is the point of local repair (PLR). 775 Poretsky, Rao, Le Roux 776 Protection Mechanisms 777 Test Setup 779 - select any one topology from section 4.5 to 4.8 780 - select overlay technology for FRR test as Mid-Point lsps 781 - The DUT will also have 2 interfaces connected to the traffic 782 generator. 784 Test Configuration 786 1. Configure the number of primaries on R1 and the backups on 787 R2 as required by the topology selected 788 2. Advertise prefixes (as per FRR Scalability table describe in 789 Appendix A) by the tail end. 791 Procedure 793 1. Establish the primary lsp on R1 required by the topology 794 selected 795 2. Establish the backup lsp on R2 required by the selected 796 topology 797 3. Verify primary and backup lsps are up and that primary is 798 protected 799 4. Verify Fast Reroute protection 800 5. Setup traffic streams as described in section 3.7 801 6. Send IP traffic at maximum Forwarding Rate to DUT. 802 7. Verify traffic switched over Primary LSP. 803 8. Trigger any choice of Node failure as describe in section 804 3.1 805 9. Verify that primary tunnel and prefixes gets mapped to 806 backup tunnels 807 10. Stop traffic stream and measure the traffic loss. 808 11. Failover time is calculated as per defined in section 6, 809 Reporting format. 810 12. Start traffic stream again to verify reversion when 811 protected interface comes up. Traffic loss should be 0 due 812 to make before break or reversion 813 13. Boot protected Node that was down 814 14. Verify head-end signals new LSP and protection should be in 815 place again 817 Poretsky, Rao, Le Roux 818 Protection Mechanisms 820 6. Reporting Format 822 For each test, it is recommended that the results be reported in the 823 following format. 825 Parameter Units 827 IGP used for the test ISIS-TE/ OSPF-TE 828 Interface types Gige,POS,ATM,VLAN etc. 829 Packet Sizes offered to the DUT Bytes 830 IGP routes advertised number of IGP routes 831 RSVP hello timers configured (if any) milliseconds 832 Number of FRR tunnels configured number of tunnels 833 Number of VPN routes in head-end number of VPN routes 834 Number of VC tunnels number of VC tunnels 835 Number of BGP routes number of BGP routes 836 Number of mid-point tunnels number of tunnels 838 Benchmarks 840 Minimum failover time milliseconds 841 Mean failover time milliseconds 842 Maximum failover time milliseconds 843 Minimum reversion time milliseconds 844 Mean reversion time milliseconds 845 Maximum reversion time milliseconds 847 Failover time suggested above is calculated using the following 848 formula: (Numbers of packet drop/rate per second * 1000) milliseconds 850 Note: If the primary is configured to be dynamic, and if the primary 851 is to reroute, make before break should occur from the backup that is 852 in use to a new alternate primary. If there is any packet loss seen, 853 it should be added to failover time. 855 Poretsky, Rao, Le Roux 856 Protection Mechanisms 857 7. Security Considerations 859 Documents of this type do not directly affect the security of 860 the Internet or of corporate networks as long as benchmarking 861 is not performed on devices or systems connected to operating 862 networks. 864 8. Acknowledgements 866 We would like to thank Jean Philip Vasseur for his invaluable input 867 to the document and Curtis Villamizar his contribution in suggesting 868 text on definition and need for benchmarking Correlated failures. 870 Additionally we would like to thank Arun Gandhi, Amrit Hanspal, Karu 871 Ratnam and for their input to the document. 873 9. References 875 [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., 876 Fredette, A. and B. Thomas, "LDP Specification", 877 RFC 3036, January 2001. 879 [MPLS-RSVP] R. Braden, Ed., et al, "Resource ReSerVation 880 protocol (RSVP) -- version 1 functional 881 specification," RFC2205, September 1999. 883 [MPLS-RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to 884 RSVP for LSP Tunnels", RFC3209, December 2001. 886 [MPLS-FRR-EXT] Pan, P., Atlas, A., Swallow, G., 887 "Fast Reroute Extensions to RSVP-TE for LSP 888 Tunnels", RFC 4090. 890 [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, 891 "Multiprotocol Label Switching Architecture", 892 RFC 3031, January 2001. 894 [RFC-WORDS] Bradner, S., "Key words for use in RFCs to 895 Indicate Requirement Levels", RFC 2119, 896 March 1997. 898 [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for 900 Poretsky, Rao, Le Roux 901 Protection Mechanisms 902 Writing an IANA Considerations Section in RFCs", 903 RFC 2434. 905 [TERM-ID] Poretsky, S., Papneja, R., Kimura, T., 906 "Benchmarking Terminology for Protection 907 Performance", draft-poretsky-protection-term- 908 00.txt, work in progress. 910 [FRR-METH] Poretsky, S., Papneja, R., Rao, S., Le Roux, JL. 911 "Benchmarking Methodology for MPLS Protection 912 Mechanisms,"draft-poretsky-mpls-protection-meth- 913 04.txt,” work in progress. 915 [IGP-METH] S. Poretsky, B. Imhoff. "Benchmarking Methodology 916 for IGP Data Plane Route Convergence," draft-ietf- 917 bmwg-igp-dataplane-conv-meth-11.txt,” work in 918 progress. 920 10. Author's Address 922 Rajiv Papneja 923 Isocore 924 12359 Sunrise Valley Drive, STE 100 925 Reston, VA 20190 926 USA 927 Phone: +1 703 860 9273 928 Email: rpapneja@isocore.com 930 Samir Vapiwala 931 Cisco System 932 300 Beaver Brook Road 933 Boxborough, MA 01719 934 USA 935 Phone: +1 978 936 1484 936 Email: svapiwal@cisco.com 938 Jay Karthik 939 Cisco System 940 300 Beaver Brook Road 941 Boxborough, MA 01719 943 Poretsky, Rao, Le Roux 944 Protection Mechanisms 945 USA 946 Phone: +1 978 936 0533 947 Email: jkarthik@cisco.com 949 Scott Poretsky 950 Reef Point Systems 951 8 New England Executive Park 952 Burlington, MA 01803 953 USA 954 Phone: + 1 781 395 5090 955 EMail: sporetsky@reefpoint.com 957 Shankar Rao 958 Qwest Communications, 959 950 17th Street 960 Suite 1900 961 Qwest Communications 962 Denver, CO 80210 963 USA 964 Phone: + 1 303 437 6643 965 Email: shankar.rao@qwest.com 967 Jean-Louis Le Roux 968 France Telecom 969 2 av Pierre Marzin 970 22300 Lannion 971 France 972 Phone: 00 33 2 96 05 30 20 973 Email: jeanlouis.leroux@orange-ft.com 975 Full Copyright Statement 977 Copyright (C) The Internet Society (2006). 979 This document is subject to the rights, licenses and restrictions 980 contained in BCP 78, and except as set forth therein, the authors 981 retain all their rights. 983 This document and the information contained herein are provided on an 985 Poretsky, Rao, Le Roux 986 Protection Mechanisms 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Intellectual Property 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; nor does it represent that it has 1000 made any independent effort to identify any such rights. Information 1001 on the procedures with respect to rights in RFC documents can be 1002 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at ietf- 1014 ipr@ietf.org. 1016 Acknowledgement 1017 Funding for the RFC Editor function is currently provided by the 1018 Internet Society. 1020 Appendix A: Fast Reroute Scalability Table 1022 This section provides the recommended numbers for evaluating the 1023 scalability of fast reroute implementations. It also recommends the 1024 typical numbers for IGP/VPNv4 Prefixes, LSP Tunnels and VC entries. 1026 Poretsky, Rao, Le Roux 1027 Protection Mechanisms 1028 Based on the features supported by the device under test, appropriate 1029 scaling limits can be used for the test bed. 1031 A 1. FRR IGP Table 1033 No of Headend IGP Prefixes 1034 TE LSPs 1035 1 100 1036 1 500 1037 1 1000 1038 1 2000 1039 1 5000 1040 2(Load Balance) 100 1041 2(Load Balance) 500 1042 2(Load Balance) 1000 1043 2(Load Balance) 2000 1044 2(Load Balance) 5000 1045 100 100 1046 500 500 1047 1000 1000 1048 2000 2000 1050 A 2. FRR VPN Table 1052 No of Headend VPNv4 Prefixes 1053 TE LSPs 1055 1 100 1056 1 500 1057 1 1000 1058 1 2000 1059 1 5000 1060 1 10000 1061 1 20000 1062 1 Max 1063 2(Load Balance) 100 1064 2(Load Balance) 500 1065 2(Load Balance) 1000 1066 2(Load Balance) 2000 1067 2(Load Balance) 5000 1069 Poretsky, Rao, Le Roux 1070 Protection Mechanisms 1071 2(Load Balance) 10000 1072 2(Load Balance) 20000 1073 2(Load Balance) Max 1075 A 3. FRR Mid-Point LSP Table 1077 No of Mid-point TE LSps could be configured at the following 1078 recommended levels 1079 100 1080 500 1081 1000 1082 2000 1083 Max supported number 1085 A 4. FRR VC Table 1087 No of Headend VC entries 1088 TE LSPs 1090 1 100 1091 1 500 1092 1 1000 1093 1 2000 1094 1 Max 1095 100 100 1096 500 500 1097 1000 1000 1098 2000 2000 1100 Appendix B: Abbreviations 1102 BFD - Bidirectional Fault Detection 1103 BGP - Border Gateway protocol 1104 CE - Customer Edge 1105 DUT - Device Under Test 1106 FRR - Fast Reroute 1107 IGP - Interior Gateway Protocol 1108 IP - Internet Protocol 1109 LSP - Label Switched Path 1110 MP - Merge Point 1112 Poretsky, Rao, Le Roux 1113 Protection Mechanisms 1114 MPLS - Multi Protocol Label Switching 1115 N-Nhop - Next - Next Hop 1116 Nhop - Next Hop 1117 OIR - Online Insertion and Removal 1118 P - Provider 1119 PE - Provider Edge 1120 PHP - Penultimate Hop Popping 1121 PLR - Point of Local Repair 1122 RSVP - Resource reSerVation Protocol 1123 SRLG - Shared Risk Link Group 1124 TA - Traffic Analyzer 1125 TE - Traffic Engineering 1126 TG - Traffic Generator 1127 VC - Virtual Circuit 1128 VPN - Virtual Private Network 1130 Poretsky, Rao, Le Roux