idnits 2.17.1 draft-lasserre-bgp-rr-benchmark-method-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2016) is 2747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 372, but not defined == Unused Reference: 'RFC2629' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC4098' is defined on line 422, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lasserre, Ed. 3 Internet-Draft J. Cumming, Ed. 4 Intended status: Informational Nokia 5 Expires: March 23, 2017 C. Rossenhoevel 6 Eantc 7 G. Gaulon 8 Orange 9 September 19, 2016 11 BGP RR Benchmarking Methodology 12 draft-lasserre-bgp-rr-benchmark-method-01 14 Abstract 16 BGP is commonly used with network operators in order to distribute 17 routing information for both infrastructure routes as well as service 18 routing information. BGP is used due to its ability to handle high 19 amounts of prefixes and paths information coupled with administrative 20 attributes, such as communities, in a reliable and scalable manner. 22 A route-reflector is a key network component of BGP as it propose an 23 alternative to internal border gateway protocol (iBGP) fully-meshed 24 peering requirement. By acting as a concentration point it learns, 25 process, and reflect prefixes from and to all its iBGP Peers also 26 referred as route-reflector clients, and is a key element of such 27 networks performances. 29 As today networks grow in terms of size and offered services, this 30 translates into more prefixes to be handled by BGP Route-Reflectors, 31 and there is a demand by service providers to be able to benchmark 32 this key function in a realistic and consistent manner. 34 This document covers how to provide an accurate BGP route-reflector 35 benchmark. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 23, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 73 2. Physical Test Layout . . . . . . . . . . . . . . . . . . . . 3 74 3. Issues to consider when testing . . . . . . . . . . . . . . . 4 75 4. Route Profiles . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Synthetic Prefixes . . . . . . . . . . . . . . . . . . . 5 77 4.1.1. Predefined route profiles . . . . . . . . . . . . . . 6 78 4.2. Global Internet Routing Table . . . . . . . . . . . . . . 6 79 4.3. Routes Testing . . . . . . . . . . . . . . . . . . . . . 6 80 5. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.1. Route-Reflection one to all . . . . . . . . . . . . . . . 7 82 5.2. Route-Reflection many to all . . . . . . . . . . . . . . 7 83 5.3. Route-Reflection start . . . . . . . . . . . . . . . . . 8 84 6. Results Matrix . . . . . . . . . . . . . . . . . . . . . . . 8 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 90 10.2. Informative References . . . . . . . . . . . . . . . . . 9 91 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 10 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 96 This document defines the methodology for benchmarking BGP Route- 97 Reflectors against specific key performance indicators (KPI) in order 98 to allow a realistic, fair, comparative analysis of Route-Reflector 99 implementations in a representative sample of common deployment 100 scenarios. The methodology will assume that the Device Under Test 101 (DUT) is a 'black box' and unknown to the tester. Each scenario will 102 be considered to be complete when the Route-Reflector has achieved 103 convergence, which means it received, processed and completed sending 104 all prefixes to its neighbors. This benchmark will not include the 105 installation of selected prefixes into the neighbors FIB table. And 106 the installation of learned prefixes by the DUT into its FIB table 107 SHOULD also be disabled. The following BGP address-families are in- 108 scope for this document: 110 o ipv4 (AFI 1, SAFI 66) 112 o ipv6 (AFI 2, SAFI ) 114 o vpnv4 (AFI 1, SAFI 128) 116 o vpnv6 (AFI 2, SAFI 128) 118 Other address-families are not covered in this draft. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Physical Test Layout 128 The following diagram details the physical topology for the testing. 129 The tester devices must be equipped with sufficient resources in 130 order to ensure they do not create a bottleneck on any of the tests 131 defined within this document. The sending and receiving tester 132 devices have been separated in order to ensure that the transmission 133 of prefixes is not hampered by the reception and processing of 134 prefixes for some test scenarios. 136 Figure 1: Physical Test Topology 138 +-------------+ +-------------+ +-------------+ 139 | + + + + | 140 | TESTER- + 10G + + 10G + TESTER- | 141 | DEVICE1 +-----------+ DUT +-----------+ DEVICE2 | 142 | + + + + | 143 | + + + + | 144 +-------------+ +-------------+ +-------------+ 146 Figure 1 148 3. Issues to consider when testing 150 BGP is a protocol based on TCP. As such it uses the inherent 151 features available in TCP to ensure transmission of information such 152 as TCP windowing. The understanding of this is important when 153 creating a testing setup and methodology which accurately tests the 154 DUT as opposed to being hampered by any limitations in testing 155 equipment or other underlying protocols. 157 With the introduction of virtualized route-reflector running on 158 servers, the DUT can outgrow in some scenarios traditional hardware- 159 based testing devices which emulate numerous route-reflector clients 160 simultaneously. So, it is necessary to ensure that the tester 161 devices have adequate processing capacity and resources not to slow 162 down the DUT and impair the tests results. 164 When testing a Route-reflector, a limited testing equipment will 165 typically slow down the distribution of BGP Routing Updates by 166 reducing the TCP Window sizes during the test. This mis-behavior can 167 typically be observed by monitoring the TCP-Window sizes variations 168 for the BGP peering sessions in-between the DUT and the testing 169 devices. The testing devices should allow this monitoring. 171 All tests described must be performed at maximum supported TCP-MSS 172 value in a number of predefined IP-MTU Size on all interfaces between 173 the DUT and the testers, specifically: 175 o The maximum supported IP MTU value 177 o The pre-defined IP MTU value of 9000 Bytes. 179 Another important consideration is the behavior of any testing 180 devices being utilized to obtain the benchmarking figures. In order 181 to provide clear and unambiguous guidance this document will detail 182 the requirements on the testing devices as well. 184 Test devices should be able to support the following features: 186 o The ability to bring multiple BGP peering sessions into an 187 ESTABLISHED state without advertising any prefix/path information 189 o The ability to advertise all BGP prefix/path information 190 immediately and simultaneously without grouping advertisements 191 into smaller sections of ramping up the advertisements over time. 193 o The ability to count the number of prefixes advertised. 195 o The ability to count the number of prefixes received. Best-path 196 processing or FIB installation are not required on the tester 197 devices. 199 o The ability to start the test when the prefixes are advertised and 200 to end the test when all prefixes are received, providing a time 201 between these two points 203 o The ability to monitor Test devices internal BGP computing 204 resources as well as TCP-Window sizes variations for the BGP 205 peering sessions in-between the DUT and the testing devices 207 4. Route Profiles 209 The profile of the routing information that is used may result in 210 wildly different results. In order to provide meaningful results 211 that can be used for accurate benchmarking of Route-Reflector 212 implementations against one and other and to provide results capable 213 of relating to real world deployments of the DUT there are a number 214 of specific route profiles that should be tested. Broadly these 215 profiles fall into two categories: Synthetic Prefixes with a 216 realistic distribution of prefixes and BGP attributes (BGP-PATH,...) 217 and, Real Prefixes with real BGP attributes such as the Global 218 Internet Table. 220 4.1. Synthetic Prefixes 222 All of the described tests SHOULD be configurable and performed at a 223 number of realistic prefixes distribution generated according to an 224 algorithm within the tester. 226 The algorithm SHOULD allow building prefixes according to a number of 227 predefined route profiles. Route profiles defined with as 228 parameters: 230 o The number of prefixes 231 o The distribution of prefixes per prefix length 233 o The number of BGP-PATHs 235 o The number of AS numbers per AS-PATH (min, max, avg) 237 o The number of BGP Communities per prefixes (min, max, avg) 239 4.1.1. Predefined route profiles 241 [TBD] 243 4.2. Global Internet Routing Table 245 A recording of the current Global Internet Routing table should be 246 played back as the source feed providing a realistic prefix 247 distribution, AS_PATH distribution, a realistic next-hop distribution 248 and a realistic number of communities per prefix. It is expected 249 that this sample-set will change with each test as the Global 250 Internet Table will change, in time and per internet region, however, 251 the same sample-set must be used for every route-reflector taking 252 part in a comparative benchmarking activity. 254 4.3. Routes Testing 256 The profiles that should be tested are 258 IPv4 260 - Synthetic 262 - Global Internet Table 264 IPv6 266 - Synthetic 268 - Global Internet Table 270 VPNv4 272 - Synthetic with RD per ASN 274 - Synthetic with RD per Router-ID 276 VPNv6 278 - Synthetic with RD per ASN 279 - Synthetic with RD per Router-ID 281 The profiles should be tested individually and then in groups where 282 the groupings are as follows 284 - IPv4+IPv6 286 - VPNv4+VPNv6 288 - IPv4+IPv6+VPNv4+VPNv6 290 5. Test Scenarios 292 Route-Reflectors typically operate in three situations. In these 293 three situations testing should be performed for a representative 294 number of iBGP route-reflector clients: 100, 250, 500, and 1,000. 296 5.1. Route-Reflection one to all 298 Test1 - Where they are processing a set of updates from a single iBGP 299 peer and reflecting it to all iBGP route-reflector clients. 301 Figure 2: Scenario 1 Topology 303 +-------------+ +-------------+ +-------------+ 304 | + + + + | 305 | TESTER- + 10G + + 10G + TESTER- | 306 | DEVICE1 +-----------+ DUT +-----------+ DEVICE2 | 307 | 1 Peer + + + + X Clients | 308 | + + + + | 309 +-------------+ +-------------+ +-------------+ 311 Figure 2 313 o Establish iBGP peering sessions between DUT and TESTER-DEVICE2 315 o Establish iBGP peering session between DUT and TESTER-DEVICE1 317 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and 318 DUT on TESTER-DEVICE1 320 5.2. Route-Reflection many to all 322 Test2 - Where they are processing multiple sets of updates from 323 multiple iBGP peers and reflecting them to all iBGP route-reflector 324 clients. 326 Figure 3: Scenario 2 Topology 328 +----------+ +-------------+ +------------+ 329 | + + + + | 330 | TESTER + 10G + + 10G + TESTER | 331 | DEVICE1 +----------+ DUT +----------+ DEVICE2 | 332 | X Peers + + + + X Clients | 333 | + + + + | 334 +----------+ +-------------+ +------------+ 336 Figure 3 338 o Establish iBGP peering sessions between DUT and TESTER-DEVICE2 340 o Establish iBGP peering session between DUT and TESTER-DEVICE1 342 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and 343 DUT on TESTER-DEVICE1 345 5.3. Route-Reflection start 347 Test3 - Where, as the BGP Route-Reflector starts, it processes all 348 updates from all iBGP route-reflector clients and reflects them back. 350 Figure 4: Scenario 3 Topology 352 +-------------+ +-------------+ 353 | + + + 354 | TESTER + 10G + + 355 | DEVICE1 +-----------+ DUT + 356 | X Clients + + + 357 | + + + 358 +-------------+ +-------------+ 360 Figure 4 362 o Establish iBGP peering session between DUT and TESTER-DEVICE1 364 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and 365 DUT on TESTER-DEVICE1 367 6. Results Matrix 369 This table should be used to provide the results of each Route- 370 Reflector tested. 372 [TBD] 374 7. Acknowledgements 376 This template was derived from an initial version written by Pekka 377 Savola and contributed by him to the xml2rfc project. 379 This document is part of a plan to make xml2rfc indispensable 380 [DOMINATION]. 382 8. IANA Considerations 384 This memo includes no request to IANA. 386 All drafts are required to have an IANA considerations section (see 387 Guidelines for Writing an IANA Considerations Section in RFCs 388 [RFC5226] for a guide). If the draft does not require IANA to do 389 anything, the section contains an explicit statement that this is the 390 case (as above). If there are no requirements for IANA, the section 391 will be removed during conversion into an RFC by the RFC Editor. 393 9. Security Considerations 395 All drafts are required to have a security considerations section. 396 See RFC 3552 [RFC3552] for a guide. 398 10. References 400 10.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 10.2. Informative References 409 [DOMINATION] 410 Mad Dominators, Inc., "Ultimate Plan for Taking Over the 411 World", 1984, . 413 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 414 DOI 10.17487/RFC2629, June 1999, 415 . 417 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 418 Text on Security Considerations", BCP 72, RFC 3552, 419 DOI 10.17487/RFC3552, July 2003, 420 . 422 [RFC4098] Berkowitz, H., Davies, E., Ed., Hares, S., Krishnaswamy, 423 P., and M. Lepp, "Terminology for Benchmarking BGP Device 424 Convergence in the Control Plane", RFC 4098, 425 DOI 10.17487/RFC4098, June 2005, 426 . 428 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 429 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 430 DOI 10.17487/RFC5226, May 2008, 431 . 433 Appendix A. Additional Stuff 435 This becomes an Appendix. 437 Authors' Addresses 439 Gregory Lasserre (editor) 440 Nokia 441 777 E. Middlefield Rd 442 Mountain View, California 94043 443 USA 445 Email: gregory.lasserre@nokia.com 447 James Cumming (editor) 448 Nokia 449 740 Waterside Drive, Aztec West 450 Bristol BS32 4UF 451 UK 453 Email: james.cumming@nokia.com 455 Carsten Rossenhoevel 456 Eantc 457 Germany 459 Email: cross@eantc.de 460 Guillaume Gaulon 461 Orange 462 38-40 Rue du General Leclerc 463 Issy-les-Moulineaux 92130 464 France 466 Email: guillaume.gaulon@orange.com