Internet Engineering Task Force G. Lasserre, Ed. Internet-Draft J. Cumming, Ed. Intended status: Informational Nokia Expires: September 22, 2016 C. Rossenhoevel Eantc G. Gaulon Orange March 21, 2016 BGP RR Benchmarking Methodology draft-lasserre-bgp-rr-benchmark-method-00 Abstract BGP is commonly used with network operators in order to distribute routing information for both infrastructure routes as well as service routing information. BGP is used due to its ability to handle high amounts of prefixes and paths information coupled with administrative attributes, such as communities, in a reliable and scalable manner. A route-reflector is a key network component of BGP as it propose an alternative to internal border gateway protocol (iBGP) fully-meshed peering requirement. By acting as a concentration point it learns, process, and reflect prefixes from and to all its iBGP Peers also referred as route-reflector clients, and is a key element of such networks performances. As today networks grow in terms of size and offered services, this translates into more prefixes to be handled by BGP Route-Reflectors, and there is a demand by service providers to be able to benchmark this key function in a realistic and consistent manner. This document covers how to provide an accurate BGP route-reflector benchmark. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Lasserre, et al. Expires September 22, 2016 [Page 1] Internet-Draft Abbreviated Title March 2016 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 22, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Physical Test Layout . . . . . . . . . . . . . . . . . . . . 3 3. Issues to consider when testing . . . . . . . . . . . . . . . 4 4. Route Profiles . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Synthetic Prefixes . . . . . . . . . . . . . . . . . . . 5 4.1.1. Predefined route profiles . . . . . . . . . . . . . . 6 4.2. Global Internet Routing Table . . . . . . . . . . . . . . 6 4.3. Routes Testing . . . . . . . . . . . . . . . . . . . . . 6 5. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Route-Reflection one to all . . . . . . . . . . . . . . . 7 5.2. Route-Reflection many to all . . . . . . . . . . . . . . 7 5.3. Route-Reflection start . . . . . . . . . . . . . . . . . 8 6. Results Matrix . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Lasserre, et al. Expires September 22, 2016 [Page 2] Internet-Draft Abbreviated Title March 2016 1. Introduction This document defines the methodology for benchmarking BGP Route- Reflectors against specific key performance indicators (KPI) in order to allow a realistic, fair, comparative analysis of Route-Reflector implementations in a representative sample of common deployment scenarios. The methodology will assume that the Device Under Test (DUT) is a 'black box' and unknown to the tester. Each scenario will be considered to be complete when the Route-Reflector has achieved convergence, which means it received, processed and completed sending all prefixes to its neighbors. This benchmark will not include the installation of selected prefixes into the neighbors FIB table. And the installation of learned prefixes by the DUT into its FIB table SHOULD also be disabled. The following BGP address-families are in- scope for this document: o ipv4 (AFI 1, SAFI 66) o ipv6 (AFI 2, SAFI ) o vpnv4 (AFI 1, SAFI 128) o vpnv6 (AFI 2, SAFI 128) Other address-families are excluded to ensure a level of consistency between Route-Reflector implementations. . 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Physical Test Layout The following diagram details the physical topology for the testing. The tester devices must be equipped with sufficient resources in order to ensure they do not create a bottleneck on any of the tests defined within this document. The sending and receiving tester devices have been separated in order to ensure that the transmission of prefixes is not hampered by the reception and processing of prefixes for some test scenarios. Lasserre, et al. Expires September 22, 2016 [Page 3] Internet-Draft Abbreviated Title March 2016 Figure 1: Physical Test Topology +-------------+ +-------------+ +-------------+ | + + + + | | TESTER- + 10G + + 10G + TESTER- | | DEVICE1 +-----------+ DUT +-----------+ DEVICE2 | | + + + + | | + + + + | +-------------+ +-------------+ +-------------+ Figure 1 3. Issues to consider when testing BGP is a protocol based on TCP. As such it uses the inherent features available in TCP to ensure transmission of information such as TCP windowing. The understanding of this is important when creating a testing setup and methodology which accurately tests the DUT as opposed to being hampered by any limitations in testing equipment or other underlying protocols. With the introduction of virtualized route-reflector running on servers, the DUT can outgrow in some scenarios traditional hardware- based testing devices which emulate numerous route-reflector clients simultaneously. So, it is necessary to ensure that the tester devices have adequate processing capacity and resources not to slow down the DUT and impair the tests results. When testing a Route-reflector, a limited testing equipment will typically slow down the distribution of BGP Routing Updates by reducing the TCP Window sizes during the test. This mis-behavior can typically be observed by monitoring the TCP-Window sizes variations for the BGP peering sessions in-between the DUT and the testing devices. The testing devices should allow this monitoring. All tests described must be performed at maximum supported TCP-MSS value in a number of predefined IP-MTU Size on all interfaces between the DUT and the testers, specifically: o The maximum supported IP MTU value o The pre-defined IP MTU value of 9000 Bytes. Another important consideration is the behavior of any testing devices being utilized to obtain the benchmarking figures. In order to provide clear and unambiguous guidance this document will detail the requirements on the testing devices as well. Lasserre, et al. Expires September 22, 2016 [Page 4] Internet-Draft Abbreviated Title March 2016 Test devices should be able to support the following features: o The ability to bring multiple BGP peering sessions into an ESTABLISHED state without advertising any prefix/path information o The ability to advertise all BGP prefix/path information immediately and simultaneously without grouping advertisements into smaller sections of ramping up the advertisements over time. o The ability to count the number of prefixes advertised. o The ability to count the number of prefixes received. Best-path processing or FIB installation are not required on the tester devices. o The ability to start the test when the prefixes are advertised and to end the test when all prefixes are received, providing a time between these two points o The ability to monitor Test devices internal BGP computing resources as well as TCP-Window sizes variations for the BGP peering sessions in-between the DUT and the testing devices 4. Route Profiles The profile of the routing information that is used may result in wildly different results. In order to provide meaningful results that can be used for accurate benchmarking of Route-Reflector implementations against one and other and to provide results capable of relating to real world deployments of the DUT there are a number of specific route profiles that should be tested. Broadly these profiles fall into two categories: Synthetic Prefixes with a realistic distribution of prefixes and BGP attributes (BGP-PATH,...) and, Real Prefixes with real BGP attributes such as the Global Internet Table. 4.1. Synthetic Prefixes All of the described tests SHOULD be configurable and performed at a number of realistic prefixes distribution generated according to an algorithm within the tester. The algorithm SHOULD allow building prefixes according to a number of predefined route profiles. Route profiles defined with as parameters: o The number of prefixes Lasserre, et al. Expires September 22, 2016 [Page 5] Internet-Draft Abbreviated Title March 2016 o The distribution of prefixes per prefix length o The number of BGP-PATHs o The number of AS numbers per AS-PATH (min, max, avg) o The number of BGP Communities per prefixes (min, max, avg) 4.1.1. Predefined route profiles [TBD] 4.2. Global Internet Routing Table A recording of the current Global Internet Routing table should be played back as the source feed providing a realistic prefix distribution, AS_PATH distribution, a realistic next-hop distribution and a realistic number of communities per prefix. It is expected that this sample-set will change with each test as the Global Internet Table will change, in time and per internet region, however, the same sample-set must be used for every route-reflector taking part in a comparative benchmarking activity. 4.3. Routes Testing The profiles that should be tested are IPv4 - Synthetic - Global Internet Table IPv6 - Synthetic - Global Internet Table VPNv4 - Synthetic with RD per ASN - Synthetic with RD per Router-ID VPNv6 - Synthetic with RD per ASN Lasserre, et al. Expires September 22, 2016 [Page 6] Internet-Draft Abbreviated Title March 2016 - Synthetic with RD per Router-ID The profiles should be tested individually and then in groups where the groupings are as follows - IPv4+IPv6 - VPNv4+VPNv6 - IPv4+IPv6+VPNv4+VPNv6 5. Test Scenarios Route-Reflectors typically operate in three situations. In these three situations testing should be performed for a representative number of iBGP route-reflector clients: 100, 250, 500, and 1,000. 5.1. Route-Reflection one to all Test1 - Where they are processing a set of updates from a single iBGP peer and reflecting it to all iBGP route-reflector clients. Figure 2: Scenario 1 Topology +-------------+ +-------------+ +-------------+ | + + + + | | TESTER- + 10G + + 10G + TESTER- | | DEVICE1 +-----------+ DUT +-----------+ DEVICE2 | | 1 Peer + + + + X Clients | | + + + + | +-------------+ +-------------+ +-------------+ Figure 2 o Establish iBGP peering sessions between DUT and TESTER-DEVICE2 o Establish iBGP peering session between DUT and TESTER-DEVICE1 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1 5.2. Route-Reflection many to all Test2 - Where they are processing multiple sets of updates from multiple iBGP peers and reflecting them to all iBGP route-reflector clients. Lasserre, et al. Expires September 22, 2016 [Page 7] Internet-Draft Abbreviated Title March 2016 Figure 3: Scenario 2 Topology +----------+ +-------------+ +------------+ | + + + + | | TESTER + 10G + + 10G + TESTER | | DEVICE1 +----------+ DUT +----------+ DEVICE2 | | X Peers + + + + X Clients | | + + + + | +----------+ +-------------+ +------------+ Figure 3 o Establish iBGP peering sessions between DUT and TESTER-DEVICE2 o Establish iBGP peering session between DUT and TESTER-DEVICE1 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1 5.3. Route-Reflection start Test3 - Where, as the BGP Route-Reflector starts, it processes all updates from all iBGP route-reflector clients and reflects them back. Figure 4: Scenario 3 Topology +-------------+ +-------------+ | + + + | TESTER + 10G + + | DEVICE1 +-----------+ DUT + | X Clients + + + | + + + +-------------+ +-------------+ Figure 4 o Establish iBGP peering session between DUT and TESTER-DEVICE1 o Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1 6. Results Matrix This table should be used to provide the results of each Route- Reflector tested. [TBD] Lasserre, et al. Expires September 22, 2016 [Page 8] Internet-Draft Abbreviated Title March 2016 7. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. This document is part of a plan to make xml2rfc indispensable [DOMINATION]. 8. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 9. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [DOMINATION] Mad Dominators, Inc., "Ultimate Plan for Taking Over the World", 1984, . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Lasserre, et al. Expires September 22, 2016 [Page 9] Internet-Draft Abbreviated Title March 2016 [RFC4098] Berkowitz, H., Davies, E., Ed., Hares, S., Krishnaswamy, P., and M. Lepp, "Terminology for Benchmarking BGP Device Convergence in the Control Plane", RFC 4098, DOI 10.17487/RFC4098, June 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Gregory Lasserre (editor) Nokia 777 E. Middlefield Rd Mountain View, California 94043 USA Email: gregory.lasserre@nokia.com James Cumming (editor) Nokia 740 Waterside Drive, Aztec West Bristol BS32 4UF UK Email: james.cumming@nokia.com Carsten Rossenhoevel Eantc Germany Email: cross@eantc.de Lasserre, et al. Expires September 22, 2016 [Page 10] Internet-Draft Abbreviated Title March 2016 Guillaume Gaulon Orange 38-40 Rue du General Leclerc Issy-les-Moulineaux 92130 France Email: guillaume.gaulon@orange.com Lasserre, et al. Expires September 22, 2016 [Page 11]