draft-ietf-bmwg-bgpbas-00.txt   draft-ietf-bmwg-bgpbas-01.txt 
Network Working Group H.Berkowitz Benchmarking Working Group H.Berkowitz, Gett Communications
Internet Draft A.Retana Internet Draft S.Hares, Nexthop
Expires Febuaary 2002 S.Hares Document: draft-ietf-bmwg-bgpbas-01.txt A.Retana, Cisco
draft-ietf-bmwg-bgpbas-00.txt P.Krishnaswamy Expires August 2002 P.Krishnaswamy
M. Lepp M.Lepp, Juniper Networks
E.Davies, Nortel Networks
June 2001 February 2002
Benchmarking Methodology for Basic BGP Convergence Benchmarking Methodology for Basic BGP Device Convergence
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026[1]. all provisions of Section 10 of RFC 2026[1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts. Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Internet-Drafts are draft documents valid for a maximum of six time. It is inappropriate to use Internet- Drafts as reference
months and may be updated, replaced, or made obsolete by other material or to cite them other than as "work in progress."
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC
editor as a Informational document for the Internet Community.
Discussion and suggestions for improvement are requested.
This document will expire before August 2002. Distribution of this
draft is unlimited.
Abstract Abstract
This draft establishes standards for measuring BGP convergence
performance. Its initial emphasis is on the control plane of single This draft begins the process of establishing standards for measuring
BGP routers. We do not address forwarding plane performance. the performance of the BGP routing subsystem in a network. Its
initial emphasis is on the control plane of single BGP devices. We
do not address forwarding plane performance.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC-2119]. [2]. document are to be interpreted as described in RFC-2119 [2].
Berkowitz, et al 1
Table of Contents Table of Contents
1 1. Introduction 2
1.1 Overview and Roadmap 2 1. Introduction....................................................3
1.2 Scope 3 1.1 Overview and Roadmap.......................................3
1.3. Types of Single-Router Convergence 3 1.2 Scope......................................................4
2. Reference Configurations 4 1.3 Types of Single-Device Convergence.........................4
3. Basic eBGP tests 4 2. Reference Configurations........................................5
3.1 Connection Conditions 5 3. Basic eBGP tests................................................6
3.2 Test Streams 5 3.1 Connection Conditions......................................6
3.3 Order of Received Updates 5 3.2 Test Streams...............................................7
3.4 Initial Convergence 6 3.3 Route Mixtures.............................................7
3.4.1 Single Peer Initial Convergence Time 6 3.4 Order of Received Updates..................................8
3.4.2 Multiple Peers 7 3.5 Initial Convergence........................................9
3.5 Incremental Re-convergence with a Single Peer 7 3.6 Incremental Re-convergence with a Single Peer and a Single
3.5.1 Explicit add of single new route 7 Update.................................................10
3.5.2 Sequential withdraw and reannounce 7 3.7 Incremental Reconvergence with a Single Peer and Small Packet
3.5.3 Time to Change to Alternate Path after Explicit Withdrawal 7 Trains.................................................10
3.6 Incremental Re-convergence with Multiple Peers 8 3.8 Incremental Re-convergence with Multiple Peers............11
4. Flaps 8 4. Route Flaps....................................................12
4.1 Flap Isolation Test 8 4.1 Flap Isolation Test.......................................12
4.2 Authentication 8 4.2 Authentication............................................12
5. Acknowledgements 8 5. Acknowledgements...............................................12
6. References 8 6. References.....................................................13
Appendix A. Representative Scenarios 10 7. Acknowledgments................................................14
A.1 Default-free interprovider peering 10 8. Author's Addresses.............................................14
A.2 Interprovider peering with transit 10 Appendix A. Representative Scenarios..............................15
A.3 Provider edge router 10 A.1 Default-free interprovider peering........................15
A.4 Multihomed subscriber edge router 10 A.2 Interprovider peering with transit........................15
A.3 Provider edge device......................................15
A.4 Multihomed subscriber edge device.........................15
Berkowitz, et al Expires: August 2002 2
1. Introduction 1. Introduction
This document describes a specific set of tests aimed at This document describes a specific set of tests aimed at
characterizing the convergence performance of BGP-4 processes in characterizing the convergence performance of BGP-4 processes in
routers or other boxes that incorporate BGP functionality. A key devices that incorporate BGP functionality as described in [10] and
objective is to propose methodology that will standardize the subsequent additions. Such devices include conventional routers,
conducting and reporting of convergence-related measurements. route servers, "layer 3 switches" with external path determination
engines (e.g. Ethernet Switch/Routers), and controllers of sub-IP
path creation and management. A key objective is to propose
methodology that will standardize the conducting and reporting of
convergence-related measurements.
Although both convergence and forwarding are The convergence performance of BGP-4 processes is important to the
essential to basic router operation, this document does not consider effectiveness and efficiency of IP networks. Poor performance can
the forwarding performance in the Device Under Test (DUT),for two make the network slow to respond to changes and failures, unnecessary
reasons. Forwarding performance is the primary focus in [RFC 2544] and processing when updates are delivered over a longer period than is
it is expected to be dealt with in work that ensues from [Trotter]. desirable and consequent misdirection or delay of traffic.
Although both convergence and forwarding are essential to basic
device operation, this document does not consider the forwarding
performance in the Device Under Test (DUT), for two reasons:
- Forwarding performance is being treated separately: Methodology
for forwarding performance is the primary focus in [5] and it is
expected to be further covered in work that ensues from the
definitions of terminology for Forwarding Information Bases in
[9].
- The additional time taken to establish new forwarding behavior
after the BGP-4 processes have determined new routes and generated
adverts to downstream devices should not affect the overall time
for convergence of the network
Further, as convergence characterization is a complex process, we Further, as convergence characterization is a complex process, we
deliberately restrict this document basic measurements towards deliberately restrict this document to basic measurements aimed at
characterizing BGP convergence. characterizing BGP convergence in an isolated device receiving inputs
on two interfaces and generating outputs on a third interface.
Subsequent documents will explore the more intricate aspects of Subsequent versions of this document and other document will explore
convergence measurement, such as the presence of policy processing, more complex interconnections, interactions of several devices and
simultaneous traffic on the control and data paths within the DUT, the more intricate aspects of convergence measurement, such as the
and other realistic performance modifiers. Convergence of presence of policy processing, simultaneous traffic on the control
Interior Gateway Protocols will be considered in separate and data paths within the DUT, and other realistic performance
drafts. modifiers. Convergence of Interior Gateway Protocols will be
considered in separate drafts.
1.1 Overview and Roadmap 1.1 Overview and Roadmap
Measurements of protocols can be classified either as internal or Measurements of protocols can be classified either as internal or
external. Internal measurements are time-stamped within the Device external. Internal measurements are derived from time-stamps applied
Under Test (DUT). External measurements infer the timing of a process within the Device Under Test (DUT). External measurements infer the
in the DUT to have converged after a downstream measurement device timing of a process in the DUT from measurements made on externally
indicates the corresponding advertisement has been received. An observable phenomena such as transmission of packets to or reception
alternative type of external measurement is to test for data forwarded of packets from the DUT by connected test devices. In the case of
to the downstream device that relies upon the new route just computed by BGP convergence, the DUT is stimulated by sending BGP UPDATE packets
the Device Under Test. to one or more of its interfaces: If measurements of control plane
Internal measurements are plagued with time synchronization issues, Berkowitz, et al Expires: August 2002 3
since the Network Time Protocol (NTP) hooks may be missing from products behavior are required, the progress of the BGP processes can be
or improperly implemented. Of course in a self-contained lab setting or gauged by observing the UPDATEs generated and transmitted by the DUT
the self-contained measurement of internal processes themselves, in response to the stimuli as they are received by test receivers
synchronized timing is not an issue. connected to the interfaces. An alternative type of external
measurement, involving both the data and control planes, is to test
for data forwarded to the downstream device that relies upon the new
route(s) just installewd in the FIB of the Device Under Test.
For the purposes of this paper, external technique are more readily We focus here on external measurements based only on control plane
applicable. However, external measurements have their own problems phenomena, thus facilitating black box comparisons of the routing
because they include the time to advertise the new route downstream and subsystem in devices with diverse internal architectures and
transmission times for the advertisement within the device under test. functions.
If data forwarding were to feature in the measurement methodology it too
would include some extraneous latency- that of the forwarding lookup
process in the DUT at the minimum. This document deals only with
external measurements limited to route propagation.
A characterization of the BGP convergence performance of a device If alternative internal measurements were adopted, correlating the
must take into account all distinct stages and aspects of BGP DUT's time stamps with those from the rest of the test system is a
functionality. This requires that the relevant terms and metrics be as key problem: The requisite Network Time Protocol (NTP) functionality
specific as possible. A terminology that meets this objective was may not be present and it may be difficult to reach the precision
presented in draft-ietf-bmwg-conterm-00.txt needed for these measurements.
For the purposes of this paper, the external technique is more
readily applicable. However, external measurements have their own
problems because they include the time to advertise the new route
downstream and transmission times for the advertisement within the
device under test. If data forwarding were to feature in the
measurement methodology it too would include some extraneous latency
- that of the forwarding lookup process in the DUT at the minimum.
This document deals only with external measurements limited to route
propagation.
Characterization of the BGP convergence performance of a device
SHOULD take into account all distinct stages and aspects of BGP
functionality. This requires that the relevant terms and metrics be
as specific as possible. A terminology that meets this objective was
presented in "Terinology for Benchmarking External Routing
Convergence Measurements" [13].
1.2 Scope 1.2 Scope
This document deals with eBGP convergence of a single router Device This document deals with eBGP convergence of a single deviceDevice
Under Test (DUT). It restricts the measurement of convergence to events Under Test (DUT). It restricts the measurement of convergence to
in the control plane, and does not consider the interactions of events in the control plane, and does not consider the interactions
convergence and forwarding. of convergence and forwarding.
Convergence measurements among multiple iBGP-connected routers in an AS, Convergence measurements among multiple iBGP-connected devices in an
and Internet-wide convergence measurements, are outside the scope of AS, and Internet-wide convergence measurements, are also outside the
this document as well. scope of this document.
These additional topics are unquestionably of interest, and it is the These additional topics are unquestionably of interest, and it is the
intention of this document to form a stepping stone toward them intention of this document to form a stepping stone toward them
1.3. Types of Single-Router Convergence 1.3 Types of Single-Device Convergence
Two significantly different types of convergence time tend to be lumped There are two major types of convergence time that tend to be lumped
together in product specifications. The first is the time needed for a together in product specifications:
BGP speaker to build a full table after initialization, or for a
particular peering session to rebuild its table after a hard reset. The
second is the time needed for a router to respond to a new announcement
or withdrawal.
As stated in the Roadmap, measurements can be defined either as internal Berkowitz, et al Expires: August 2002 4
or external. Internal measurements examine the RIB/FIB of the DUT - The time needed for a BGP speaker to build a full table after
directly. While they are more accurate in principle, they require initialization, or for a particular peering session to rebuild its
measurement hooks in the implementation, as described in [Ahuja et al]. table after a hard reset (see [12],[13] and section 3.5).
- The time needed for a device to respond to a new announcement or
withdrawal. This second time has two subtypes: the time to
reconverge a update with a single prefix, and the time to
reconverge after receiving a small train of updates. See sections
3.6 and 3.7.
External measurements start with a stimulus from one or more "upstream" External measurements start with the delivery of a stimulus or the
routers and end with a specific event causing an advertisement to be first of several route advertisement stimuli from one or more
sent to a "downstream" peer. In the reference configuration above, "upstream" devices (identified as TD1 to Tdn) and end when the BGP
external measurements are defined with respect to TR3 as the downstream process(es) in the device have returned to equilibrium as indicated
router. by all advertisements resulting from the stimuli having been sent to
a "downstream" peer (TDrx). In the reference configurations below,
external measurements are defined with respect to TDrx as the
downstream device.
2. Reference Configurations 2. Reference Configurations
For tests when the number of peers is not a performance parameter of For tests when the number of peers is not a performance parameter
interest, use the configuration in Figure 1: of interest, use the configuration in Figure 1:
TR1==========+---------+==========TR3 +---------+
TD1==========| |==========TDrx
| | | | | |
D1 | | D1 | |
| | DUT | | | DUT |
TR2==========| | TD2==========| |
+---------+ +---------+
Figure 1. Basic Test Configuration. Figure 1. Basic Test Configuration.
D1 is a prefix reachable by both TR1 and TR2. Neither TR1 or TR2 is the D1 is a prefix reachable by both TD1 and TD2. Neither TD1 nor TD2 is
originating AS for the announcement of D1. the originating AS for the announcement of D1. Stimuli will
typically be generated by one or both of TD1 and TD2 according to a
timed schedule. The DUT will propagate consequent adverts towards
TDrx where their arrival will be recorded and timed.
More complex peering arrangements will involve up to n Test Routers, as More complex peering arrangements will involve up to n Test Routers,
shown in Figure 2. It is recommended that the Figure 1 configuration as shown in Figure 2. It is recommended that the Figure 1
always be tested as a baseline, and then additional reports made that configuration always be tested as a baseline, and then additional
show the effect on performance of increasing the number of peers. reports made that show the effect on performance of increasing the
number of peers. Again stimuli would be expected from one or more
of the TD1 to TDn.
TR1==========+---------+==========TR3 Berkowitz, et al Expires: August 2002 5
+---------+
TD1==========| |==========TDrx
| | | | | |
D1 | | D1 | |
| | DUT | | | DUT |
TR2==========| | TD2==========| |
| | | |
... ...
TRn==========+---------+ TDn==========+---------+
Figure 2. Test Configuration with n Peers. Figure 2. Test Configuration with n Peers.
Interface speeds must be specified as part of the test report. At Interface speeds and types MUST be specified as part of the test
least 100 Mbps is recommended, so media delays are not a significant report. At least 100 Mbps is recommended, so media delays are not a
component of convergence times. significant component of convergence times.
In the absence of other route selection criteria, TR1 shall have an IP In the absence of other route selection criteria, TD1 SHALL have an
address that makes it most preferred. IP address that makes it most preferred.
3. Basic eBGP tests 3. Basic eBGP tests
All routers in this configuration shall have a policy of ADVERTISE All devices in this configuration SHOULD have a policy of ADVERTISE
ALL/ACCEPT ALL [RPSL]. Tests with prefix filtering, community-based ALL/ACCEPT ALL [6]. Tests with prefix filtering, community-based
preferences, authentication, etc., as well as performance under flap are preferences, authentication, etc., as well as performance under route
TBD. flap conditions are TBD.
Not all eBGP applications are alike. While the tests in this section Not all eBGP applications are alike. While the tests in this section
are applicable to a wide range of configurations, testers may select are applicable to a wide range of configurations, testers MAY select
configurations that are most relevant to the intended product use. Such configurations that are most relevant to the intended product use.
configurations include: Such configurations include:
1. Interprovider peering, characterized by an exchange of customer 1. Interprovider peering, characterized by an exchange of customer
routes,which, in the case of major providers, may be in the tens of routes, which, in the case of major providers, may be in the tens
thousands of routes but smaller than the full default-free table. of thousands of routes but smaller than the full default-free
table.
2. Provider/Subscriber edge peering, where transit service implies 2. Provider/Subscriber edge peering, where transit service implies
the subscriber advertises relatively few routes to the provider but may the subscriber advertises relatively few routes to the provider
take, variously, full default-free routes, a limited subset therein, or but may take, variously, a full set of default-free routes, a
default only from the provider. limited subset of the full set, or just a default route from the
provider.
3.1 Connection Conditions 3.1 Connection Conditions
The DUT should be physically connected to the test routers over a medium The DUT SHOULD be physically connected to the test devices over a
sufficiently fast that propagation time is not a significant factor. A medium sufficiently fast that propagation time is not a significant
medium of at least 100 Mbps is recommended. factor. A medium of at least 100 Mbps is recommended.
Multiple peers may be connected to a single physical interface using Multiple peers MAY be connected to a single physical interface using
802.1q VLANs or another appropriate multiplexing scheme. 802.1q VLANs or another appropriate multiplexing scheme, such as a
channelized interface. If so, this MUST be documented in the test
results because it may change the arrival times of UPDATEs by
TCP connections shall use slow start. Any nonstandard initial or Berkowitz, et al Expires: August 2002 6
maximum window sizes shall be indicated in the test report. serializing packets which might otherwise arrive in parallel where
truly separate, asynchronous interfaces are used.
TCP connections SHOULD NOT use slow start. Any nonstandard initial
or maximum window sizes SHALL be indicated in the test report.
3.2 Test Streams 3.2 Test Streams
Packet trains presented to the DUT shall be random with respect to Update Packet trains presented to the DUT SHOULD in general be random
prefix length or order of specificity. (see definition of random update train in [13]) with respect to
selection of prefixes, prefix length, ordering of prefixes, and time
of delivery to DUT. Note that this does not preclude prior, offline
creation of sets of update trains with the required randomness that
can then be used in running the tests multiple times to determine the
reproducibility of results, and for use in comparison tests between
products. There may also be circumstances such as are described in
Section 3.3 where specific ordering of prefixes may be appropriate
for some tests.
The degree of update packing shall be specified. When long packet trains The degree of update packing SHALL be specified. When long update
are being sent, the usual case will be that maximum packing up to the trains are being sent, the usual case is that the maximum possible
MTU size will be used. number of prefixes are packed into an UPDATE packet subject to the
MTU size of the link over which they are being sent.
3.3 Order of Received Updates 3.3 Route Mixtures
Within a set of updates, there is a potential for ordering among the As shown by measurements of routers in actual deployment, such as are
prefixes. For the fairest testing of update trains randomize the order documented in 'The CIDR Report' [14] and similar monitoring projects,
of prefixes, so no particular RIB data structure benefits by the both the prefix length distribution and the clustering of prefixes
ordering. take on characteristic values in the mixture of routes seen.
There are two sets of statistics which exhibit related but different
characteristics:
- The distribution in typical default free routing table
- The distribution in the dynamic UPDATEs arriving at a device
The characteristics are reasonably consistent although there are
significant bursts of activity from time to time that distort the
normal situation.
In creating update trains as test stimuli, these characteristics
SHOULD be used to drive:
- The distribution of prefix lengths
- The clustering of prefixes in the total prefix space
The characteristics used should be appropriate for the sort of test
in which the update train is to be used. Initial table load trains
should reflect the structure of a default free routing table whereas
trains for incremental updates should typically reflect the
characteristics of the dynamic UPDATEs.
Future versions of this document may suggest specific profiles for
these characteristics, but these remain TBD at present.
Berkowitz, et al Expires: August 2002 7
3.4 Order of Received Updates
For the fairest testing of update trains the order of the prefixes
SHALL include one randomized test. It Should also include one test
sorted by prefix size, and one radix tree implementation.
Assume we have a Adj-RIB-out that consists of Assume we have a Adj-RIB-out that consists of
1.0.0.0/8 1.0.0.0/8
2.0.0.0/8 2.0.0.0/8
3.0.0.0/8 3.0.0.0/8
1.1.0.0/16 1.1.0.0/16
2.1.0.0/16 2.1.0.0/16
3.1.0.0/16 3.1.0.0/16
3.2.0.0/16 3.2.0.0/16
1.1.1.0/24 1.1.1.0/24
1.1.2.0/24 1.1.2.0/24
2.1.2.0/24 2.1.2.0/24
If it were sent in this order, top to bottom, it would be sorted If it were sent in this order, top to bottom, it would be sorted by
by prefix size and prefix value within size. A radix tree prefix size and prefix value within size. A radix tree
implementation might like to receive this very much. implementation might like to receive this very much.
But if it were sent out in the following order But if it were sent out in the following order
1.0.0.0/8 1.0.0.0/8
1.1.0.0/16 1.1.0.0/16
1.1.1.0/24 1.1.1.0/24
1.1.2.0/24 1.1.2.0/24
2.0.0.0/8 2.0.0.0/8
2.1.0.0/16 2.1.0.0/16
2.1.2.0/24 2.1.2.0/24
3.0.0.0/8 3.0.0.0/8
3.1.0.0/16 3.1.0.0/16
3.2.0.0/16 3.2.0.0/16
It would make the day for an implementation that orders its routing It would favor an implementation that orders its routing table as a
table as a strict tree, implemented as a linked list. strict tree, implemented as a linked list.
The optimal test train would be A 'fair' test train would be
1.0.0.0/8 1.0.0.0/8
2.1.0.0/16 2.1.0.0/16
1.1.0.0/16 1.1.0.0/16
3.0.0.0/8 3.0.0.0/8
1.1.1.0/24 1.1.1.0/24
2.0.0.0/8 2.0.0.0/8
1.1.2.0/24 1.1.2.0/24
3.1.0.0/16 3.1.0.0/16
2.1.2.0/24 2.1.2.0/24
3.2.0.0/16 3.2.0.0/16
which is random, and does not favor any particular implementation.
which is random, and equally fair to any particular implementation.
Berkowitz, et al Expires: August 2002 8
On the other hand, when dealing with a network of devices from a
single vendor, in the updates forwarded from a device as a result of
a set of stimuli, particularly during a complete table load, the
prefixes may be ordered, both within the route packing in a single
UPDATE and across the update train which results from the stimuli, in
such a way as to be advantageous to downstream devices of the same
type: Hence, it MAY be desirable to measure both randomized and
'friendly' orders so as to get a more realistic view of the real
world behavior of the devices. Note that this can only apply to
update trains where the individual update packets are delivered close
together in time. If the spacing is too great(greater than the
MIN_ADVERT_TIME) the packets will become separate stimuli that are
processed individually.
Measurement units: A metric of randomness,TBD Measurement units: A metric of randomness,TBD
3.4 Initial Convergence 3.5 Initial Convergence
While this is relatively simple to measure, and often is the basis of While this is relatively simple to measure, and often is the basis of
product specifications, it is operationally far less significant than product specifications, it is operationally far less significant than
reconvergence after changes. A "carrier-grade" router should not reconvergence after changes. A "carrier-grade" device should not
initialize often, and the soft reset option reduces the need to rebuild initialize often, and the proposed soft reset option reduces the need
views. The initialization time, therefore, can be amortized over a long to rebuild views. The initialization time, therefore, can be
period of time and may disappear into the noise when compared to amortized over a long period of time and may disappear into the noise
reconvergence. when compared to reconvergence (See [12] for details of soft restart
standards proposals. Proprietary implementations already exist).
3.4.1 Single Peer Initial Convergence Time 3.5.1 Single Peer Initial Convergence Time
This basic reference test uses a representatively sized and populated This basic reference test uses a representatively sized and populated
target RIB and no other variable influences (eg authentication off, target RIB and the device SHOULD be configured for as basic behavior
filters off, no policy). as possible, thus minimizing variable influences (eg authentication
off, filters off, no policy, slow start off).
The test begins with OPEN requests sent from TR1 and TR2 to the DUT. The test begins with OPEN requests sent from TD1 and TD2 to the DUT.
Each Test Router sends a standard routing table of TBD routes. Each Test Router sends a standard routing table with a number, NR, of
routes, designated first route (FR) to last route (LR). The value of
NR should be reported with every test. There are perfectly valid
reasons to test with a small NR, such as testing a device intended as
a small multihomed enterprise gateway to the Internet. In contrast,
a large NR would be appropriate for a device intended as a major
interprovider gateway.
The test ends when the DUT begins to advertise the last route in the Conceptually, the test ends when the DUT begins to advertise the last
routing table to TR3. route, LR, in the routing table to TDrx. Since individual
implementations may vary in the order in which they construct their
outgoing updates i.e., different ordering, packing, etc.), it is
possible that the received LR will not necessarily be the last update
advertised by the DUT. Note that the routes FR and LR are not in any
respect special. They are identified so that progress of the
stimulus generator can be monitored and the corresponding events that
might be logged in the DUT can be identified.
3.4.2 Multiple Peers Berkowitz, et al Expires: August 2002 9
The test receiver (e.g TDrx) SHOULD record the time at which LR is
advertised, but also continue monitoring to see if additional routes
are advertised. Initial convergence time is the interval between
receipt of FR to the later of two events: the reception of re-
advertised LR, or the last update received after the stimulus of LR.
LR may be, and often will, be the last update, but that is not
guaranteed.
3.5.2 Multiple Peers
TBD TBD
3.5 Incremental Re-convergence with a Single Peer 3.6 Incremental Re-convergence with a Single Peer and a Single Update
For all of these measurements, report any route filters, authentication, For all of these measurements, an update train with a single update
and reverse path verification used. It is recommended that these not be is used and the device SHOULD be configured for as basic behavior as
used for initial testing. possible, thus minimizing variable influences (eg authentication off,
filters off, no policy, slow start off).
3.5.1 Explicit add of single new route 3.6.1 Explicit add of single new route
This test measures the time required to add a route newly advertised by This test measures the time required to add a single route (D1) newly
a peer. Such a route does not exist in the DUT's RIB, and will not advertised by a peer. At the start of the test the route does not
displace a route in the RIB. exist in the DUT's RIB, and hence the new route will not displace a
route in the RIB.
The DUT has been initialized, with no path to D1. Measurement time The DUT has been initialized, with no path to D1. Measurement time
begins when TR1 announces D1 to the DUT. begins when TD1 announces D1 to the DUT.
Measurement time stops when the DUT advertises D1 to TR3. Measurement time stops when the DUT advertises D1 to TDrx.
3.5.2 Sequential withdraw and reannounce 3.6.2 Sequential withdraw and reannounce of a Single Prefix
The DUT has been initialized and has a path to D1 via TR1, not TR2. The DUT has been initialized and has a path to D1 via TD1, but not
Simultaneously, TR1 sends TDown(TR1) and TR2 announces the new route via TD2. Simultaneously, TD1 sends TDown(S,TD1) and TD2 announces the
with Tbest(TR2). new route with Tbest(TD2).
Measurement begins when Tbest is received at the DUT. Measurement time Measurement begins when Tbest is received at the DUT. Measurement
stops when the DUT advertises D1 to TR3. time stops when the DUT advertises the new route to D1 to TDrx.
3.5.3 Time to Change to Alternate Path after Explicit Withdrawal 3.6.3 Time to Change to Alternate Path after Explicit Withdrawal of a
Single Route
The DUT has been initialized and has paths to D1 via both TR1 and TR2. The DUT has been initialized and has paths to D1 via both TD1 and
TR1's path is preferred, but TR1 withdraws it with TDown(TR1). Re- TD2. TD1's path is preferred, but TD1 withdraws it with
convergence occurs when the TR2 advertised path(s) becomes active. TDown(S,TD1)). Re-convergence occurs when a route from the path(s)
advertised by TD2 becomes active.
Measurement time stops when the DUT advertises D1 to TR3. Measurement time stops when the DUT advertises the new route to D1
via TD2 to TDrx.
3.6 Incremental Re-convergence with Multiple Peers 3.7 Incremental Reconvergence with a Single Peer and Small Packet Trains
Berkowitz, et al Expires: August 2002 10
For all of these measurements, an update train with a small number of
updates is used and the device SHOULD be configured for as basic
behavior as possible, thus minimizing variable influences (eg
authentication off, filters off, no policy, slow start off). The
train SHOULD deliver the updates over a short period of time so that
the device may deal with them as a batch rather than reconverging
separately for each UPDATE packet received.
3.7.1 Explicit add of several new routes
This test measures the time required to add a number of routes (Dm)
newly advertised by a peer. At the start of the test these routes do
not exist in the DUT's RIB, and hence the new routes will not
displace any routes in the RIB.
The DUT has been initialized, with no path to any of Dm. Measurement
time begins when TD1 announces D1 to the DUT.
Measurement time stops when the DUT advertises the last of the routes
Dm to TDrx.
3.7.2 Sequential withdraw and reannounce for a small group of prefixes
The DUT has been initialized and has paths to each of Dm via TD1, but
not via TD2. Simultaneously, TD1 sends TDown(S,TD1) and TD2 announces
the new route with Tbest(S,TD2).
Measurement begins when Tbest(S.TD1) is received at the DUT.
Measurement time stops when the DUT advertises the last of the new
routes to Dm to TDrx.
3.7.3 Time to Change to Alternate Path after Explicit Withdrawal of
several routes
The DUT has been initialized and has paths to each of Dm via both TD1
and TD2. TD1's path is preferred in each case, but TD1 withdraws it
with TDown(S,TD1). Re-convergence occurs when routes selected from
the path(s) advertised by TD2 become active.
Measurement time stops when the DUT advertises the last of the routes
to Dm via TD2 to TDrx.
3.8 Incremental Re-convergence with Multiple Peers
The number of routes per BGP peer is an obvious stressor to the The number of routes per BGP peer is an obvious stressor to the
convergence process. The number, and relative proportion, of convergence process. The number, and relative proportion, of
multiple route instances and distinct routes being added or multiple route instances and distinct routes being added or
withdrawn by each peer will affect the convergence process, as will withdrawn by each peer will affect the convergence process, as will
the mix of overlapping route instances, and IGP routes. the mix of overlapping route instances advertised by teo or more
peers.
Berkowitz, et al Expires: August 2002 11
4. Route Flaps
4. Flaps
The following tests evaluate convergence when route flap exists. The following tests evaluate convergence when route flap exists.
Let TRF be a router that will generate only flapping routes. Let TDF be a device that will generate only flapping routes.
TR1==========+---------+==========TR3 +---------+
TD1==========| |==========TDrx
| | | | | |
D1 | | D1 | |
| | DUT | | | DUT |
TR2==========| | TD2==========| |
| | | |
... ...
TRF==========+---------+ TDF==========+---------+
Figure 3. Test Diagram with a Router, TRF, flapping.
Figure 3. Test Diagram with a Router, TDF, flapping.
4.1 Flap Isolation Test 4.1 Flap Isolation Test
TRF will advertise a continuously flapping route. Repeat the eBGP TDF will advertise a continuously flapping route i.e. repeated
convergence tests. advertisements and withdrawals of a single route sent at intervals
The objective is to determine whether one route flapping affects the equal to the MIN_ADVERT_TIME. Repeat the eBGP convergence tests. The
operation of the router. objective is to determine whether one route flapping affects the
operation of the device.
If the DUT implements the BGP-4 route flap damping capability
described in [4], then the capability SHOULD be disabled for this
test. Testing of the route flap damping capability is FFS.
4.2 Authentication 4.2 Authentication
Repeat all tests above with MD5 authentication.
Repeat all tests above with MD5 authentication if the DUT implements
the capabilities described in [11].
Repeat all tests with Ipsec authentication turned on.
5. Acknowledgements 5. Acknowledgements
Thanks to Francis Ovenden for review and Abha Ahuja for encouragement. Much Thanks to Francis Ovenden for review and Abha Ahuja for
appreciation to Jeff Haas, Matt Richardson, and Shane Wright at Nexthop for encouragement. Much appreciation to Jeff Haas, Matt Richardson, and
comments and input. Shane Wright at Nexthop for comments and input.
Berkowitz, et al Expires: August 2002 12
6. References 6. References
[Ahuja 2000a] "An Experimental Study of Delayed Internet Routing [1] Bradner, S., "The Internet Standards Process --
Convergence." Abha Ahuja, Farnam Jahanian, Abhijit Bose, Craig Labovits, Revision 3", BCP 9, RFC 2026, October 1996
RIPE 37 - Routing WG.
[RFC 2119] "Key words for use in RFCs to Indicate Requirement
Levels." S Bradner, March 1997.
[RFC 2539] "BGP Route Flap Damping" C. Villamizar, R. Chandra, R.
Govindan. November 1998.
[RFC 2544] "Benchmarking Methodology for Network Interconnect
Devices." S. Bradner, J. McQuaid. March 1999.
[RFC 2622] Routing Policy Specification Language (RPSL)." C.
Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates,
D. Karrenberg, M. Terpstra. June 1999.
[RFC 2827] Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing. P. Ferguson, D.
Senie. May 2000.
[RFC 2928] "Route Refresh Capability for BGP-4". E. Chen.
[Trotter] "Terminology for Forwarding Information Based (FIB) based
Router Performance Benchmarking", Work in Progress, IETF draft-ietf-
bmwg-fib-term-00.txt
12. Authors' Addresses [2] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997
[3] Ahuja, A., Jahanian, F., Bose, A. and Labovitz,
C.,
"An Experimental Study of Delayed Internet
Routing Convergence", RIPE 37 - Routing WG.
[4] Villamizar, C., Chandra, R. and Govindan, R.,
"BGP Route Flap Damping", RFC 2439,
November 1998.
[5] Bradner, S. and McQuaid, J., "Benchmarking
Methodology for Network Interconnect Devices",
RFC 2544, March 1999
[6] Alaettinoglu, C., Villamizar, C., Gerich, E.,
Kessens, D., Meyer, D., Bates, T., Karrenberg,
D. and Terpstra, M., "Routing Policy
Specification Language (RPSL)", RFC 2622, June
1999.
[7] Ferguson, P. and Senie, D., "Network Ingress
Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing",
RFC 2827, May 2000
[8] Chen, E., "Route Refresh Capability for BGP-4",
RFC 2928, DATE NEEDED
[9] Trotter, G., "Terminology for Forwarding
Information Base(FIB)-based Router Performance",
RFC 3222, December 2001
[10] Rekhter, Y. and Li, T., "A Border Gateway
Protocol 4 (BGP-4)", RFC 1771, . March 1995.
[11] Heffernan, A., "Protection of BGP Sessions via
the TCP MD5 Signature Option", RFC 2385, August
1998.
[12] Ramachandra, S., Rekhter, Y., Fernando, R.,
Scudder, J.G. and Chen, E.,
"Graceful Restart Mechanism for BGP",
draft-ietf-idr-restart-02.txt, January 2002, work
in progress.
Berkowitz, et al Expires: August 2002 13
[13] Berkowitz, H., Hares, S., Retana, A.,
Krishnaswamy, P. and Lepp, M., "Terminology for
Benchmarking External Routing Convergence
Measurements", draft-ietf-bmwg-conterm-01.txt,
Febtruary 2002, Work in progress
[14] Bates, T., "The CIDR Report",
http://www.employees.org/~tbates/cidr-report.html
Internet statistics relevant to inter-domain
routing updated daily
7. Acknowledgments
Thanks to Francis Ovenden for review and Abha Ahuja for
encouragement. Much appreciation to Jeff Haas, Matt Richardson, and
Shane Wright at Nexthop for comments and input. Debby Stopp and Nick
Ambrose contributed the concept of route packing. Thanks to Martin
Biddiscombe for trying out the tests.
8. Author's Addresses
Howard Berkowitz Howard Berkowitz
Nortel Networks Gett Communications
5012 S. 25th St 5012 S. 25th St
Arlington VA 22206 Arlington VA 22206
Phone: +1 703 998-5819
Phone: +1 703 998-5819 (ESN 451-5819)
Fax: +1 703 998-5058 Fax: +1 703 998-5058
EMail: hberkowi@nortelnetworks.com EMail: hcb@gettcomm.com
hcb@clark.net
Alvaro Retana Elwyn Davies
Cisco Systems, Inc. Nortel Networks
7025 Kit Creek Rd. London Road
Research Triangle Park, NC 27709 Harlow, Essex CM17 9NA
Email: aretana@cisco.com UK
Phone: +44-1279-405498
Email: elwynd@nortelnetworks.com
Susan Hares Susan Hares
Nexthop Technologies Nexthop Technologies
517 W. William 517 W. William
Ann Arbor, Mi 48103 Ann Arbor, Mi 48103
Phone: Phone:
Email: skh@nexthop.com Email: skh@nexthop.com
Padma Krishnaswamy Padma Krishnaswamy
Nexthop Technologies Email: kri1@earthlink.net
517 W William
Ann Arbor, Mi 48103
Phone: 734 936 2656
Email: kri@nexthop.com
Marianne Lepp Marianne Lepp
Juniper Networks Juniper Networks
51 Sawyer Road 51 Sawyer Road
Waltham, MA 02453 Waltham, MA 02453
Phone: 617 645 9019 Phone: 617 645 9019
Email: mlepp@juniper.net Email: mlepp@juniper.net
Berkowitz, et al Expires: August 2002 14
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
Email: aretana@cisco.com
Appendix A. Representative Scenarios Appendix A. Representative Scenarios
The following describes sample BGP applications positioned at various The following describes sample BGP applications positioned at various
points in the network. points in the network.
A.1 Default-free interprovider peering A.1 Default-free interprovider peering
The DUT exchanges 0.3 to 0.5 D with a small number of peers. Typically, The DUT exchanges 0.3 to 0.5 D with a small number of peers.
routers in this application are limited by bandwidth rather than route Typically, devices in this application are limited by bandwidth
processing rather than route processing
A.2 Interprovider peering with transit A.2 Interprovider peering with transit
The DUT exchanges 1.3 D routes with a small number of peers. The DUT exchanges 1.3 D routes with a small number of peers.
A.3 Provider edge router A.3 Provider edge device
The DUT has a large number (>10) of eBGP peers. The DUT has a large number (>10) of eBGP peers.
To 10% of the peers, the DUT advertises 1.3 D. To 10% of the peers, the DUT advertises 1.3 D.
To 20% of the peers, the DUT advertises 0.3 D. To 20% of the peers, the DUT advertises 0.3 D.
To 70% of the peers, the DUT advertises default. To 70% of the peers, the DUT advertises default.
50% of the peers advertise an aggregate and a more-specific route to the 50% of the peers advertise an aggregate and a more-specific route to
DUT. the DUT.
20% of the peers advertise 10 or more routes to the DUT. 20% of the peers advertise 10 or more routes to the DUT.
30% of the peers advertise a single route to the DUT. 30% of the peers advertise a single route to the DUT.
A.4 Multihomed subscriber edge router
A.4 Multihomed subscriber edge device
The DUT connects to 2 peers. It advertises an aggregate and a more- The DUT connects to 2 peers. It advertises an aggregate and a more-
specific to each. specific to each.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implmentation may be prepared, copied, published and
and distributed, in whole or in part, without restriction of any distributed, in whole or in part, without restriction of any kind,
kind, provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
Berkowitz, et al Expires: August 2002 15
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Berkowitz, et al Expires: August 2002 16
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/