idnits 2.17.1 draft-ietf-bmwg-acc-bench-meth-ebgp-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 26 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 75 instances of lines with control characters in the document. ** The abstract seems to contain references ([4], [6]), 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 -- 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 (January 2006) is 6675 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 347, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 350, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC3871' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'NANOG25' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'IEEECQR' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'CONVMETH' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'NANOG30' is defined on line 382, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2544 (ref. '3') == Outdated reference: A later version (-13) exists of draft-ietf-bmwg-acc-bench-term-05 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-acc-bench-term (ref. '4') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-05 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-term (ref. '5') == Outdated reference: A later version (-09) exists of draft-ietf-bmwg-acc-bench-meth-03 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-acc-bench-meth (ref. '6') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-05 Summary: 14 errors (**), 0 flaws (~~), 15 warnings (==), 7 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: January 2006 4 Scott Poretsky 5 Reef Point Systems 7 Shankar Rao 8 Qwest Communications 10 July 2005 12 Methodology for Benchmarking Accelerated Stress 13 with Operational EBGP Instabilities 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 ABSTRACT 44 Routers in an operational network are simultaneously configured with 45 multiple protocols and security policies while forwarding traffic and 46 being managed. To accurately benchmark a router for deployment it is 47 necessary that the router be tested in these simultaneous operational 48 conditions, which is known as Stress Testing. This document provides 49 the Methodology for performing Stress Benchmarking of networking 50 devices when subjected to instability with eBGP-4. Descriptions of 51 Test Topology, Benchmarks and Reporting Format are provided in 52 addition to procedures for conducting various test cases. This 53 methodology is based upon the accelerated stress methodology 54 guidelines [6] and is to be used with the companion terminology 55 document [4]. 57 Table of Contents 58 1. Introduction ............................................... 2 59 2. Existing definitions ....................................... 2 60 3. Test Setup.................................................. 2 61 4. Test Cases.................................................. 3 62 4.1 Failed Primary EBGP Peer................................... 3 63 4.2 Establish New EBGP Peer.................................... 3 64 4.3 BGP Route Explosion........................................ 4 65 4.4 BGP Policy Configuration................................... 4 66 4.5 Persistent BGP Flapping.................................... 5 67 4.6 BGP Route Flap Dampening................................... 6 68 4.7 Nested Convergence Events.................................. 6 69 5. IANA Considerations..................................... 7 70 6. Security Considerations..................................... 7 71 7. References........................................ 7 72 8. Author's Address............................................ 8 74 1. Introduction 76 Routers in an operational network are simultaneously configured with 77 multiple protocols and security policies while forwarding traffic and 78 being managed. To accurately benchmark a router for deployment it is 79 necessary that the router be tested in these simultaneous operational 80 conditions, which is known as Stress Testing. This document provides 81 methodologies based upon the accelerated stress methodology 82 guidelines [6] and is to be used with the companion terminology 83 document [4]. This document provides the methodologies for performing 84 Stress Benchmarking of networking devices when subjected to instability 85 with eBGP-4. Test cases are provided for such conditions as a failed 86 EBGP peer, establishing a new EBGP peer, BGP Route Explosion, BGP 87 Policy Configuration, Persistent BGP Flapping, Route Flapping with BGP 88 Dampening enabled, Nested Convergence Events, and secure BGP. 89 Descriptions of Test Topology, Benchmarks and Reporting Format are 90 provided in addition to the procedures to be used for conducting various 91 test cases. 93 2. Existing definitions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in BCP 14, RFC 2119 [7]. 97 RFC 2119 defines the use of these key words to help make the intent 98 of standards track documents as clear as possible. While this 99 document uses these keywords, this document is not a standards track 100 document. 102 Terms specific to Accelerated Stress Benchmarking are defined in [4]. 104 3. Test Setup 106 Test Setup, Test Topologies, Considerations, and Reporting Format 107 MUST be as described in [6]. 109 4. Test Cases 110 4.1 Failed Primary EBGP Peer 111 Objective 112 The purpose of this test is to benchmark the performance 113 of the DUT during stress conditions when losing an EBGP 114 Peer from which most FIB routes have been learned. 116 Procedure 117 1. Report Configuration Set 118 2. Begin Startup Conditions with the DUT 119 3. Establish Configuration Sets with the DUT 120 4. Report benchmarks (for stability) 121 5. Apply Instability Conditions 122 6. Remove link to EBGP peer with most FIB routes. This SHOULD 123 be achieved by losing physical layer connectivity with 124 a local fiber pull. Loss of the peering session SHOULD 125 cause the DUT to withdraw 100,000 or greater routes. 126 7. Report benchmarks (for instability) 127 8. Stop applying all Instability Conditions 128 9. Report benchmarks (for recovery) 129 10. Optional - Change Configuration Set and/or Instability 130 Conditions for next iteration 132 Results 133 It is expected that there will be significant packet loss 134 until the DUT converges from the lost EBGP link. Other DUT 135 operation should be stable without session loss or sustained 136 packet loss. Recovery time should not be infinite. 138 4.2 Establish New EBGP Peer 139 Objective 140 The purpose of this test is to benchmark the performance 141 of the DUT during stress conditions when establishing a 142 new EBGP Peer from which routes are learned. 144 Procedure 145 1. Report Configuration Set 146 2. Begin Startup Conditions with the DUT 147 3. Establish Configuration Sets with the DUT 148 4. Report benchmarks (for stability) 149 5. Apply Instability Conditions 150 6. Configure a new EBGP peering session at DUT and peering router. 151 Physical and Data Link Layer connectivity SHOULD already exist 152 to perform this step. Establishment of the peering session 153 MUST result in the DUT learning X routes from the BGP peer and 154 advertising X routes to the BGP peer. 156 NOTE 1: Number X of BGP Routes MUST be recorded. 157 NOTE 2: X routes MUST be installed in the FIB and MUST be 158 verified installed in the FIB by sending data to each NLRI. 160 7. Report benchmarks (for instability) 161 8. Stop applying all Instability Conditions 162 9. Report benchmarks (for recovery) 163 10. Optional - Change Configuration Set and/or Instability 164 Conditions for next iteration 166 Results 167 It is expected that there will be zero packet loss as the DUT 168 learns the new routes. Other DUT operation should be stable 169 without session loss or sustained packet loss. 171 4.3 BGP Route Explosion 173 Objective 174 The purpose of this test is to benchmark the performance 175 of the DUT during stress conditions when there is BGP Route 176 Explosion experienced in the network. 178 Procedure 179 1. Report Configuration Set 180 2. Begin Startup Conditions with the DUT 181 3. Establish Configuration Sets with the DUT 182 4. Report benchmarks (for stability) 183 5. Apply Instability Conditions 184 6. Advertise X BGP routes to the DUT from a single EBGP 185 neighbor. 187 NOTE 1: Number X of BGP Routes MUST be recorded. 188 NOTE 2: X routes MUST be installed in the FIB and MUST be 189 verified installed in the FIB by sending data to each NLRI. 191 7. Report benchmarks (for instability) 192 8. Stop applying all Instability Conditions, including BGP route 193 advertisement. 194 9. Report benchmarks (for recovery) 195 10. Optional - Change Configuration Set and/or Instability 196 Conditions for next iteration 198 Results 199 It is expected that there will be no additional packet loss from 200 the advertisement of routes from the BGP neighbor. Other 201 DUT operation should be stable without session loss. 203 4.4 BGP Policy Configuration 205 Objective 206 The purpose of this test is to benchmark the performance 207 of the DUT during stress conditions when there is continuous 208 reconfiguration of BGP Policy at the DUT. 210 Procedure 211 1. Report Configuration Set 212 2. Begin Startup Conditions with the DUT 213 3. Establish Configuration Sets with the DUT 214 4. Report benchmarks (for stability) 215 5. Apply Instability Conditions 216 6. Configure BGP Policy on the DUT for each established neighbor. 217 The BGP Policy SHOULD filter X% of the routes learned from 218 that neighbor. 220 NOTE 1: Note that the specific policy configuration 221 to achieve the filtering may be device specific. 222 NOTE 2: Number X% of BGP Policies MUST be recorded. 223 NOTE 3: The policies MUST be applied so that routes in the FIB 224 are impacted. 225 7. Every 30 minutes remove the BGP Policy configuration and then 226 configure it gain so that it is reapplied. 227 8. Report benchmarks (for instability) 228 9. Stop applying all Instability Conditions, including Policy 229 changes 230 10. Report benchmarks (for recovery) 231 11. Optional - Change Configuration Set and/or Instability 232 Conditions for next iteration 234 Results 235 It is expected that there will be no packet loss resulting from 236 the continuous configuration and removal of BGP Policy for BGP 237 neighbors. Other DUT operation should be stable without session 238 loss. 240 4.5 Persistent BGP Flapping 241 Objective 242 The purpose of this test is to benchmark the performance 243 of the DUT during stress conditions when flapping BGP Peering 244 sessions for an infinite period. 246 Procedure 247 1. Report Configuration Set 248 2. Begin Startup Conditions with the DUT 249 3. Establish Configuration Sets with the DUT 250 4. Report benchmarks (for stability) 251 5. Apply Instability Conditions 252 6. Repeatedly flap an IBGP and an EBGP peering session. 253 This SHOULD be achieved by losing physical layer connectivity 254 via a local interface shutdown/no shutdown every 180 seconds with 255 a delay of 10 seconds between the shut and no shut. 256 The loss of the EBGP peering session MUST cause the DUT to withdraw 257 100,000 routes that are re-learned when the session 258 re-establishes. Route Flap Dampening SHOULD NOT be enabled. 259 7. Report benchmarks (for instability) 260 8. Stop applying all Instability Conditions, including flapping 261 9. Report benchmarks (for recovery) 262 10. Optional - Change Configuration Set and/or Instability 263 Conditions for next iteration 265 Results 266 It is expected that there will be significant packet loss 267 from repeated Convergence Events. Other DUT operation should be 268 stable without session loss. Recovery time should not be infinite. 270 4.6 BGP Route Flap Dampening 272 Objective 273 The purpose of this test is to benchmark the performance 274 of the DUT during stress conditions when flapping BGP Peering 275 sessions for an infinite period and route flap dampening is 276 enabled. 278 Procedure 279 1. Report Configuration Set 280 2. Configure Route Flap Dampening on the DUT with DEFAULT parameter 281 values. 282 3. Begin Startup Conditions with the DUT 283 4. Establish Configuration Sets with the DUT 284 5. Report benchmarks (for stability) 285 6. Apply Instability Conditions 286 7. Repeatedly flap an IBGP and an EBGP peering session. 287 This SHOULD be achieved by losing physical layer connectivity 288 via a local interface shutdown/no shutdown every 180 seconds with 289 a delay of 10 seconds between the shut and no shut. 290 The loss of the EBGP peering session MUST cause the DUT to withdraw 291 100,000 or greater routes that are re-learned when the session 292 re-establishes. 293 8. Report benchmarks (for instability) 294 9. Stop applying all Instability Conditions 295 10. Report benchmarks (for recovery) 296 11. Optional - Change Route Flap Dampening parameter values 297 12. Optional - Change Configuration Set and/or Instability 298 Conditions for next iteration 300 Results 301 It is expected that there will be significant packet loss from 302 repeated Convergence Events and flap dampening. Other DUT 303 operation should be stable without session loss. Recovery time 304 should not be infinite. 306 4.7 Nested Convergence Events [5] 307 Objective 308 The purpose of this test is to benchmark the performance 309 of the DUT during stress conditions when flapping BGP Peering 310 sessions causes Nested Convergence Events. 312 Procedure 313 1. Report Configuration Set 314 2. Begin Startup Conditions with the DUT 315 3. Establish Configuration Sets with the DUT 316 4. Report benchmarks (for stability) 317 5. Apply Instability Conditions 318 6. Repeatedly flap an IBGP and an EBGP peering session. 319 This SHOULD be achieved by losing physical layer connectivity 320 via a local interface shutdown/no shutdown every 10 seconds with 321 a delay of 1 second between the shut and no shut. 322 The loss of the EBGP peering session MUST cause the DUT to withdraw 323 100,000 or greater routes that are re-learned when the session 324 re-establishes. Route Flap Dampening SHOULD NOT be enabled. 325 7. Report benchmarks (for instability) 326 8. Stop applying all Instability Conditions, including flapping 327 9. Report benchmarks (for recovery) 328 10. Optional - Change Configuration Set and/or Instability 329 Conditions for next iteration 331 Results 332 It is expected that there will be significant packet loss 333 from Nested Convergence Events. New Other DUT operation should be 334 stable without session loss. Recovery time should not be infinite. 336 5. IANA Considerations 337 This document requires no IANA considerations. 339 6. Security Considerations 340 Documents of this type do not directly affect the security of 341 the Internet or of corporate networks as long as benchmarking 342 is not performed on devices or systems connected to operating 343 networks. 345 7. References 346 7.1 Normative References 347 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 348 Interconnection Devices", RFC 1242, July 1991. 350 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 351 Devices", RFC 2285, June 1998. 353 [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 354 Network Interconnect Devices", RFC 2544, March 1999. 356 [4] Poretsky, S. and Rao, S., "Terminology for Accelerated 357 Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-05, 358 work in progress, July 2005. 360 [5] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 361 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05, 362 work in progress, July 2005. 364 [6] Poretsky, S. and Rao, S., "Methodology Guidelines for Accelerated 365 Stress Benchmarking", draft-ietf-bmwg-acc-bench-meth-03, 366 work in progress, July 2005. 368 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 369 Levels", RFC 2119, March 1997. 371 7.2 Informative References 372 [RFC3871] RFC 3871 "Operational Security Requirements for Large 373 Internet Service Provider (ISP) IP Network Infrastructure. 374 G. Jones, Ed.. IETF, September 2004. 375 [NANOG25] "Core Router Evaluation for Higher Availability", Scott 376 Poretsky, NANOG 25, June 8, 2002, Toronto, CA. 377 [IEEECQR] "Router Stress Testing to Validate Readiness for Network 378 Deployment", Scott Poretsky, IEEE CQR 2003. 379 [CONVMETH] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 380 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-05, 381 work in progress, July 2005. 382 [NANOG30] Poretsky, S. and Imhoff, B., "BGP Testing: Why be so Negative?", 383 NANOG 30, Miami, Feb 2004. 385 8. Author's Address 387 Scott Poretsky 388 Reef Point Systems 389 8 New England Executive Park 390 Burlington, MA 01803 391 USA 392 Phone: + 1 781 395 5090 393 EMail: sporetsky@reefpoint.com 395 Shankar Rao 396 1801 California Street 397 8th Floor 398 Qwest Communications 399 Denver, CO 80202 400 USA 401 Phone: + 1 303 437 6643 402 Email: shankar.rao@qwest.com 404 Full Copyright Statement 406 Copyright (C) The Internet Society (2005). 407 This document is subject to the rights, licenses and restrictions 408 contained in BCP 78, and except as set forth therein, the authors 409 retain all their rights. 411 This document and the information contained herein are provided on an 412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 414 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 415 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 416 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Intellectual Property 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at ietf- 441 ipr@ietf.org. 443 Acknowledgement 445 Funding for the RFC Editor function is currently provided by the 446 Internet Society.