Internet DRAFT - draft-lasserre-bgp-rr-benchmark-method
draft-lasserre-bgp-rr-benchmark-method
Internet Engineering Task Force G. Lasserre, Ed.
Internet-Draft J. Cumming, Ed.
Intended status: Informational Nokia
Expires: March 23, 2017 C. Rossenhoevel
Eantc
G. Gaulon
Orange
September 19, 2016
BGP RR Benchmarking Methodology
draft-lasserre-bgp-rr-benchmark-method-01
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 March 23, 2017 [Page 1]
Internet-Draft Abbreviated Title September 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 March 23, 2017.
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 March 23, 2017 [Page 2]
Internet-Draft Abbreviated Title September 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 not covered in this draft.
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 March 23, 2017 [Page 3]
Internet-Draft Abbreviated Title September 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 March 23, 2017 [Page 4]
Internet-Draft Abbreviated Title September 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 March 23, 2017 [Page 5]
Internet-Draft Abbreviated Title September 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 March 23, 2017 [Page 6]
Internet-Draft Abbreviated Title September 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 March 23, 2017 [Page 7]
Internet-Draft Abbreviated Title September 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 March 23, 2017 [Page 8]
Internet-Draft Abbreviated Title September 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,
<http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[DOMINATION]
Mad Dominators, Inc., "Ultimate Plan for Taking Over the
World", 1984, <http://www.example.com/dominator.html>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
Lasserre, et al. Expires March 23, 2017 [Page 9]
Internet-Draft Abbreviated Title September 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,
<http://www.rfc-editor.org/info/rfc4098>.
[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,
<http://www.rfc-editor.org/info/rfc5226>.
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 March 23, 2017 [Page 10]
Internet-Draft Abbreviated Title September 2016
Guillaume Gaulon
Orange
38-40 Rue du General Leclerc
Issy-les-Moulineaux 92130
France
Email: guillaume.gaulon@orange.com
Lasserre, et al. Expires March 23, 2017 [Page 11]
