Internet Engineering Task Force G. Lasserre, Ed.
Internet-Draft J. Cumming, Ed.
Intended status: Informational Nokia
Expires: September 22, 2016 C. Rossenhoevel
G. Gaulon
March 21, 2016

BGP RR Benchmarking Methodology


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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 ( 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

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:

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.

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:

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.

Test devices should be able to support the following features:

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:

4.1.1. Predefined route profiles


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

The profiles should be tested individually and then in groups where the groupings are as follows

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

  • Establish iBGP peering sessions between DUT and TESTER-DEVICE2
  • Establish iBGP peering session between DUT and TESTER-DEVICE1
  • 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.

Figure 3: Scenario 2 Topology

+----------+          +-------------+          +------------+
|          +          +             +          +            |
| TESTER   +   10G    +             +    10G   +   TESTER   |
| DEVICE1  +----------+     DUT     +----------+   DEVICE2  |
| X Peers  +          +             +          +  X Clients |
|          +          +             +          +            |
+----------+          +-------------+          +------------+

Figure 3

  • Establish iBGP peering sessions between DUT and TESTER-DEVICE2
  • Establish iBGP peering session between DUT and TESTER-DEVICE1
  • 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

  • Establish iBGP peering session between DUT and TESTER-DEVICE1
  • 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.


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.
[RFC4098] Berkowitz, H., Davies, E., 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:
James Cumming (editor) Nokia 740 Waterside Drive, Aztec West Bristol, BS32 4UF UK EMail:
Carsten Rossenhoevel Eantc Germany EMail:
Guillaume Gaulon Orange 38-40 Rue du General Leclerc Issy-les-Moulineaux, 92130 France EMail: