idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. 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 226 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (December 2003) is 7431 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? '1' on line 459 looks like a reference -- Missing reference section? '2' on line 463 looks like a reference -- Missing reference section? '3' on line 467 looks like a reference -- Missing reference section? '4' on line 470 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: December 2003 4 Scott Poretsky 5 Avici Systems 7 Brent Imhoff 8 Wiltel Communications 10 June 2003 12 Benchmarking Methodology for 13 IGP Data Plane Route Convergence 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Table of Contents 40 1. Introduction ...............................................2 41 2. Existing definitions .......................................2 42 3. Test Setup..................................................2 43 3.1 Test Topologies............................................2 44 3.2 Test Considerations........................................3 45 4. Test Cases..................................................4 46 4.1 Local Events...............................................4 47 4.1.1 Convergence Due to SONET Link Failure....................4 48 4.1.2 Convergence Due to PPP Session Failure...................5 49 4.1.3 Convergence Due to IGP Adjacency Failure.................5 50 4.1.4 Convergence Due to Route Withdrawal......................6 51 4.1.5 Convergence Due to Cost Change...........................7 52 4.2 Remote Events..............................................7 53 4.2.1 Convergence Due to Remote SONET Link Failure.............7 54 IGP Data Plane Route Convergence 56 5. Measuring Convergence Times.................................8 57 5.1 Measuring Peak-to-Peak Convergence Time....................8 58 5.2 Measuring Impact of Components for Convergence.............8 59 6. Security Considerations.....................................9 60 7. Acknowledgements............................................9 61 8. References..................................................9 62 9. Author's Address............................................9 63 10. Full Copyright Statement...................................10 65 1. Introduction 66 This draft describes the methodology for benchmarking IGP Route 67 Convergence. The applicability of this testing is described in 68 [1] and the new terminology that it introduces is defined in [2]. 69 Service Providers use IGP Convergence time as a key metric of 70 router design and architecture. Customers of Service Providers 71 observe convergence time by packet loss. IGP Route Convergence 72 is a Direct Measure of Quality (DMOQ) when benchmarking the data 73 plane and not the control plane. The test cases in this document 74 are black-box tests that emulate the network events that cause 75 route convergence, as described in [1]. Black-box test design 76 accounts for all of the factors for route convergence time, as 77 provided in [1]. The methodology and terminology is to be used 78 for benchmarking route convergence and can be applied to any 79 link-state IGP such as ISIS [3] and OSPF [4]. 81 2. Existing definitions 83 For the sake of clarity and continuity this RFC adopts the template 84 for definitions set out in Section 2 of RFC 1242. Definitions are 85 indexed and grouped together in sections for ease of reference. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 89 this document are to be interpreted as described in RFC 2119. 91 3. Test Setup 92 3.1 Test Topologies 94 --------- Ingress Traffic Path --------- 95 | |<------------------------------| | 96 | | | | 97 | | Preferred Egress Path | | 98 | DUT |------------------------------>|Tester | 99 | | | | 100 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 101 | | Backup Egress Path | | 102 --------- --------- 104 Figure 1. IGP Route Convergence Test Topology 105 for Local Changes 106 IGP Data Plane Route Convergence 108 Figure 1 shows the test topology to measure IGP Route Convergence due 109 to local changes such as SONET Link Failure, PPP Session Failure, IGP 110 Adjacency Failure, Route Withdrawal, and Route cost change. These 111 test cases are described in section 4.1. These test cases provide 112 IGP Route Convergence times that consider the Event Detection time, 113 SPF Processing time, and FIB Update time. These times are measured 114 by observing packet loss in the data plane. Physical Links may be of 115 any type, such as Sonet or Ethernet, and any speed. 117 Figure 2 shows the test topology to measure IGP Route Convergence 118 time due to remote changes in the network topology. These times are 119 measured by observing packet loss in the data plane. Physical Links 120 may be of any type, such as Sonet or Ethernet, and any speed. In this 121 topology, the three routers are considered a System Under Test (SUT). 122 Application of this topology and test cases described in section 4.2 123 account for the impact of IGP Advertisement on Route Convergence, as 124 described in [1]. 126 ----- ----------- 127 | | Preferred | | 128 ----- |R2 |------------->| | 129 | |---->| | Egress Path | | 130 | | ----- | | 131 |R1 | | Tester | 132 | | ----- | | 133 | |---->| | Backup | | 134 ----- |R3 |~~~~~~~~~~~~~>| | 135 ^ | | Egress Path | | 136 | ----- ----------- 137 | | 138 |-------------------------------- 139 Ingress Traffic Path 141 Figure 2. IGP Route Convergence Test Topology 142 for Remote Changes 144 3.2 Test Considerations 146 3.2.1 IGP Selection 147 The test cases described in section 4 can be used for ISIS or 148 OSPF. The Route Convergence test methodology for both is 149 identical. The IGP adjacencies are established on the Preferred 150 Egress Path and Backup Egress Path. 152 3.2.2 BGP Configuration 153 The obtained results for IGP Route Convergence may vary if 154 BGP routes are installed. For results similar to those that 155 would be observed in an operational network it is recommended 156 that a BGP session be established on the Ingress Traffic Path 157 with routes installed. 159 IGP Data Plane Route Convergence 161 3.2.3 IGP Route Scaling 162 The number of IGP routes will impact the measured IGP Route 163 Convergence because convergence for the entire IGP route table is 164 measured. For results similar to those that would be observed in 165 an operational network it is recommended that the number of 166 installed routes closely approximate that for routers in the 167 network. 169 3.2.4 BGP Route Scaling 170 The number of installed BGP routes may impact the IGP Convergence 171 time. For results similar to those that would be observed in an 172 operational Network it is recommended that the number of installed 173 routes closely approximate that for routers in the network. 175 3.2.5 Timers 176 There are some timers that will impact the measured IGP Convergence 177 time. The following timers should be configured to the minimum value 178 prior to beginning execution of the test cases: 179 SONET Failure Indication Delay 180 IGP Hello Timer 181 IGP Dead-Interval 182 LSA Generation Delay 183 LSA Flood Packet Pacing 184 LSA Retransmission Packet Pacing 185 SPF Delay 187 4. Test Cases 188 4.1 Local Events 189 The test cases in this section use the test topology shown in 190 Figure 1. 192 4.1.1 Convergence Due to Local SONET Link Failure 193 Objective 194 To obtain the IGP Route Convergence due to a Local SONET Link 195 failure event. 197 Procedure 198 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 199 Path. 200 2. Advertise matching IGP routes from Tester to DUT on 201 Preferred Egress Path and Backup Egress Path. Set the cost 202 of the routes so that the IGP routes along the Preferred 203 Egress Path is the preferred next-hop. 204 3. Send traffic at maximum forwarding rate to destinations 205 matching all IGP routes from Tester to DUT on Ingress Traffic 206 Path. 207 4. Verify traffic routed over Preferred Egress Path. 208 5. Remove SONET on Tester Interface connected to Preferred Egress 209 Path. 210 6. Measure Peak-to-Peak Convergence Time [2] as DUT detects 211 the link down event and converges all IGP routes and 212 traffic over the Backup Egress Path. 214 IGP Data Plane Route Convergence 216 Results 217 The measured IGP Convergence time is influenced by the Local 218 SONET indication, SPF delay, SPF Holdtime, SPF Execution 219 Time, Tree Build Time, and Hardware Update Time. 221 4.1.2 Convergence Due to PPP Session Failure 223 Objective 224 To obtain the IGP Route Convergence due to a Local PPP Session 225 failure event. 227 Procedure 228 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 229 Path. 230 2. Advertise matching IGP routes from Tester to DUT on 231 Preferred Egress Path and Backup Egress Path. Set the cost 232 of the routes so that the IGP routes along the Preferred 233 Egress Path is the preferred next-hop. 234 3. Send traffic at maximum forwarding rate to destinations 235 matching all IGP routes from Tester to DUT on Ingress 236 Traffic Path. 237 4. Verify traffic routed over Preferred Egress Path. 238 5. Remove PPP session from Tester Interface connected to 239 Preferred Egress Path. 240 6. Measure Peak-to-Peak Convergence Time as DUT detects the 241 PPP session down event and converges all IGP routes and 242 traffic over the Backup Egress Path. 244 Results 245 The measured IGP Convergence time is influenced by the Local 246 PPP failure indication, SPF delay, SPF Holdtime, SPF Execution 247 Time, Tree Build Time, and Hardware Update Time. 249 4.1.3 Convergence Due to IGP Adjacency Failure 251 Objective 252 To obtain the IGP Route Convergence due to a Local IGP Adjacency 253 failure event. 255 Procedure 256 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 257 Path. 258 2. Advertise matching IGP routes from Tester to DUT on 259 Preferred Egress Path and Backup Egress Path. Set the cost 260 of the routes so that the IGP routes along the Preferred 261 Egress Path is the preferred next-hop. 262 3. Send traffic at maximum forwarding rate to destinations 263 matching all IGP routes from Tester to DUT on Ingress 264 Traffic Path. 265 4. Verify traffic routed over Preferred Egress Path. 266 5. Remove IGP adjacency from Tester interface connected to 267 Preferred Egress Path. 269 IGP Data Plane Route Convergence 271 6. Measure Peak-to-Peak Convergence Time as DUT detects the 272 IGP session failure event and converges all IGP routes and 273 traffic over the Backup Egress Path. 275 Results 276 The measured IGP Convergence time is influenced by the IGP 277 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 278 SPF Execution Time, Tree Build Time, and Hardware Update 279 Time. 281 4.1.4 Convergence Due to Route Withdrawal 283 Objective 284 To obtain the IGP Route Convergence due to Route Withdrawal. 286 Procedure 287 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 288 Path. 289 2. Advertise matching IGP routes from Tester to DUT on 290 Preferred Egress Path and Backup Egress Path. Set the cost 291 of the routes so that the IGP routes along the Preferred 292 Egress Path is the preferred next-hop. 293 3. Send traffic at maximum forwarding rate to destinations 294 matching all IGP routes from Tester to DUT on Ingress 295 Traffic Path. 296 4. Verify traffic routed over Preferred Egress Path. 297 5. Tester withdraws all IGP routes from DUT's Local Interface 298 on Preferred Egress Path. 299 6. Measure Peak-to-Peak Convergence Time as DUT processes the 300 route withdrawal event and converges all IGP routes and 301 traffic over the Backup Egress Path. 303 Results 304 The measured IGP Convergence time is the SPF Processing and FIB 305 Update time as influenced by the SPF delay, SPF Holdtime, 306 SPF Execution Time, Tree Build Time, and Hardware Update Time. 308 4.1.5 Convergence Due to Cost Change 310 Objective 311 To obtain the IGP Route Convergence due to route cost change. 313 Procedure 314 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 315 Path. 316 2. Advertise matching IGP routes from Tester to DUT on 317 Preferred Egress Path and Backup Egress Path. Set the cost 318 of the routes so that the IGP routes along the Preferred 319 Egress Path is the preferred next-hop. 320 3. Send traffic at maximum forwarding rate to destinations 321 matching all IGP routes from Tester to DUT on Ingress 322 Traffic Path. 324 IGP Data Plane Route Convergence 326 4. Verify traffic routed over Preferred Egress Path. 327 5. Tester increases cost for all IGP routes at DUT's Local 328 Interface on Preferred Egress Path so that Backup Egress 329 Path have lower cost and becomes preferred path. 330 6. Measure Reroute Convergence Time [2] as DUT detects the 331 cost change event and converges all IGP routes and 332 traffic over the Backup Egress Path. 334 Results 335 The measured IGP Convergence time is the SPF Processing and FIB 336 Update time as influenced by the SPF delay, SPF Holdtime, 337 SPF Execution Time, Tree Build Time, and Hardware Update Time. 338 There should be no packet loss for this case. 340 4.2 Remote Events 342 The test cases in this section use the test topology shown in 343 Figure 2. 345 4.2.1 Convergence Due to Remote SONET Link Failure 347 Objective 348 To obtain the IGP Route Convergence due to a Remote 349 SONET Link failure event. 351 Procedure 352 1. Advertise IGP routes from Tester to DUT on Ingress Traffic 353 Path. 354 2. Advertise matching IGP routes from Tester to DUT on 355 Preferred Egress Path and Backup Egress Path. Set the cost 356 of the routes so that the IGP routes along the Preferred 357 Egress Path is the preferred next-hop. 358 3. Send traffic at maximum forwarding rate to destinations 359 matching all IGP routes from Tester to DUT on Ingress 360 Traffic Path. 361 4. Verify traffic routed over Preferred Egress Path. 362 5. Remove SONET on Neighbor Interface connected to 363 Preferred Egress Path. 364 6. Measure Peak-to-Peak Convergence time as DUT detects the 365 link down event and converges all IGP routes and traffic 366 over the Backup Egress Path. 368 Results 369 The measured IGP Convergence time is influenced by the 370 SONET failure indication, LSA/LSP Flood Packet Pacing, 371 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 372 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 373 Build Time, and Hardware Update Time. 375 IGP Data Plane Route Convergence 377 5. Measuring Convergence Times 378 5.1 Measuring Full Convergence Time 380 Figure 3 shows a graph model of Convergence Time as measured 381 from the data plane. Refer to [2] for definitions of the terms 382 used. IGP Route Convergence Time is the amount of time for the 383 Forwarding Rate to begin its downward slope upon occurrence of 384 a network event and then fully recover to the Maximum 385 Forwarding Rate. 387 Forwarding Rate versus Time 389 Time=Recovery Time=Network Event Time = 0sec 390 Maximum ^ ^ ^ 391 Forwarding Rate--> ----\ /----------- 392 \ /<----Route Convergence 393 Route Convergence------->\ / Event Slope 394 Recovery Slope \_______/<------100% Packet Loss 396 X-axis = Time 397 Y-axis = Forwarding Rate 399 Figure 3. Convergence Graph 401 Maximum forwarding rate at a fixed packet size without packet 402 loss is required for accurate measurement. The test duration 403 must be greater than the convergence time. Full Convergence 404 Time is obtained directly from the graph in Figure 3 using 405 equation 1. 407 (eq 1) Convergence Time(Full)=Time(Recovery)-Time(Network Event). 409 Given a known constant rate of offered load in units packet per 410 second (pps), the Average Convergence Time can be obtained 411 using equation 2 or equation 3. 413 (eq 2) Convergence Time(Average)=Number Packets Lost/pps(Offered) 415 (eq 3) Convergence Time(Average)= (Number Packets Offered - 416 Number of Packets Received)/pps(Offered) 418 As discussed in [1], Full Convergence Time is the more accurate 419 measurement. Average Convergence Time does not account for the 420 angle of the Route Convergence Recovery Slope, so Full Convergence 421 Time > Average Convergence Time. Ideally, the Recovery Slope has 422 no angle so that it is vertical and Average Convergence Time = 423 Full Convergence Time. 425 5.2 Measuring Impact of Components for Convergence 426 The factors for IGP Route Convergence Time are provided in [1]. 427 The results of the test cases in section 4 above can be used to 428 calculate the impact each factor has on the Convergence 429 IGP Data Plane Route Convergence 431 results, as follow: 433 SPF Processing and FIB Update time = Result (4.1.4) 435 SONET failure indication time = Result(4.1.1) - Result(4.1.4) 437 PPP failure indication time = Result(4.1.2) - Result(4.1.4) 439 IGP failure indication time = Result(4.1.3) - Result(4.1.4) 441 IGP Advertisement time = Result(4.1.1) - Result(4.2.1) 443 6. Security Considerations 445 Documents of this type do not directly effect the security of 446 the Internet or of corporate networks as long as benchmarking 447 is not performed on devices or systems connected to operating 448 networks. 450 7. Acknowledgements 451 Thanks to Jayant Kulkarni for doing as most Test Engineers 452 do - working beyond the call of duty to help advance 453 technology. Especially thanks to the many Network Engineers 454 and Network Architects at the Service Providers who are always 455 eager to discuss Route Convergence. 457 8. References 459 [1] Poretsky, S., "Benchmarking Applicability for IGP 460 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-00, work 461 in progress, June 2003. 463 [2] Poretsky, S., "Benchmarking Terminology for IGP Convergence", 464 draft-ietf-bmwg-igp-dataplane-conv-term-00, work in progress, 465 June 2003. 467 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 468 Environments", RFC 1195, December 1990. 470 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 472 9. Author's Address 474 Scott Poretsky 475 Avici Systems, Inc. 476 101 Billerica Avenue 477 N. Billerica, MA 01862 478 USA 480 Phone: + 1 978 964 2287 481 EMail: sporetsky@avici.com 482 IGP Data Plane Route Convergence 484 Brent Imhoff 485 WilTel Communications 486 3180 Rider Trail South 487 Bridgeton, MO 63045 488 USA 490 Phone: +1 314 595 6853 491 EMail: brent.imhoff@wcg.com 493 10. Full Copyright Statement 495 Copyright (C) The Internet Society (1998). All Rights 496 Reserved. 498 This document and translations of it may be copied and 499 furnished to others, and derivative works that comment on or 500 otherwise explain it or assist in its implementation may be 501 prepared, copied, published and distributed, in whole or in 502 part, without restriction of any kind, provided that the above 503 copyright notice and this paragraph are included on all such 504 copies and derivative works. However, this document itself may 505 not be modified in any way, such as by removing the copyright 506 notice or references to the Internet Society or other Internet 507 organizations, except as needed for the purpose of developing 508 Internet standards in which case the procedures for copyrights 509 defined in the Internet Standards process must be followed, or 510 as required to translate it into languages other than English. 512 The limited permissions granted above are perpetual and will 513 not be revoked by the Internet Society or its successors or 514 assigns. This document and the information contained herein is 515 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 516 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 517 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 518 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 519 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 520 FOR A PARTICULAR PURPOSE.