One document matched: draft-lasserre-bgp-rr-benchmark-method-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. --><!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4098 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4098.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-lasserre-bgp-rr-benchmark-method-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">BGP RR Benchmarking Methodology</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Gregory Lasserre" initials="G." role="editor" surname="Lasserre">
<organization>Nokia</organization>
<address>
<postal>
<street>777 E. Middlefield Rd</street>
<!-- Reorder these if your country does things differently -->
<city>Mountain View</city>
<region>California</region>
<code>94043</code>
<country>USA</country>
</postal>
<phone/>
<email>gregory.lasserre@nokia.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="James Cumming" initials="J." role="editor" surname="Cumming">
<organization>Nokia</organization>
<address>
<postal>
<street>740 Waterside Drive, Aztec West</street>
<city>Bristol</city>
<region/>
<code>BS32 4UF</code>
<country>UK</country>
</postal>
<phone/>
<email>james.cumming@nokia.com</email>
</address>
</author>
<author fullname="Carsten Rossenhoevel" initials="C." surname="Rossenhoevel">
<organization>Eantc</organization>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city/>
<region/>
<code/>
<country>Germany</country>
</postal>
<email>cross@eantc.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Guillaume Gaulon" initials="G." surname="Gaulon">
<organization>Orange</organization>
<address>
<postal>
<street>38-40 Rue du General Leclerc</street>
<!-- Reorder these if your country does things differently -->
<code>92130</code>
<city>Issy-les-Moulineaux</city>
<region/>
<country>France</country>
</postal>
<email>guillaume.gaulon@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>bgp rr benchmarking</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>This document covers how to provide an accurate BGP route-reflector benchmark.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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:
</t>
<t><list style="symbols">
<t>ipv4 (AFI 1, SAFI 66)</t>
<t>ipv6 (AFI 2, SAFI )</t>
<t>vpnv4 (AFI 1, SAFI 128)</t>
<t>vpnv6 (AFI 2, SAFI 128)</t>
</list>Other address-families are excluded to ensure a level of consistency between Route-Reflector implementations.
.</t>
<section title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="physical_test_layout" title="Physical Test Layout">
<t>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.
</t>
<figure align="center" anchor="Figure_1">
<preamble>Figure 1: Physical Test Topology</preamble>
<artwork align="left"><![CDATA[
+-------------+ +-------------+ +-------------+
| + + + + |
| TESTER- + 10G + + 10G + TESTER- |
| DEVICE1 +-----------+ DUT +-----------+ DEVICE2 |
| + + + + |
| + + + + |
+-------------+ +-------------+ +-------------+
]]></artwork>
</figure>
</section>
<section anchor="issues_to_consider_when_testing" title="Issues to consider when testing">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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:
</t>
<t><list style="symbols">
<t>The maximum supported IP MTU value </t>
<t>The pre-defined IP MTU value of 9000 Bytes.</t>
</list></t>
<t>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.
</t>
<t>Test devices should be able to support the following features:</t>
<t><list style="symbols">
<t>The ability to bring multiple BGP peering sessions into an ESTABLISHED state without advertising any prefix/path information</t>
<t>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.</t>
<t>The ability to count the number of prefixes advertised.</t>
<t>The ability to count the number of prefixes received. Best-path processing or FIB installation are not required on the tester devices.</t>
<t>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</t>
<t>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</t>
</list>
</t>
</section>
<section anchor="route_profiles" title="Route Profiles">
<t>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.
</t>
<section title="Synthetic Prefixes">
<t>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.</t>
<t>The algorithm SHOULD allow building prefixes according to a number of predefined route profiles. Route profiles defined with as parameters:</t>
<t><list style="symbols">
<t>The number of prefixes</t>
<t>The distribution of prefixes per prefix length</t>
<t>The number of BGP-PATHs</t>
<t>The number of AS numbers per AS-PATH (min, max, avg)</t>
<t>The number of BGP Communities per prefixes (min, max, avg)</t>
</list></t>
<section title="Predefined route profiles">
<t>[TBD]</t>
</section>
</section>
<section title="Global Internet Routing Table">
<t>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.
</t>
</section>
<section title="Routes Testing">
<t>The profiles that should be tested are</t>
<t><list style="empty">
<t>IPv4</t>
<t>- Synthetic</t>
<t>- Global Internet Table</t>
<t>IPv6</t>
<t>- Synthetic</t>
<t>- Global Internet Table</t>
<t>VPNv4</t>
<t>- Synthetic with RD per ASN</t>
<t>- Synthetic with RD per Router-ID</t>
<t>VPNv6</t>
<t>- Synthetic with RD per ASN</t>
<t>- Synthetic with RD per Router-ID</t>
</list> The profiles should be tested individually and then in groups where the groupings are as follows</t>
<t><list style="empty">
<t>- IPv4+IPv6</t>
<t>- VPNv4+VPNv6</t>
<t>- IPv4+IPv6+VPNv4+VPNv6</t>
</list></t>
</section>
</section>
<section anchor="test_scenarios" title="Test Scenarios">
<t>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.</t>
<section title="Route-Reflection one to all">
<t>Test1 - Where they are processing a set of updates from a single iBGP peer and reflecting it to all iBGP route-reflector clients.</t>
<figure align="center" anchor="Figure_2">
<preamble>Figure 2: Scenario 1 Topology</preamble>
<artwork align="left"><![CDATA[
+-------------+ +-------------+ +-------------+
| + + + + |
| TESTER- + 10G + + 10G + TESTER- |
| DEVICE1 +-----------+ DUT +-----------+ DEVICE2 |
| 1 Peer + + + + X Clients |
| + + + + |
+-------------+ +-------------+ +-------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>Establish iBGP peering sessions between DUT and TESTER-DEVICE2</t>
<t>Establish iBGP peering session between DUT and TESTER-DEVICE1</t>
<t>Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1</t>
</list></t>
</section>
<section title="Route-Reflection many to all">
<t>Test2 - Where they are processing multiple sets of updates from multiple iBGP peers and reflecting them to all iBGP route-reflector clients.</t>
<figure align="center" anchor="Figure_3">
<preamble>Figure 3: Scenario 2 Topology</preamble>
<artwork align="left"><![CDATA[
+----------+ +-------------+ +------------+
| + + + + |
| TESTER + 10G + + 10G + TESTER |
| DEVICE1 +----------+ DUT +----------+ DEVICE2 |
| X Peers + + + + X Clients |
| + + + + |
+----------+ +-------------+ +------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>Establish iBGP peering sessions between DUT and TESTER-DEVICE2</t>
<t>Establish iBGP peering session between DUT and TESTER-DEVICE1</t>
<t>Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1</t>
</list></t>
</section>
<section title="Route-Reflection start">
<t>Test3 - Where, as the BGP Route-Reflector starts, it processes all updates from all iBGP route-reflector clients and reflects them back.</t>
<figure align="center" anchor="Figure_4">
<preamble>Figure 4: Scenario 3 Topology</preamble>
<artwork align="left"><![CDATA[
+-------------+ +-------------+
| + + +
| TESTER + 10G + +
| DEVICE1 +-----------+ DUT +
| X Clients + + +
| + + +
+-------------+ +-------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>Establish iBGP peering session between DUT and TESTER-DEVICE1</t>
<t>Enable the BGP prefixes advertisement between TESTER-DEVICE1 and DUT on TESTER-DEVICE1</t>
</list></t>
</section>
</section>
<section anchor="results_matrix" title="Results Matrix">
<t>This table should be used to provide the results of each Route-Reflector tested.</t>
<t>[TBD]</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
<t>This document is part of a plan to make xml2rfc indispensable <xref target="DOMINATION"/>.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="RFC5226">Guidelines for Writing an IANA Considerations Section in RFCs</xref> 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&RFC5226;
&RFC4098;
<!-- A reference written by by an organization not a person. -->
<reference anchor="DOMINATION" target="http://www.example.com/dominator.html">
<front>
<title>Ultimate Plan for Taking Over the World</title>
<author>
<organization>Mad Dominators, Inc.</organization>
</author>
<date year="1984"/>
</front>
</reference>
</references>
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 23:37:23 |