draft-ietf-bmwg-bgp-basic-convergence-01.txt   draft-ietf-bmwg-bgp-basic-convergence-02.txt 
Benchmarking Working Group R. Papneja Benchmarking Working Group R. Papneja
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track B. Parise Intended status: Standards Track B. Parise
Expires: September 2, 2014 Cisco Systems Expires: December 27, 2014 Cisco Systems
S. Hares S. Hares
Adara Networks Adara Networks
D. Lee D. Lee
IXIA IXIA
I. Varlashkin I. Varlashkin
Easynet Global Services Easynet Global Services
Mar 2014 June 25, 2014
Basic BGP Convergence Benchmarking Methodology for Data Plane Basic BGP Convergence Benchmarking Methodology for Data Plane
Convergence Convergence
draft-ietf-bmwg-bgp-basic-convergence-01.txt draft-ietf-bmwg-bgp-basic-convergence-02.txt
Abstract Abstract
BGP is widely deployed and used by several service providers as the BGP is widely deployed and used by several service providers as the
default Inter AS routing protocol. It is of utmost importance to default Inter AS routing protocol. It is of utmost importance to
ensure that when a BGP peer or a downstream link of a BGP peer fails, ensure that when a BGP peer or a downstream link of a BGP peer fails,
the alternate paths are rapidly used and routes via these alternate the alternate paths are rapidly used and routes via these alternate
paths are installed. This document provides the basic BGP paths are installed. This document provides the basic BGP
Benchmarking Methodology using existing BGP Convergence Terminology, Benchmarking Methodology using existing BGP Convergence Terminology,
RFC 4098. RFC 4098.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2014. This Internet-Draft will expire on December 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Precise Benchmarking Definition . . . . . . . . . . . . . 4 1.1. Benchmarking Definitions . . . . . . . . . . . . . . . . . 4
1.2. Purpose of BGP FIB (Data Plane) Convergence . . . . . . . 4 1.2. Purpose of BGP FIB (Data Plane) Convergence . . . . . . . 4
1.3. Control Plane Convergence . . . . . . . . . . . . . . . . 5 1.3. Control Plane Convergence . . . . . . . . . . . . . . . . 5
1.4. Benchmarking Testing . . . . . . . . . . . . . . . . . . . 5 1.4. Benchmarking Testing . . . . . . . . . . . . . . . . . . . 5
2. Existing Definitions and Requirements . . . . . . . . . . . . 5 2. Existing Definitions and Requirements . . . . . . . . . . . . 5
3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 6 3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. General Reference Topologies . . . . . . . . . . . . . . . 6 3.1. General Reference Topologies . . . . . . . . . . . . . . . 6
4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. Number of Peers . . . . . . . . . . . . . . . . . . . . . 9 4.1. Number of Peers . . . . . . . . . . . . . . . . . . . . . 9
4.2. Number of Routes per Peer . . . . . . . . . . . . . . . . 9 4.2. Number of Routes per Peer . . . . . . . . . . . . . . . . 9
4.3. Policy Processing/Reconfiguration . . . . . . . . . . . . 9 4.3. Policy Processing/Reconfiguration . . . . . . . . . . . . 9
4.4. Configured Parameters (Timers, etc..) . . . . . . . . . . 9 4.4. Configured Parameters (Timers, etc..) . . . . . . . . . . 9
4.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 11 4.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 11
4.6. Measurement Accuracy . . . . . . . . . . . . . . . . . . . 11 4.6. Measurement Accuracy . . . . . . . . . . . . . . . . . . . 11
4.7. Measurement Statistics . . . . . . . . . . . . . . . . . . 11 4.7. Measurement Statistics . . . . . . . . . . . . . . . . . . 11
4.8. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Authentication . . . . . . . . . . . . . . . . . . . . . . 12
4.9. Convergence Events . . . . . . . . . . . . . . . . . . . . 12 4.9. Convergence Events . . . . . . . . . . . . . . . . . . . . 12
4.10. High Availability . . . . . . . . . . . . . . . . . . . . 12 4.10. High Availability . . . . . . . . . . . . . . . . . . . . 12
5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Basic Convergence Tests . . . . . . . . . . . . . . . . . 13 5.1. Basic Convergence Tests . . . . . . . . . . . . . . . . . 13
5.1.1. RIB-IN Convergence . . . . . . . . . . . . . . . . . . 13 5.1.1. RIB-IN Convergence . . . . . . . . . . . . . . . . . . 13
5.1.2. RIB-OUT Convergence . . . . . . . . . . . . . . . . . 14 5.1.2. RIB-OUT Convergence . . . . . . . . . . . . . . . . . 15
5.1.3. eBGP Convergence . . . . . . . . . . . . . . . . . . . 16 5.1.3. eBGP Convergence . . . . . . . . . . . . . . . . . . . 16
5.1.4. iBGP Convergence . . . . . . . . . . . . . . . . . . . 16 5.1.4. iBGP Convergence . . . . . . . . . . . . . . . . . . . 16
5.1.5. eBGP Multihop Convergence . . . . . . . . . . . . . . 16 5.1.5. eBGP Multihop Convergence . . . . . . . . . . . . . . 17
5.2. BGP Failure/Convergence Events . . . . . . . . . . . . . . 18 5.2. BGP Failure/Convergence Events . . . . . . . . . . . . . . 18
5.2.1. Physical Link Failure on DUT End . . . . . . . . . . . 18 5.2.1. Physical Link Failure on DUT End . . . . . . . . . . . 18
5.2.2. Physical Link Failure on Remote/Emulator End . . . . . 19 5.2.2. Physical Link Failure on Remote/Emulator End . . . . . 19
5.2.3. ECMP Link Failure on DUT End . . . . . . . . . . . . . 19 5.2.3. ECMP Link Failure on DUT End . . . . . . . . . . . . . 20
5.3. BGP Adjacency Failure (Non-Physical Link Failure) on 5.3. BGP Adjacency Failure (Non-Physical Link Failure) on
Emulator . . . . . . . . . . . . . . . . . . . . . . . . . 20 Emulator . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. BGP Hard Reset Test Cases . . . . . . . . . . . . . . . . 21 5.4. BGP Hard Reset Test Cases . . . . . . . . . . . . . . . . 21
5.4.1. BGP Non-Recovering Hard Reset Event on DUT . . . . . . 21 5.4.1. BGP Non-Recovering Hard Reset Event on DUT . . . . . . 21
5.5. BGP Soft Reset . . . . . . . . . . . . . . . . . . . . . . 22 5.5. BGP Soft Reset . . . . . . . . . . . . . . . . . . . . . . 22
5.6. BGP Route Withdrawal Convergence Time . . . . . . . . . . 23 5.6. BGP Route Withdrawal Convergence Time . . . . . . . . . . 24
5.7. BGP Path Attribute Change Convergence Time . . . . . . . . 25 5.7. BGP Path Attribute Change Convergence Time . . . . . . . . 26
5.8. BGP Graceful Restart Convergence Time . . . . . . . . . . 26 5.8. BGP Graceful Restart Convergence Time . . . . . . . . . . 27
6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 28 6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document defines the methodology for benchmarking data plane FIB This document defines the methodology for benchmarking data plane FIB
convergence performance of BGP in router and switches for simple convergence performance of BGP in routers and switches using
topologies of 3 or 4 nodes. The methodology proposed in this topologies of 3 or 4 nodes. The methodology proposed in this
document applies to both IPv4 and IPv6 and if a particular test is document applies to both IPv4 and IPv6 and if a particular test is
unique to one version, it is marked accordingly. For IPv6 unique to one version, it is marked accordingly. For IPv6
benchmarking the device under test will require the support of Multi- benchmarking the device under test will require the support of Multi-
Protocol BGP (MP-BGP) [RFC4760, RFC2545]. Protocol BGP (MP-BGP) [RFC4760, RFC2545]. Similarly both iBGP & eBGP
are covered in the tests as applicable.
The scope of this companion document is limited to basic BGP protocol
FIB convergence measurements. BGP extensions outside of carrying
IPv6 in (MP-BGP) [RFC4760, RFC2545] are outside the scope of this
document. Interaction with IGPs (IGP interworking) is outside the
scope of this document.
1.1. Precise Benchmarking Definition
Since benchmarking is science of precision, let us restate the
purpose of this document in benchmarking terms. This document
defines methodology to test
- data plane convergence on a single BGP device that supports the BGP The scope of this document is to provide methodology for BGP protocol
[RFC4271] functionality FIB convergence measurements with BGP functionality limited to IPv4 &
IPv6 as defined in RFC 4271 and Multi-Protocol BGP (MP-BGP) [RFC4760,
RFC2545]. Other BGP extensions to support layer-2, layer-3 virtual
private networks (VPN) are outside the scope of this document.
Interaction with IGPs (IGP interworking) is outside the scope of this
document.
- in test topology of 3 or 4 nodes 1.1. Benchmarking Definitions
- using Basic BGP. The terminology used in this document is defined in [RFC4098]. One
additional term is defined in this draft: FIB (Data plane) BGP
Convergence.
Data plane convergence is defined as the completion of all FIB FIB (Data plane) convergence is defined as the completion of all FIB
changes so that all forwarded traffic now takes the new proposed changes so that all forwarded traffic now takes the new proposed
route. RFC 4098 defines the terms BGP device, FIB and the forwarded route. RFC 4098 defines the terms BGP device, FIB and the forwarded
traffic. Data plane convergence is different than control plane traffic. Data plane convergence is different than control plane
convergence within a node. convergence within a node.
Basic BGP is defined as RFC 4271 functional with Multi-Protocol BGP This document defines methodology to test
(MP-BGP) [RFC4760, RFC2545] for IPv6. The use of other extensions of
BGP to support layer-2, layer-3 virtual private networks (VPN) are
out of scope of this document.
The terminology used in this document is defined in [RFC4098]. One - Data plane convergence on a single BGP device that supports the BGP
additional term is defined in this draft: FIB (Data plane) BGP functionality with scope as outlined above
Convergence.
- using test topology of 3 or 4 nodes which are sufficient to
recreate the Convergence events used in the various tests of this
draft
1.2. Purpose of BGP FIB (Data Plane) Convergence 1.2. Purpose of BGP FIB (Data Plane) Convergence
In the current Internet architecture the Inter-Autonomous System In the current Internet architecture the Inter-Autonomous System
(inter-AS) transit is primarily available through BGP. To maintain a (inter-AS) transit is primarily available through BGP. To maintain
reliable connectivity within intra-domains or across inter-domains, reliable connectivity within intra-domains or across inter-domains,
fast recovery from failures remains most critical. To ensure minimal fast recovery from failures remains most critical. To ensure minimal
traffic losses, many service providers are requiring BGP traffic losses, many service providers are requiring BGP
implementations to converge the entire Internet routing table within implementations to converge the entire Internet routing table within
sub-seconds at FIB level. sub-seconds at FIB level.
Furthermore, to compare these numbers amongst various devices, Furthermore, to compare these numbers amongst various devices,
service providers are also looking at ways to standardize the service providers are also looking at ways to standardize the
convergence measurement methods. This document offers test methods convergence measurement methods. This document offers test methods
for simple topologies. These simple tests will provide a quick high- for simple topologies. These simple tests will provide a quick high-
level check, of the BGP data plane convergence across multiple level check of the BGP data plane convergence across multiple
implementations. implementations from different vendors.
1.3. Control Plane Convergence 1.3. Control Plane Convergence
The convergence of BGP occurs at two levels: RIB and FIB convergence. The convergence of BGP occurs at two levels: RIB and FIB convergence.
RFC 4098 defines terms for BGP control plane convergence. RFC 4098 defines terms for BGP control plane convergence.
Methodologies which test control plane convergence are out of scope Methodologies which test control plane convergence are out of scope
for this draft. for this draft.
1.4. Benchmarking Testing 1.4. Benchmarking Testing
skipping to change at page 6, line 12 skipping to change at page 6, line 8
addition, the following terms are taken as defined in [RFC2285]: addition, the following terms are taken as defined in [RFC2285]:
Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test
(DUT), and System Under Test (SUT). (DUT), and System Under Test (SUT).
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Test Topologies 3. Test Topologies
This section describes simple test setups for use in BGP benchmarking This section describes the test setups for use in BGP benchmarking
tests measuring convergence of the FIB (data plane) after the BGP tests measuring convergence of the FIB (data plane) after the BGP
updates has been received. updates has been received.
These simple test nodes have 3 or 4 nodes with the following These test setups have 3 or 4 nodes with the following configuration:
configuration:
1. Basic Test Setup 1. Basic Test Setup
2. Three node setup for iBGP or eBGP convergence 2. Three node setup for iBGP or eBGP convergence
3. Setup for eBGP multihop test scenario 3. Setup for eBGP multihop test scenario
4. Four node setup for iBGP or eBGP convergence 4. Four node setup for iBGP or eBGP convergence
Individual tests refer to these topologies. Individual tests refer to these topologies.
Figures 1-4 use the following conventions Figures 1-4 use the following conventions
o AS-X: Autonomous System X o AS-X: Autonomous System X
o Loopback Int: Loopback interface on the BGP enabled device o Loopback Int: Loopback interface on the BGP enabled device
o R2: Helper router o HLP,HLP1,HLP2: Helper routers running the same version of BGP as
DUT
o Enable NTP or use any external clock source to synchronize to the
nodes
3.1. General Reference Topologies 3.1. General Reference Topologies
Emulator acts as 1 or more BGP peers for different testcases. Emulator acts as 1 or more BGP peers for different testcases.
+----------+ +------------+ +----------+ +------------+
| | traffic interfaces | | | | traffic interfaces | |
| |-----------------------1---- | tx | | |-----------------------1---- | tx |
| |-----------------------2---- | tr1 | | |-----------------------2---- | tr1 |
| |-----------------------3-----| tr2 | | |-----------------------3-----| tr2 |
| DUT | routing interfaces | Emulator | | DUT | | Emulator |
| | | | | | routing interfaces | |
| Dp1 |--------------------------- |Emp1 | | Dp1 |--------------------------- |Emp1 |
| | BGP Peering | | | | BGP Peering | |
| Dp2 |---------------------------- |Emp2 | | Dp2 |---------------------------- |Emp2 |
| | BGP Peering | | | | BGP Peering | |
+----------+ +------------+ +----------+ +------------+
Figure 1 Basic Test Setup Figure 1 Basic Test Setup
+------------+ +-----------+ +-----------+ +------------+ +-----------+ +-----------+
| | | | | | | | | | | |
skipping to change at page 9, line 23 skipping to change at page 9, line 23
eBGP peering depending upon the test case requirement. eBGP peering depending upon the test case requirement.
The DUT establishes one or more BGP sessions with one more emulated The DUT establishes one or more BGP sessions with one more emulated
routers or helper nodes. Additional peers can be added based on the routers or helper nodes. Additional peers can be added based on the
testing requirements. The number of peers enabled during the testing testing requirements. The number of peers enabled during the testing
should be well documented in the report matrix. should be well documented in the report matrix.
4.2. Number of Routes per Peer 4.2. Number of Routes per Peer
Number of Routes per Peer is defined as the number of routes Number of Routes per Peer is defined as the number of routes
advertised or learnt by the DUT per session or through neighbor advertised or learnt by the DUT per session or through a neighbor
relationship with an emulator or helper node. The tester, emulating relationship with an emulator or helper node. The tester, emulating
as neighbor MUST advertise at least one route per peer. as neighbor MUST advertise at least one route per peer.
Each test run must identify the route stream in terms of route Each test run must identify the route stream in terms of route
packing, route mixture, and number of routes. This route stream must packing, route mixture, and number of routes. This route stream must
be well documented in the reporting stream. RFC 4098 defines these be well documented in the reporting stream. RFC 4098 defines these
terms. terms.
It is RECOMMENDED that the user may consider advertising the entire It is RECOMMENDED that the user consider advertising the entire
current Internet routing table per peering session using an Internet current Internet routing table per peering session using an Internet
route mixture with unique or non-unique routes. If multiple peers route mixture with unique or non-unique routes. If multiple peers
are used, it is important to precisely document the timing sequence are used, it is important to precisely document the timing sequence
between the peer sending routes (as defined in RFC 4098). between the peer sending routes (as defined in RFC 4098).
4.3. Policy Processing/Reconfiguration 4.3. Policy Processing/Reconfiguration
The DUT MUST run one baseline test where policy is Minimal policy as The DUT MUST run one baseline test where policy is Minimal policy as
defined in RFC 4098. Additional runs may be done with policy set-up defined in RFC 4098. Additional runs may be done with policy set-up
before the tests begin. Exact policy settings should be documented before the tests begin. Exact policy settings MUST be documented as
as part of the test. part of the test.
4.4. Configured Parameters (Timers, etc..) 4.4. Configured Parameters (Timers, etc..)
There are configured parameters and timers that may impact the There are configured parameters and timers that may impact the
measured BGP convergence times. measured BGP convergence times.
The benchmark metrics MAY be measured at any fixed values for these The benchmark metrics MAY be measured at any fixed values for these
configured parameters. configured parameters.
It is RECOMMENDED these configure parameters have the following It is RECOMMENDED these configure parameters have the following
settings: a)default values specified by the respective RFC settings: a) default values specified by the respective RFC b)
b)platform-specific default parameters and c)values as expected in platform-specific default parameters and c) values as expected in the
the operational network. All optional BGP settings MUST be kept operational network. All optional BGP settings MUST be kept
consistent across iterations of any specific tests consistent across iterations of any specific tests
Examples of the configured parameters that may impact measured BGP Examples of the configured parameters that may impact measured BGP
convergence time include, but are not limited to: convergence time include, but are not limited to:
1. Interface failure detection timer 1. Interface failure detection timer
2. BGP Keepalive timer 2. BGP Keepalive timer
3. BGP Holdtime 3. BGP Holdtime
skipping to change at page 11, line 22 skipping to change at page 11, line 22
9. Route Flap Dampening parameters (off) 9. Route Flap Dampening parameters (off)
10. TCP MD5 (off) 10. TCP MD5 (off)
4.5. Interface Types 4.5. Interface Types
The type of media dictate which test cases may be executed, each The type of media dictate which test cases may be executed, each
interface type has unique mechanism for detecting link failures and interface type has unique mechanism for detecting link failures and
the speed at which that mechanism operates will influence the the speed at which that mechanism operates will influence the
measurement results. All interfaces MUST be of the same media and measurement results. All interfaces MUST be of the same media and
throughput for each test case. throughput for all iterations of each test case.
4.6. Measurement Accuracy 4.6. Measurement Accuracy
Since observed packet loss is used to measure the route convergence Since observed packet loss is used to measure the route convergence
time, the time between two successive packets offered to each time, the time between two successive packets offered to each
individual route is the highest possible accuracy of any packet-loss individual route is the highest possible accuracy of any packet-loss
based measurement. When packet jitter is much less than the based measurement. When packet jitter is much less than the
convergence time, it is a negligible source of error and hence it convergence time, it is a negligible source of error and hence it
will be treated as within tolerance. will be treated as within tolerance.
Other options to measure convergence are the Time-Based Loss Method Other options to measure convergence are the Time-Based Loss Method
(TBLM) and Timestamp Based Method(TBM)[MPLSProt]. (TBLM) and Timestamp Based Method(TBM)[MPLSProt].
An exterior measurement on the input media (such Ethernet)is defined An exterior measurement on the input media (such as Ethernet) is
by this specification. defined by this specification.
4.7. Measurement Statistics 4.7. Measurement Statistics
The benchmark measurements may vary for each trial, due to the The benchmark measurements may vary for each trial, due to the
statistical nature of timer expirations, CPU scheduling, etc. It is statistical nature of timer expirations, CPU scheduling, etc. It is
recommended to repeat the test multiple times. Evaluation of the recommended to repeat the test multiple times. Evaluation of the
test data must be done with an understanding of generally accepted test data must be done with an understanding of generally accepted
testing practices regarding repeatability, variance and statistical testing practices regarding repeatability, variance and statistical
significance of a small number of trials. significance of a small number of trials.
For any repeated tests that are averaged to remove variance, all For any repeated tests that are averaged to remove variance, all
parameters MUST remain the same. parameters MUST remain the same.
4.8. Authentication 4.8. Authentication
Authentication in BGP is done using the TCP MD5 Signature Option Authentication in BGP is done using the TCP MD5 Signature Option
[RFC5925]. The processing of the MD5 hash, particularly in devices [RFC5925]. The processing of the MD5 hash, particularly in devices
with a large number of BGP peers and a large amount of update with a large number of BGP peers and a large amount of update
traffic, can have an impact on the control plane of the device. If traffic, can have an impact on the control plane of the device. If
authentication is enabled, it SHOULD be documented correctly in the authentication is enabled, it MUST be documented correctly in the
reporting format. reporting format.
4.9. Convergence Events 4.9. Convergence Events
Convergence events or triggers are defined as abnormal occurrences in Convergence events or triggers are defined as abnormal occurrences in
the network, which initiate route flapping in the network, and hence the network, which initiate route flapping in the network, and hence
forces the re-convergence of a steady state network. In a real forces the re-convergence of a steady state network. In a real
network, a series of convergence events may cause convergence latency network, a series of convergence events may cause convergence latency
operators desire to test. operators desire to test.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
The convergence events may or may not be tied to the actual failure A The convergence events may or may not be tied to the actual failure A
Soft Reset (RFC 4098) does not clear the RIB or FIB tables. A Hard Soft Reset (RFC 4098) does not clear the RIB or FIB tables. A Hard
reset clears the BGP peer sessions, the RIB tables, and FIB tables. reset clears the BGP peer sessions, the RIB tables, and FIB tables.
4.10. High Availability 4.10. High Availability
Due to the different Non-Stop-Routing (sometimes referred to High- Due to the different Non-Stop-Routing (sometimes referred to High-
Availability) solutions available from different vendors, it is Availability) solutions available from different vendors, it is
RECOMMENDED that any redundancy available in the routing processors RECOMMENDED that any redundancy available in the routing processors
should be disabled during the convergence measurements. should be disabled during the convergence measurements. For cases
where the redundancy cannot be disabled, the results are no longer
comparable and the level of impacts on the measurements is out of
scope of this document.
5. Test Cases 5. Test Cases
All tests defined under this section assume the following: All tests defined under this section assume the following:
a. BGP peers should be brought to BGP Peer established state a. BGP peers are in established state
b. BGP peers should be brought down and reestablished between each b. BGP state should be cleared from established state to idle prior
test iteration. This is recommended to ensure each test to each test. This is recommended to ensure that all tests start
iteration starts with a clean state. with the BGP peers being forced back to idle state and databases
flushed.
c. Furthermore the traffic generation and routing should be verified c. Furthermore the traffic generation and routing should be verified
in the topology to ensure there is no packet loss observed on any in the topology to ensure there is no packet loss observed on any
advertised routes advertised routes
d. The arrival timestamp of advertised routes can be measured by
installing an inline monitoring device between the emulator and
DUT, or by the span port of DUT connected with an external
analyzer. The time base of such inline monitor or external
analyzer needs to be synchronized with the protocol and traffic
emulator. Some modern emulator may have the capability to
capture and timestamp every NLRI packets leaving and arriving at
the emulator ports. The timestamps of these NLRI packets will be
almost identical to the arrival time at DUT if the cable distance
between the emulator and DUT is relatively short.
5.1. Basic Convergence Tests 5.1. Basic Convergence Tests
These test cases measure characteristics of a BGP implementation in These test cases measure characteristics of a BGP implementation in
non-failure scenarios like: non-failure scenarios like:
1. RIB-IN Convergence 1. RIB-IN Convergence
2. RIB-OUT Convergence 2. RIB-OUT Convergence
3. eBGP Convergence 3. eBGP Convergence
skipping to change at page 13, line 34 skipping to change at page 14, line 8
Reference Test Setup: Reference Test Setup:
This test uses the setup as shown in figure 1 This test uses the setup as shown in figure 1
Procedure: Procedure:
A. All variables affecting Convergence should be set to a basic A. All variables affecting Convergence should be set to a basic
test state (as defined in section 4-4). test state (as defined in section 4-4).
B. Establish BGP adjacency between DUT and peer x of Emulator. B. Establish BGP adjacency between DUT and one peer of Emulator,
Emp1.
C. To ensure adjacency establishment, wait for 3 KeepAlives from C. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
D. Start the traffic from the Emulator peer-x towards the DUT D. Start the traffic from the Emulator tx towards the DUT
targeted at a routes specified in route mixture (ex. route A) targeted at a routes specified in route mixture (ex. routeA)
Initially no traffic SHOULD be observed on the egress Initially no traffic SHOULD be observed on the egress
interface as the route A is not installed in the forwarding interface as the routeA is not installed in the forwarding
database of the DUT. database of the DUT.
E. Advertise route A from the Peer-x to the DUT and record the E. Advertise routeA from the peer(Emp1) to the DUT and record the
time. time.
This is Tup(EMx,Rt-A) also named 'XMT-Rt-time(Rt-A)'. This is Tup(EMp1,Rt-A) also named 'XMT-Rt-time(Rt-A)'.
F. Record the time when the route A from Peer-x is received at F. Record the time when the routeA from Emp1 is received at the
the DUT. DUT.
This Tup(DUT,Rt-A) also named 'RCV-Rt-time(Rt-A)'. This Tup(DUT,Rt-A) also named 'RCV-Rt-time(Rt-A)'.
G. Record the time when the traffic targeted towards route A is G. Record the time when the traffic targeted towards routeA is
received by Emulator on appropriate traffic egress interface. received by Emulator on appropriate traffic egress interface.
This is TR(TDr,Rt-A). This is also named DUT-XMT-Data- This is TR(TDr,Rt-A). This is also named DUT-XMT-Data-
Time(Rt-A). Time(Rt-A).
H. The difference between the Tup(DUT,RT-A) and traffic received H. The difference between the Tup(DUT,RT-A) and traffic received
time (TR (TDr, Rt-A) is the FIB Convergence Time for route A time (TR (TDr, Rt-A) is the FIB Convergence Time for routeA in
in the route mixture. A full convergence for the route update the route mixture. A full convergence for the route update is
is the measurement between the 1st route (Rt-A) and the last the measurement between the 1st route (Rt-A) and the last
route (Rt-last) route (Rt-last)
Route update convergence is Route update convergence is
TR(TDr, Rt-last)- Tup(DUT, Rt-A) or TR(TDr, Rt-last)- Tup(DUT, Rt-A) or
(DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A) (DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A)
Note: It is recommended that a single test with the same route Note: It is recommended that a single test with the same route
mixture be repeated several times. A report should provide the Stand mixture be repeated several times. A report should provide the
Deviation of all tests and the Average. Standard Deviation of all tests and the Average.
Running tests with a varying number of routes and route mixtures is Running tests with a varying number of routes and route mixtures is
important to get a full characterization of a single peer. important to get a full characterization of a single peer.
5.1.2. RIB-OUT Convergence 5.1.2. RIB-OUT Convergence
Objective: Objective:
This test measures the convergence time taken by an implementation This test measures the convergence time taken by an implementation
to receive, install and advertise a route using BGP. to receive, install and advertise a route using BGP.
Reference Test Setup: Reference Test Setup:
This test uses the setup as shown in figure 2. This test uses the setup as shown in figure 2.
Procedure: Procedure:
A. The Helper node (HLP) run same version of BGP as DUT. A. The Helper node (HLP) MUST run same version of BGP as DUT.
B. All devices MUST be synchronized using NTP or some local B. All devices MUST be synchronized using NTP or some local
reference clock. reference clock.
C. All configuration variables for HLP, DUT and Emulator SHOULD C. All configuration variables for HLP, DUT and Emulator SHOULD
be set to the same values. These values MAY be basic-test or be set to the same values. These values MAY be basic-test or
a unique set completely described in the test set-up. a unique set completely described in the test set-up.
D. Establish BGP adjacency between DUT and Emulator. D. Establish BGP adjacency between DUT and Emulator.
E. Establish BGP adjacency between DUT and Helper Node. E. Establish BGP adjacency between DUT and Helper Node.
F. To ensure adjacency establishment, wait for 3 KeepAlives from F. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
G. Start the traffic from the Emulator towards the Helper Node G. Start the traffic from the Emulator towards the Helper Node
targeted at a specific route (e.g. route A). Initially no targeted at a specific route (e.g. routeA). Initially no
traffic SHOULD be observed on the egress interface as the traffic SHOULD be observed on the egress interface as the
route A is not installed in the forwarding database of the routeA is not installed in the forwarding database of the DUT.
DUT.
H. Advertise route A from the Emulator to the DUT and note the H. Advertise routeA from the Emulator to the DUT and note the
time. time.
This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A) This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A)
I. Record when route A is received by DUT. I. Record when routeA is received by DUT.
This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A) This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A)
J. Record the time when the route A is forwarded by DUT towards J. Record the time when the routeA is forwarded by DUT towards
the Helper node. the Helper node.
This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A) This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A)
K. Record the time when the traffic targeted towards route A is K. Record the time when the traffic targeted towards routeA is
received on the Route Egress Interface. This is TR(EMr, received on the Route Egress Interface. This is TR(EMr,
Rt-A), also named DUT-XMT-Data Time(Rt-A). Rt-A), also named DUT-XMT-Data Time(Rt-A).
FIB convergence = (DUT-RCV-Rt-Time - FIB convergence = (DUT-RCV-Rt-Time -
DUT-XMT-Data-Time)(Rt-A) DUT-XMT-Data-Time)(Rt-A)
RIB convergence = (DUT-RCV-Rt-Time - DUT-XMT-Rt-Time)(Rt-A) RIB convergence = (DUT-RCV-Rt-Time - DUT-XMT-Rt-Time)(Rt-A)
Convergence for a route stream is characterized by Convergence for a route stream is characterized by
a) Individual route convergence for FIB, RIB a) Individual route convergence for FIB, RIB
b) All route convergence of b) All route convergence of
FIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Data- FIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Data-
Time(last) Time(last)
RIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Rt- RIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Rt-
skipping to change at page 17, line 10 skipping to change at page 17, line 28
to receive, install and advertise a route in an eBGP Multihop to receive, install and advertise a route in an eBGP Multihop
Scenario. Scenario.
Reference Test Setup: Reference Test Setup:
This test uses the setup as shown in figure 3. DUT is used along This test uses the setup as shown in figure 3. DUT is used along
with a helper node. with a helper node.
Procedure: Procedure:
A. The Helper Node (HLP) runs the same BGP version as DUT. A. The Helper Node (HLP) MUST run the same version of BGP as DUT.
B. All devices to be synchronized using NTP. B. All devices MUST be synchronized using NTP or some local
reference clock.
C. All variables affecting Convergence like authentication, C. All variables affecting Convergence like authentication,
policies, timers should be set to basic-settings policies, timers SHOULD be set to basic-settings
D. All 3 devices, DUT, Emulator and Helper Node are configured D. All 3 devices, DUT, Emulator and Helper Node are configured
with different Autonomous Systems. with different Autonomous Systems.
E. Loopback Interfaces are configured on DUT and Helper Node and E. Loopback Interfaces are configured on DUT and Helper Node and
connectivity is established between them using any config connectivity is established between them using any config
options available on the DUT. options available on the DUT.
F. Establish BGP adjacency between DUT and Emulator. F. Establish BGP adjacency between DUT and Emulator.
G. Establish BGP adjacency between DUT and Helper Node. G. Establish BGP adjacency between DUT and Helper Node.
H. To ensure adjacency establishment, wait for 3 KeepAlives from H. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the tes.t rest of the test
I. Start the traffic from the Emulator towards the DUT targeted I. Start the traffic from the Emulator towards the DUT targeted
at a specific route (e.g. route A). at a specific route (e.g. routeA).
J. Initially no traffic SHOULD be observed on the egress J. Initially no traffic SHOULD be observed on the egress
interface as the route A is not installed in the forwarding interface as the routeA is not installed in the forwarding
database of the DUT. database of the DUT.
K. Advertise route A from the Emulator to the DUT and note the K. Advertise routeA from the Emulator to the DUT and note the
time (Tup(EMx,RouteA) also named Route-Tx-time(Rt-A). time (Tup(EMx,RouteA) also named Route-Tx-time(Rt-A).
L. Record the time when the route is received by the DUT. This L. Record the time when the route is received by the DUT. This
is Tup(EMr,DUT) named Route-Rcv-time(Rt-A). is Tup(EMr,DUT) named Route-Rcv-time(Rt-A).
M. Record the time when the traffic targeted towards route A is M. Record the time when the traffic targeted towards routeA is
received from Egress Interface of DUT on emulator. This is received from Egress Interface of DUT on emulator. This is
Tup(EMd,DUT) named Data-Rcv-time(Rt-A) Tup(EMd,DUT) named Data-Rcv-time(Rt-A)
N. Record the time when the route A is forwarded by DUT towards N. Record the time when the routeA is forwarded by DUT towards
the Helper node. This is Tup(EMf,DUT) also named Route-Fwd- the Helper node. This is Tup(EMf,DUT) also named Route-Fwd-
time(Rt-A) time(Rt-A)
FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A) FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A)
RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A) RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A)
Note: It is recommended that the test be repeated with varying number Note: It is recommended that the test be repeated with varying number
of routes and route mixtures. With each set route mixture, the test of routes and route mixtures. With each set route mixture, the test
should be repeated multiple times. The results should record should be repeated multiple times. The results should record
skipping to change at page 18, line 37 skipping to change at page 19, line 11
defined as an administrative shutdown event on the DUT. defined as an administrative shutdown event on the DUT.
Procedure: Procedure:
A. All variables affecting Convergence like authentication, A. All variables affecting Convergence like authentication,
policies, timers should be set to basic-test policy. policies, timers should be set to basic-test policy.
B. Establish 2 BGP adjacencies from DUT to Emulator, one over the B. Establish 2 BGP adjacencies from DUT to Emulator, one over the
peer interface and the other using a second peer interface. peer interface and the other using a second peer interface.
C. Advertise the same route, route A over both the adjacencies C. Advertise the same route, routeA over both the adjacencies and
and (Tx1)Interface to be the preferred next hop. (Emp1) Interface to be the preferred next hop.
D. To ensure adjacency establishment, wait for 3 KeepAlives from D. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
E. Start the traffic from the Emulator towards the DUT targeted E. Start the traffic from the Emulator towards the DUT targeted
at a specific route (e.g. route A). Initially traffic would at a specific route (e.g. routeA). Initially traffic would be
be observed on the best egress route (Emp1) instead of Trr2. observed on the best egress route (Emp1) instead of Emp2.
F. Trigger the shutdown event of Best Egress Interface on DUT F. Trigger the shutdown event of Best Egress Interface on DUT
(Drr1). (Dp1).
G. Measure the Convergence Time for the event to be detected and G. Measure the Convergence Time for the event to be detected and
traffic to be forwarded to Next-Best Egress Interface (rr2) traffic to be forwarded to Next-Best Egress Interface (Dp2)
Time = Data-detect(rr2) - Shutdown time Time = Data-detect(Emp2) - Shutdown time
H. Stop the offered load and wait for the queues to drain and H. Stop the offered load and wait for the queues to drain and
Restart. Restart.
I. Bring up the link on DUT Best Egress Interface. I. Bring up the link on DUT Best Egress Interface.
J. Measure the convergence time taken for the traffic to be J. Measure the convergence time taken for the traffic to be
rerouted from (rr2) to Best Interface (rr1) rerouted from (Dp2) to Best Interface (Dp1)
Time = Data-detect(rr1) - Bring Up time Time = Data-detect(Emp1) - Bring Up time
K. It is recommended that the test be repeated with varying K. It is recommended that the test be repeated with varying
number of routes and route mixtures or with number of routes & number of routes and route mixtures or with number of routes &
route mixtures closer to what is deployed in operational route mixtures closer to what is deployed in operational
networks. networks.
5.2.2. Physical Link Failure on Remote/Emulator End 5.2.2. Physical Link Failure on Remote/Emulator End
Objective: Objective:
skipping to change at page 20, line 33 skipping to change at page 21, line 10
Interface. Interface.
C. Advertise the same route, routeA over both the adjacencies and C. Advertise the same route, routeA over both the adjacencies and
make Best Egress Interface to be the preferred next hop make Best Egress Interface to be the preferred next hop
D. To ensure adjacency establishment, wait for 3 KeepAlives from D. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
E. Start the traffic from the Emulator towards the DUT targeted E. Start the traffic from the Emulator towards the DUT targeted
at a specific route say routeA. Initially traffic would be at a specific route (e.g. routeA). Initially traffic would be
observed on the Best Egress interface. observed on the Best Egress interface.
F. Remove BGP adjacency via a software adjacency down on the F. Remove BGP adjacency via a software adjacency down on the
Emulator on the Best Egress Interface. This time is called Emulator on the Best Egress Interface. This time is called
BGPadj-down-time also termed BGPpeer-down BGPadj-down-time also termed BGPpeer-down
G. Measure the Convergence Time for the event to be detected and G. Measure the Convergence Time for the event to be detected and
traffic to be forwarded to Next-Best Egress Interface. This traffic to be forwarded to Next-Best Egress Interface. This
time is Tr-rr2 also called TR2-traffic-on time is Tr-rr2 also called TR2-traffic-on
skipping to change at page 21, line 43 skipping to change at page 22, line 20
Interface. Interface.
D. Advertise the same route, routeA over both the adjacencies and D. Advertise the same route, routeA over both the adjacencies and
make Best Egress Interface to be the preferred next hop. make Best Egress Interface to be the preferred next hop.
E. To ensure adjacency establishment, wait for 3 KeepAlives from E. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
F. Start the traffic from the Emulator towards the DUT targeted F. Start the traffic from the Emulator towards the DUT targeted
at a specific route (e.g route A). Initially traffic would be at a specific route (e.g routeA). Initially traffic would be
observed on the Best Egress interface. observed on the Best Egress interface.
G. Trigger the Hard Reset event of Best Egress Interface on DUT. G. Trigger the Hard Reset event of Best Egress Interface on DUT.
H. Measure the Convergence Time for the event to be detected and H. Measure the Convergence Time for the event to be detected and
traffic to be forwarded to Next-Best Egress Interface. traffic to be forwarded to Next-Best Egress Interface.
Time of convergence = time-traffic flow - time-reset Time of convergence = time-traffic flow - time-reset
I. Stop the offered load and wait for the queues to drain and I. Stop the offered load and wait for the queues to drain and
skipping to change at page 22, line 39 skipping to change at page 23, line 14
Reference Test Setup: Reference Test Setup:
This test uses the setup as shown in figure 2. This test uses the setup as shown in figure 2.
Procedure: Procedure:
A. The BGP implementation on DUT & Helper Node needs to support A. The BGP implementation on DUT & Helper Node needs to support
BGP Route Refresh Capability [RFC2918]. BGP Route Refresh Capability [RFC2918].
B. All devices to be synchronized using NTP. B. All devices MUST be synchronized using NTP or some local
reference clock.
C. All variables affecting Convergence like authentication, C. All variables affecting Convergence like authentication,
policies, timers should be set to basic-test defaults. policies, timers should be set to basic-test defaults.
D. DUT and Helper Node are configured in the same Autonomous D. DUT and Helper Node are configured in the same Autonomous
System whereas Emulator is configured under a different System whereas Emulator is configured under a different
Autonomous System. Autonomous System.
E. Establish BGP adjacency between DUT and Emulator. E. Establish BGP adjacency between DUT and Emulator.
skipping to change at page 24, line 10 skipping to change at page 24, line 32
This test uses the setup as shown in figure 2. This test uses the setup as shown in figure 2.
Procedure: Procedure:
A. This test consists of 2 steps to determine the Total Withdraw A. This test consists of 2 steps to determine the Total Withdraw
Processing Time. Processing Time.
B. Step 1: B. Step 1:
(1) All devices to be synchronized using NTP. (1) All devices MUST be synchronized using NTP or some local
reference clock.
(2) All variables should be set to basic-test parameters. (2) All variables should be set to basic-test parameters.
(3) DUT and Helper Node are configured in the same (3) DUT and Helper Node are configured in the same
Autonomous System whereas Emulator is configured under a Autonomous System whereas Emulator is configured under a
different Autonomous System. different Autonomous System.
(4) Establish BGP adjacency between DUT and Emulator. (4) Establish BGP adjacency between DUT and Emulator.
(5) To ensure adjacency establishment, wait for 3 KeepAlives (5) To ensure adjacency establishment, wait for 3 KeepAlives
from the DUT or a configurable delay before proceeding from the DUT or a configurable delay before proceeding
with the rest of the test. with the rest of the test.
(6) Start the traffic from the Emulator towards the DUT (6) Start the traffic from the Emulator towards the DUT
targeted at a specific route (e.g. route A). Initially targeted at a specific route (e.g. routeA). Initially
no traffic would be observed on the Egress interface as no traffic would be observed on the Egress interface as
the route A is not present on DUT. the routeA is not present on DUT.
(7) Advertise route A from the Emulator to the DUT. (7) Advertise routeA from the Emulator to the DUT.
(8) The traffic targeted towards route A is received on the (8) The traffic targeted towards routeA is received on the
Egress Interface. Egress Interface.
(9) Now the Tester sends request to withdraw route A to DUT, (9) Now the Tester sends request to withdraw routeA to DUT,
TRx(Awith) also called WdrawTime1(Rt-A). TRx(Awith) also called WdrawTime1(Rt-A).
(10) Record the time when no traffic is observed on the (10) Record the time when no traffic is observed on the
Egress Interface. This is the RouteRemoveTime1(Rt-A). Egress Interface. This is the RouteRemoveTime1(Rt-A).
(11) The difference between the RouteRemoveTime1 and (11) The difference between the RouteRemoveTime1 and
WdrawTime1 is the WdrawConvTime1 WdrawTime1 is the WdrawConvTime1
WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) -
WdrawTime1(Rt-A) WdrawTime1(Rt-A)
C. Step 2: C. Step 2:
(1) Continuing from Step 1, re-advertise route A back to DUT (1) Continuing from Step 1, re-advertise routeA back to DUT
from Tester. from Tester.
(2) The DUT will try to advertise the route A to Helper Node (2) The DUT will try to advertise the routeA to Helper Node
(This assumes there exists a session between DUT and (This assumes there exists a session between DUT and
helper node). helper node).
(3) Start the traffic from the Emulator towards the Helper (3) Start the traffic from the Emulator towards the Helper
Node targeted at a specific route (e.g. route A). Node targeted at a specific route (e.g. routeA). Traffic
Traffic would be observed on the Egress interface after would be observed on the Egress interface after routeA is
route A is received by the Helper Node received by the Helper Node
WATime=time traffic first flows WATime=time traffic first flows
(4) Now the Tester sends a request to withdraw route A to (4) Now the Tester sends a request to withdraw routeA to DUT.
DUT. This is the WdrawTime2(Rt-A) This is the WdrawTime2(Rt-A)
WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A) WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A)
(5) DUT processes the withdraw and sends it to Helper Node. (5) DUT processes the withdraw and sends it to Helper Node.
(6) Record the time when no traffic is observed on the Egress (6) Record the time when no traffic is observed on the Egress
Interface of Helper Node. This is Interface of Helper Node. This is
TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A) TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A)
skipping to change at page 26, line 9 skipping to change at page 26, line 30
Procedure: Procedure:
A. This test only applies to Well-Known Mandatory Attributes like A. This test only applies to Well-Known Mandatory Attributes like
Origin, AS Path, Next Hop. Origin, AS Path, Next Hop.
B. In each iteration of test only one of these mandatory B. In each iteration of test only one of these mandatory
attributes need to be varied whereas the others remain the attributes need to be varied whereas the others remain the
same. same.
C. All devices to be synchronized using NTP. C. All devices MUST be synchronized using NTP or some local
reference clock.
D. All variables should be set to basic-test parameters. D. All variables should be set to basic-test parameters.
E. Advertise the route, route A over the Best Egress Interface E. Advertise the route, routeA over the Best Egress Interface
only, making it the preferred named Tbest. only, making it the preferred named Tbest.
F. To ensure adjacency establishment, wait for 3 KeepAlives from F. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
G. Start the traffic from the Emulator towards the DUT targeted G. Start the traffic from the Emulator towards the DUT targeted
at the specific route (e.g. route A). Initially traffic would at the specific route (e.g. routeA). Initially traffic would
be observed on the Best Egress interface. be observed on the Best Egress interface.
H. Now advertise the same route route A on the Next-Best Egress H. Now advertise the same route routeA on the Next-Best Egress
Interface but by varying one of the well-known mandatory Interface but by varying one of the well-known mandatory
attributes to have a preferred value over that interface. We attributes to have a preferred value over that interface. We
call this Tbetter. The other values need to be same as what call this Tbetter. The other values need to be same as what
was advertised on the Best-Egress adjacency was advertised on the Best-Egress adjacency
TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A) TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A)
I. Measure the Convergence Time for the event to be detected and I. Measure the Convergence Time for the event to be detected and
traffic to be forwarded to Next-Best Egress Interface traffic to be forwarded to Next-Best Egress Interface
DUT(Path-Change, Rt-A) = Path-switch time(Rt-A) DUT(Path-Change, Rt-A) = Path-switch time(Rt-A)
Convergence = Path-switch time(Rt-A) - Path Change Event Convergence = Path-switch time(Rt-A) - Path Change Event
Time(Rt-A) Time(Rt-A)
skipping to change at page 26, line 50 skipping to change at page 27, line 24
J. Stop the offered load and wait for the queues to drain and J. Stop the offered load and wait for the queues to drain and
Restart. Restart.
K. Repeat the test for various attributes. K. Repeat the test for various attributes.
5.8. BGP Graceful Restart Convergence Time 5.8. BGP Graceful Restart Convergence Time
Objective: Objective:
This test measures the route convergence time taken by an This test measures the route convergence time taken by an
implementation during a Graceful Restart Event. implementation during a Graceful Restart Event as detailed in the
Terminology document [RFC4098].
Reference Test Setup: Reference Test Setup:
This test uses the setup as shown in figure 4. This test uses the setup as shown in figure 4.
Procedure: Procedure:
A. It measures the time taken by an implementation to service a A. It measures the time taken by an implementation to service a
BGP Graceful Restart Event and advertise a route. BGP Graceful Restart Event and advertise a route.
B. The Helper Nodes are the same model as DUT and run the same B. The Helper Nodes are the same model as DUT and run the same
BGP implementation as DUT. BGP implementation as DUT.
C. The BGP implementation on DUT & Helper Node needs to support C. The BGP implementation on DUT & Helper Node needs to support
BGP Graceful Restart Mechanism [RFC4724]. BGP Graceful Restart Mechanism [RFC4724].
D. All devices to be synchronized using NTP. D. All devices MUST be synchronized using NTP or some local
reference clock.
E. All variables are set to basic-test values. E. All variables are set to basic-test values.
F. DUT and Helper Node-1(HLP1) are configured in the same F. DUT and Helper Node-1(HLP1) are configured in the same
Autonomous System whereas Emulator and Helper Node-2(HLP2) are Autonomous System whereas Emulator and Helper Node-2(HLP2) are
configured under different Autonomous System.s configured under different Autonomous Systems.
G. Establish BGP adjacency between DUT and Helper Nodes. G. Establish BGP adjacency between DUT and Helper Nodes.
H. Establish BGP adjacency between Helper Node-2 and Emulator. H. Establish BGP adjacency between Helper Node-2 and Emulator.
I. To ensure adjacency establishment, wait for 3 KeepAlives from I. To ensure adjacency establishment, wait for 3 KeepAlives from
the DUT or a configurable delay before proceeding with the the DUT or a configurable delay before proceeding with the
rest of the test. rest of the test.
J. Configure a policy under BGP on Helper Node-1 to deny routes J. Configure a policy under BGP on Helper Node-1 to deny routes
received from DUT. received from DUT.
K. Advertise route A from the Emulator to Helper Node-2. K. Advertise routeA from the Emulator to Helper Node-2.
L. Helper Node-2 advertises the route to DUT and DUT will try to L. Helper Node-2 advertises the route to DUT and DUT will try to
advertise the route to Helper Node-1 which will be denied. advertise the route to Helper Node-1 which will be denied.
M. Wait for 3 KeepAlives. M. Wait for 3 KeepAlives.
N. Start the traffic from the Emulator towards the Helper Node-1 N. Start the traffic from the Emulator towards the Helper Node-1
targeted at the specific route (e.g. route A). Initially no targeted at the specific route (e.g. routeA). Initially no
traffic would be observed on the Egress interface as the route traffic would be observed on the Egress interface as the
A is not present. routeA is not present.
O. Perform a Graceful Restart Trigger Event on DUT and note the O. Perform a Graceful Restart Trigger Event on DUT and note the
time. This is the GREventTime. time. This is the GREventTime.
P. Remove the policy on Helper Node-1. P. Remove the policy on Helper Node-1.
Q. Record the time when the traffic targeted towards route A is Q. Record the time when the traffic targeted towards routeA is
received on the Egress Interface received on the Egress Interface
TRr(DUT, routeA). This is also called RecTime(Rt-A) TRr(DUT, routeA). This is also called RecTime(Rt-A)
R. The following equation represents the Graceful Restart R. The following equation represents the Graceful Restart
Convergence Time Convergence Time
Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) -
GREventTime) - RIB-IN) GREventTime) - RIB-IN)
S. It is assumed in this test case that after a Switchover is S. It is assumed in this test case that after a Switchover is
triggered on the DUT, it will not have any cycles to process triggered on the DUT, it will not have any cycles to process
BGP Refresh messages. The reason for this assumption is that BGP Refresh messages. The reason for this assumption is that
there is a narrow window of time where after switchover when there is a narrow window of time where after switchover when
we remove the policy from Helper Node -1, implementations we remove the policy from Helper Node-1, implementations might
might generate Route-Refresh automatically and this request generate Route-Refresh automatically and this request might be
might be serviced before the DUT actually switches over and serviced before the DUT actually switches over and
reestablishes BGP adjacencies with the peers. reestablishes BGP adjacencies with the peers.
6. Reporting Format 6. Reporting Format
For each test case, it is recommended that the reporting tables below For each test case, it is recommended that the reporting tables below
are completed and all time values SHOULD be reported with resolution are completed and all time values SHOULD be reported with resolution
as specified in [RFC4098]. as specified in [RFC4098].
Parameter Units Parameter Units
Test case Test case number Test case Test case number
skipping to change at page 32, line 47 skipping to change at page 32, line 47
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. September 2000.
[RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P.,
and M. Lepp, "Terminology for Benchmarking BGP Device
Convergence in the Control Plane", RFC 4098, June 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology
for Benchmarking Link-State IGP Data-Plane Route for Benchmarking Link-State IGP Data-Plane Route
Convergence", RFC 6412, November 2011. Convergence", RFC 6412, November 2011.
10.2. Informative References 10.2. Informative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
skipping to change at page 33, line 24 skipping to change at page 33, line 27
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983,
August 1996. August 1996.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999. March 1999.
[RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P.,
and M. Lepp, "Terminology for Benchmarking BGP Device
Convergence in the Control Plane", RFC 4098, June 2005.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007. January 2007.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
 End of changes. 94 change blocks. 
139 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/