RFC 7747

Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence

📅 published April 2016, from ietf

Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence 💖

Okay bestie, let's get into RFC 7747 🎀 The title block is the tea: it's an Informational doc, so it's guidance and not a Standards Track spec 🌸 It was published in April 2016 and has ISSN 2070-1721. The authors are R. Papneja and S. Hares (both from Huawei Technologies), B. Parise (Skyport Systems), D. Lee (IXIA), and I. Varlashkin (Google). The title block doesn't list anything this document obsoletes or updates, so it stands on its own ✨

Abstract

BGP is everywhere 🌈 Lots of service providers use it as their default inter-AS (Autonomous System) routing protocol, so it's a big deal. When a BGP peer or a downstream link of a BGP peer dies, you want the backup paths to kick in fast and get their routes installed, no delays 😭 This doc gives you a basic BGP benchmarking method that uses the convergence terms already defined in RFC 4098 💅

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🦋

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧚

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7747 💜

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌸

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Benchmarking Definitions  . . . . . . . . . . . . . . . .   4
     1.2.  Purpose of BGP FIB (Data-Plane) Convergence . . . . . . .   4
     1.3.  Control-Plane Convergence . . . . . . . . . . . . . . . .   5
     1.4.  Benchmarking Testing  . . . . . . . . . . . . . . . . . .   5
   2.  Existing Definitions and Requirements . . . . . . . . . . . .   5
   3.  Test Topologies . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  General Reference Topologies  . . . . . . . . . . . . . .   7
   4.  Test Considerations . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Number of Peers . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Number of Routes per Peer . . . . . . . . . . . . . . . .   9
     4.3.  Policy Processing/Reconfiguration . . . . . . . . . . . .   9
     4.4.  Configured Parameters (Timers, etc.)  . . . . . . . . . .   9
     4.5.  Interface Types . . . . . . . . . . . . . . . . . . . . .  11
     4.6.  Measurement Accuracy  . . . . . . . . . . . . . . . . . .  11
     4.7.  Measurement Statistics  . . . . . . . . . . . . . . . . .  11
     4.8.  Authentication  . . . . . . . . . . . . . . . . . . . . .  11
     4.9.  Convergence Events  . . . . . . . . . . . . . . . . . . .  12
     4.10. High Availability . . . . . . . . . . . . . . . . . . . .  12
   5.  Test Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Basic Convergence Tests . . . . . . . . . . . . . . . . .  13
       5.1.1.  RIB-IN Convergence  . . . . . . . . . . . . . . . . .  13
       5.1.2.  RIB-OUT Convergence . . . . . . . . . . . . . . . . .  15
       5.1.3.  eBGP Convergence  . . . . . . . . . . . . . . . . . .  16
       5.1.4.  iBGP Convergence  . . . . . . . . . . . . . . . . . .  16
       5.1.5.  eBGP Multihop Convergence . . . . . . . . . . . . . .  17
     5.2.  BGP Failure/Convergence Events  . . . . . . . . . . . . .  18
       5.2.1.  Physical Link Failure on DUT End  . . . . . . . . . .  18
       5.2.2.  Physical Link Failure on Remote/Emulator End  . . . .  19
       5.2.3.  ECMP Link Failure on DUT End  . . . . . . . . . . . .  20
     5.3.  BGP Adjacency Failure (Non-Physical Link Failure) on
           Emulator  . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.4.  BGP Hard Reset Test Cases . . . . . . . . . . . . . . . .  21
       5.4.1.  BGP Non-Recovering Hard Reset Event on DUT  . . . . .  21
     5.5.  BGP Soft Reset  . . . . . . . . . . . . . . . . . . . . .  22
     5.6.  BGP Route Withdrawal Convergence Time . . . . . . . . . .  24
     5.7.  BGP Path Attribute Change Convergence Time  . . . . . . .  26
     5.8.  BGP Graceful Restart Convergence Time . . . . . . . . . .  27
   6.  Reporting Format  . . . . . . . . . . . . . . . . . . . . . .  29
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  32
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  33
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1. Introduction ✨

This doc sets out how to benchmark the data-plane Forwarding Information Base (FIB) convergence performance of BGP in routers and switches, using topologies of three or four nodes 🍓 The method works for both IPv4 and IPv6. If a test only applies to one version, it's marked that way. For IPv6, the Device Under Test (DUT) needs Multiprotocol BGP (MP-BGP) support [RFC4760] [RFC2545]. Both Internal BGP (iBGP) and External BGP (eBGP) are covered in the tests where they apply 💖

The scope is BGP FIB convergence measurement, with BGP functionality limited to IPv4 and IPv6 as defined in [RFC4271] and MP-BGP [RFC4760] [RFC2545]. Other BGP extensions for Layer 2 and Layer 3 Virtual Private Networks (VPNs) are out of scope, and so is interaction with IGPs (IGP interworking) 🙈

1.1. Benchmarking Definitions

The terminology in this doc comes from [RFC4098], plus one new term 🧠

FIB (data-plane) convergence is when all FIB changes are complete, so all forwarded traffic takes the newly proposed route. RFC 4098 defines 'BGP device', 'FIB', and 'forwarded traffic'. Data-plane convergence is not the same thing as control-plane convergence inside a node, so don't mix them up 💅

This document defines a methodology to test:

data-plane convergence on a single BGP device that supports the BGP functionality within the scope above; and
a test topology of three or four nodes, which is enough to recreate the convergence events used in the various tests in this document.

1.2. Purpose of BGP FIB (Data-Plane) Convergence

In the current Internet architecture, inter-AS transit is mainly carried by BGP 🌐 To keep connectivity reliable within intra-domains or across inter-domains, fast recovery from failures is the most critical piece 😭 To keep traffic loss minimal, a lot of service providers want BGP implementations to converge the entire Internet routing table in sub-seconds at the FIB level 🔥

Service providers also want a standard way to compare these numbers across devices, so this document offers test methods for simple topologies. These simple tests give a quick, high-level check of BGP data-plane convergence across implementations from different vendors 🎀

1.3. Control-Plane Convergence

BGP convergence happens at two levels: Routing Information Base (RIB) convergence and FIB convergence. RFC 4098 defines the terms for BGP control-plane convergence. Methods that test control-plane convergence are out of scope for this document 🦋

1.4. Benchmarking Testing

To make sure results are repeatable, you need a careful setup of initial conditions and exact steps 🧚

This document proposes those initial conditions, the test steps, and how to check results. For uniform results, all optional parameters SHOULD be disabled and all settings SHOULD be changed to default, and that can include BGP timers too 💜

2. Existing Definitions and Requirements

"Benchmarking Terminology for Network Interconnect Devices" [RFC1242] and "Benchmarking Terminology for LAN Switching Devices" [RFC2285] SHOULD be reviewed alongside this document 📚 WLAN-specific terms and definitions are in Clauses 3 and 4 of the IEEE 802.11 standard [IEEE.802.11]. Common terms can also be found in RFC 1983 [RFC1983] 🌈

For clarity and continuity, this document follows the general template for benchmarking terminology in Section 2 of [RFC1242]. Definitions are in alphabetical order and grouped into sections so they're easy to find 🫶 The following terms are taken as defined in RFC 1242 [RFC1242]: Throughput, Latency, Constant Load, Frame Loss Rate, and Overhead Behavior. The following are taken as defined in [RFC2285]: Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test (DUT), and System Under Test (SUT) 👑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Iconic, periodt 💅✨

3. Test Topologies ✨

okay so this section is all about the test setups 🧚 they're for BGP benchmarking tests that measure how fast the FIB (data-plane) converges after BGP updates arrive. bestie, the layouts are lowkey the foundation of everything else, so pay attention 💅

There are three or four nodes in these setups, and there are four of them:

Basic test setup
Three-node setup for iBGP or eBGP convergence
Setup for eBGP multihop test Scenario
Four-node setup for iBGP or eBGP convergence

Individual tests point back to these topologies, so you'll see them referenced a lot 🦋

Figures 1 through 4 follow these conventions:

AS-X: Autonomous System X
Loopback Int: Loopback interface on a BGP-enabled device
HLP, HLP1, HLP2: Helper routers running the same version of BGP as the DUT
All devices MUST be synchronized using NTP or some other clock synchronization mechanism

3.1. General Reference Topologies

the emulator plays one or more BGP peers depending on the test case 🎀

        +----------+                             +------------+
        |          |   Traffic Interfaces        |            |
        |          |-----------------------1---- | tx         |
        |          |-----------------------2---- | tr1        |
        |          |-----------------------3-----| tr2        |
        |    DUT   |                             | Emulator   |
        |          |    Routing Interfaces       |            |
        |      Dp1 |---------------------------  |Emp1        |
        |          |      BGP Peering            |            |
        |      Dp2 |---------------------------- |Emp2        |
        |          |      BGP Peering            |            |
        +----------+                             +------------+

                     Figure 1: Basic Test Setup


      +------------+        +-----------+           +-----------+
      |            |        |           |           |           |
      |            |        |           |           |           |
      |   HLP      |        |  DUT      |           | Emulator  |
      |  (AS-X)    |--------| (AS-Y)    |-----------|  (AS-Z)   |
      |            |        |           |           |           |
      |            |        |           |           |           |
      |            |        |           |           |           |
      +------------+        +-----------+           +-----------+
              |                                            |
              |                                            |
              +--------------------------------------------+

      Figure 2: Three-Node Setup for eBGP and iBGP Convergence

           +----------------------------------------------+
           |                                              |
           |                                              |
      +------------+        +-----------+           +-----------+
      |            |        |           |           |           |
      |            |        |           |           |           |
      |   HLP      |        |  DUT      |           | Emulator  |
      |  (AS-X)    |--------| (AS-Y)    |-----------|  (AS-Z)   |
      |            |        |           |           |           |
      |            |        |           |           |           |
      |            |        |           |           |           |
      +------------+        +-----------+           +-----------+
           |Loopback-Int         |Loopback-Int
           |                     |
           +                     +

        Figure 3: BGP Convergence for eBGP Multihop Scenario


       +---------+     +--------+     +--------+     +---------+
       |         |     |        |     |        |     |         |
       |         |     |        |     |        |     |         |
       |  HLP1   |     |  DUT   |     |  HLP2  |     |Emulator |
       | (AS-X)  |-----| (AS-X) |-----| (AS-Y) |-----| (AS-Z)  |
       |         |     |        |     |        |     |         |
       |         |     |        |     |        |     |         |
       |         |     |        |     |        |     |         |
       +---------+     +--------+     +--------+     +---------+
            |                                             |
            |                                             |
            +---------------------------------------------+

       Figure 4: Four-Node Setup for eBGP and iBGP Convergence

4. Test Considerations 🌸

the tests for iBGP and eBGP are different, and that's the whole vibe here. both protocols use their own mechanisms to advertise, install, and learn routes 🔥 usually an iBGP route on the DUT gets installed and exported once its next hop is valid. for eBGP, the route is installed on the DUT with the remote interface address as the next hop, except in the multihop test case (which is spelled out in that test) 💜

4.1. Number of Peers

"Number of Peers" means the number of BGP neighbors or sessions the DUT has at the beginning of the test. the peers get established before the tests start, and the relationship can be iBGP or eBGP depending on what the test case needs ✨

the DUT sets up one or more BGP peer sessions with one or more emulated routers or Helper Nodes. you can add more peers if your testing needs them 🦋 and the number of peers enabled during testing should be well documented in the report matrix 📝

4.2. Number of Routes per Peer

"Number of Routes per Peer" is the number of routes advertised or learned by the DUT per session, or through a neighbor relationship with an emulator or Helper Node. the Tester is acting as a BGP neighbor here, and the Tester MUST advertise at least one route per BGP peer 🎀

every test run has to pin down the route stream in terms of route packing, route mixture, and number of routes. that route stream must be well documented in the reporting stream 🧾 RFC 4098 defines these terms, so go check that one too 🌈

It is RECOMMENDED that the user consider advertising the entire current Internet routing table per peering session, using an Internet route mixture with unique or non-unique routes 🌍 if you're using multiple peers, it's important to precisely document the timing sequence between the peer sending routes (as defined in RFC 4098) ⭐

4.3. Policy Processing/Reconfiguration

the DUT MUST run one baseline test where the policy is the Minimal policy as defined in RFC 4098 🫶 you can also do additional runs with the policy that was set up before the tests began. the exact policy settings MUST be documented as part of the test 📋

4.4. Configured Parameters (Timers, etc.)

there are configured parameters and timers that can change the measured BGP convergence times ⏱️ the benchmark metrics MAY be measured at any fixed values for these parameters 💅

It is RECOMMENDED these configure parameters have the following settings: a) default values specified by the respective RFC, b) platform-specific default parameters, and c) values as expected in the operational network. All optional BGP settings MUST be kept consistent across iterations of any specific tests 🔒

some examples of configured parameters that can impact measured BGP convergence time include, but are not limited to:

Interface failure detection timer
BGP keepalive timer
BGP holdtime
BGP update delay timer
ConnectRetry timer
TCP segment size
Minimum Route Advertisement Interval (MRAI)
MinASOriginationInterval (MAOI)
Route flap damping parameters
TCP Authentication Option (TCP AO or TCP MD5)
Maximum TCP window size
MTU

the basic-test settings for those parameters should be:

Interface failure detection timer (0 ms)
BGP keepalive timer (1 min)
BGP holdtime (3 min)
BGP update delay timer (0 s)
ConnectRetry timer (1 s)
TCP segment size (4096 bytes)
Minimum Route Advertisement Interval (MRAI) (0 s)
MinASOriginationInterval (MAOI) (0 s)
Route flap damping parameters (off)
TCP Authentication Option (off)

4.5. Interface Types

the type of media decides which test cases you can run 🛣️ every interface type has its own way of detecting link failures, and how fast that mechanism works will shape the results. all interfaces MUST be of the same media and throughput for every iteration of each test case 🍓

4.6. Measurement Accuracy

here's the tea ☕ packet loss is what we use to measure route convergence time, so the time between two successive packets offered to each individual route is the highest possible accuracy of any packet-loss-based measurement. when packet jitter is much less than the convergence time, it's a negligible source of error, so it gets treated as within tolerance 😌

other ways to measure convergence include the Time-Based Loss Method (TBLM) and Timestamp-Based Method (TBM) [RFC6414] 🧚 and this specification defines an exterior measurement on the input media (such as Ethernet) 🫧

4.7. Measurement Statistics

the benchmark measurements can vary from trial to trial because of the statistical nature of timer expirations, CPU scheduling, and so on 🎲 it is recommended to repeat the test multiple times. evaluating the test data has to happen with an understanding of generally accepted testing practices around repeatability, variance, and statistical significance of a small number of trials 📊

for any repeated tests that get averaged to remove variance, all parameters MUST remain the same 💖

4.8. Authentication

authentication in BGP is done using the TCP Authentication Option [RFC5925] 🔐 (in some legacy situations it may still be TCP MD5). processing the authentication hash can affect the control plane of the device, especially on devices with a large number of BGP peers and a lot of update traffic 😭 if authentication is enabled, it MUST be documented correctly in the reporting format 📝

also, trials MUST be with the same Secure Inter-Domain Routing (SIDR) features [RFC7115] [BGPsec] 🛡️ the best convergence tests would be run with no SIDR features first, and then repeated with the same SIDR features 🌈

4.9. Convergence Events

convergence events (or triggers) are abnormal occurrences in the network that start route flapping and force a steady-state network to reconverge 💥 in a real network, a series of convergence events can cause the convergence latency that operators want to test 🙈

these convergence events must be defined in terms of the sequences defined in RFC 4098. this basic document begins all tests with a router initial setup, and additional documents will define BGP data-plane convergence based on peer initialization 🧩

the convergence events may or may not be tied to an actual failure. a soft reset [RFC4098] does not clear the RIB or FIB tables 🌸 a hard reset clears BGP peer sessions, RIB tables, and FIB tables 💀

4.10. High Availability

because there are different Non-Stop-Routing (sometimes called High-Availability) solutions from different vendors, it is RECOMMENDED that any redundancy available in the routing processors should be disabled during convergence measurements 👑 for cases where the redundancy cannot be disabled, the results are no longer comparable, and the level of impact on the measurements is out of scope of this document 🥲

5. Test Cases 🎀

okay so every test in this section starts from the same baseline, so your results are actually comparable 💅

a. BGP peers are in Established state.

b. BGP state should be cleared from Established state to Idle prior to each test. This is recommended so every test starts with BGP peers forced back to Idle and the databases flushed 🧹

c. Traffic generation and routing should be verified in the topology, so there's no packet loss observed on any advertised routes ✨

d. You can measure the arrival timestamp of advertised routes by installing an inline monitoring device between the emulator and the DUT, or by using the span port of the DUT with an external analyzer 🔍 The time base of that inline monitor or external analyzer needs to be synchronized with the protocol and traffic emulator. Some modern emulators can capture and timestamp every NLRI packet leaving and arriving at their ports, and those timestamps will be almost identical to the arrival time at the DUT if the cable distance between the emulator and DUT is relatively short 🦋

5.1. Basic Convergence Tests 🌸

These test cases measure characteristics of a BGP implementation in non-failure scenarios, like:

RIB-IN Convergence
RIB-OUT Convergence
eBGP Convergence
iBGP Convergence

5.1.1. RIB-IN Convergence 📥

Objective:

This test measures the convergence time taken to receive and install a route in RIB using BGP.

Reference Test Setup:

This test uses the setup shown in Figure 1.

Procedure:

A. All variables affecting convergence should be set to a basic test state (as defined in Section 4.4).

B. Establish BGP adjacency between the DUT and one peer of the emulator, Emp1.

C. To make sure adjacency is established, wait for three keepalives to be received from the DUT, or a configurable delay, before moving on with the rest of the test.

D. Start the traffic from the emulator tx towards the DUT, targeted at a route from the route mixture (e.g., routeA). At first, no traffic SHOULD be observed on the egress interface, since routeA isn't installed in the forwarding database of the DUT yet 🙈

E. Advertise routeA from the peer (Emp1) to the DUT and record the time.

This is Tup(Emp1,Rt-A), also named XMT-Rt-time(Rt-A).

F. Record the time when routeA from Emp1 is received at the DUT.

This is Tup(DUT,Rt-A), also named RCV-Rt-time(Rt-A).

G. Record the time when the traffic targeted at routeA is received by the emulator on the appropriate traffic egress interface.

This is TR(TDr,Rt-A), also named DUT-XMT-Data-Time(Rt-A).

H. The difference between Tup(DUT,RT-A) and the traffic received time TR (TDr, Rt-A) is the FIB convergence time for routeA in the route mixture. Full convergence for the route update is the measurement between the first route (Rt-A) and the last route (Rt-last), which looks like this:

TR(TDr, Rt-last)- Tup(DUT, Rt-A), or
(DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A)

Note: It is recommended that a single test with the same route mixture be repeated several times. A report should provide the standard deviation and the average of all tests 📊

Running tests with a varying number of routes and route mixtures is important if you want a full picture of a single peer 💜

5.1.2. RIB-OUT Convergence 📤

Objective:

This test measures the convergence time an implementation takes to receive, install, and advertise a route using BGP.

Reference Test Setup:

This test uses the setup shown in Figure 2.

Procedure:

A. The Helper Node (HLP) MUST run same version of BGP as the DUT.

B. All devices MUST be synchronized using NTP or some local reference clock ⏰

C. All configuration variables for the Helper Node, DUT, and emulator SHOULD be set to the same values. These values MAY be basic test or a unique set completely described in the test setup.

D. Establish BGP adjacency between the DUT and the emulator.

E. Establish BGP adjacency between the DUT and the Helper Node.

F. To make sure adjacency is established, wait for three keepalives to be received from the DUT, or a configurable delay, before moving on with the rest of the test.

G. Start the traffic from the emulator towards the Helper Node, targeted at a specific route (e.g., routeA). At first, no traffic SHOULD be observed on the egress interface, since routeA isn't installed in the forwarding database of the DUT yet 🫶

H. Advertise routeA from the emulator to the DUT and note the time.

This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A).

I. Record when routeA is received by the DUT.

This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A).

J. Record the time when routeA is forwarded by the DUT towards the Helper Node.

This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A).

K. Record the time when the traffic targeted at routeA is received on the Route Egress Interface. This is TR(EMr, Rt-A), also named DUT-XMT-Data Time(Rt-A).

These are the formulas, so the math is clear 🧮

FIB convergence = (DUT-XMT-Data-Time -DUT-RCV-Rt-Time)(Rt-A)

RIB convergence = (DUT-XMT-Rt-Time - DUT-RCV-Rt-Time)(Rt-A)

For a whole route stream, convergence is characterized by:

a) individual route convergence for FIB and RIB, and

b) all-route convergence:

FIB-convergence = DUT-XMT-Data-Time(last) - DUT-RCV-Rt-Time(first), and

RIB-convergence = DUT-XMT-Rt-Time(last) - DUT-RCV-Rt-Time(first).

5.1.3. eBGP Convergence 🌍

Objective:

This test measures the convergence time an implementation takes to receive, install, and advertise a route in an eBGP scenario.

Reference Test Setup:

This test uses the setup shown in Figure 2. The RIB-IN and RIB-OUT scenarios both apply to this test case ✅

5.1.4. iBGP Convergence 🏠

Objective:

This test measures the convergence time an implementation takes to receive, install, and advertise a route in an iBGP scenario.

Reference Test Setup:

This test uses the setup shown in Figure 2. The RIB-IN and RIB-OUT scenarios both apply to this test case ✅

5.1.5. eBGP Multihop Convergence 🦋

Objective:

This test measures the convergence time an implementation takes to receive, install, and advertise a route in an eBGP Multihop scenario.

Reference Test Setup:

This test uses the setup shown in Figure 3. The DUT is used along with a Helper Node.

Procedure:

A. The Helper Node MUST run the same version of BGP as the DUT.

B. All devices MUST be synchronized using NTP or some local reference clock ⏰

C. All variables affecting convergence, like authentication, policies, and timers, SHOULD be set to basic settings.

D. All three devices (the DUT, the emulator, and the Helper Node) are configured with different ASs.

E. Loopback interfaces are configured on the DUT and the Helper Node, and connectivity is established between them using any config options available on the DUT.

F. Establish BGP adjacency between the DUT and the emulator.

G. Establish BGP adjacency between the DUT and the Helper Node.

H. To make sure adjacency is established, wait for three keepalives to be received from the DUT, or a configurable delay, before moving on with the rest of the test

I. Start the traffic from the emulator towards the DUT, targeted at a specific route (e.g., routeA).

J. At first, no traffic SHOULD be observed on the egress interface, since routeA isn't installed in the forwarding database of the DUT yet 🙈

K. Advertise routeA from the emulator to the DUT and note the time (Tup(EMx,RouteA), also named Route-Tx-time(Rt-A).

L. Record the time when the route is received by the DUT. This is Tup(EMr,DUT), also named Route-Rcv-time(Rt-A).

M. Record the time when the traffic targeted at routeA is received from the egress interface of the DUT on the emulator. This is Tup(EMd,DUT), named Data-Rcv-time(Rt-A).

N. Record the time when routeA is forwarded by the DUT towards the Helper Node. This is Tup(EMf,DUT), also named Route-Fwd-time(Rt-A).

FIB Convergence = (Data-Rcv-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 a varying number of routes and route mixtures. For each route mixture, the test should be repeated multiple times. The results should record the average, mean, and standard deviation 📈

5.2. BGP Failure/Convergence Events 💥

5.2.1. Physical Link Failure on DUT End 🔌

Objective:

This test measures the route convergence time due to a local link failure event at the DUT's Local Interface.

Reference Test Setup:

This test uses the setup shown in Figure 1. The shutdown event is defined as an administrative shutdown event on the DUT.

Procedure:

A. All variables affecting convergence, like authentication, policies, and timers, should be set to the basic-test policy.

B. Establish two BGP adjacencies from the DUT to the emulator, one over the peer interface and the other using a second peer interface.

C. Advertise the same route, routeA, over both adjacencies, with preferences set so that the Best Egress Interface for the preferred next hop is the (Emp1) interface 🎯

D. To make sure adjacency is established, wait for three keepalives to be received from the DUT, or a configurable delay, before moving on with the rest of the test.

E. Start the traffic from the emulator towards the DUT, targeted at a specific route (e.g., routeA). At first, traffic would be observed on the best egress route, Emp1, instead of Emp2.

F. Trigger the shutdown event of the Best Egress Interface on the DUT (Dp1). This time is called Shutdown time 💀

G. Measure the convergence time for the event to be detected and for traffic to be forwarded to the Next-Best Egress Interface (Dp2).

Time = Data-detect(Emp2) - Shutdown time

H. Stop the offered load and wait for the queues to drain. Then restart the data flow.

I. Bring up the link on the DUT's Best Egress Interface.

J. Measure the convergence time taken for the traffic to be rerouted from Dp2 back to the Best Egress Interface, Dp1.

Time = Data-detect(Emp1) - Bring Up time

K. It is recommended that the test be repeated with a varying number of routes and route mixtures, or with a number of routes and route mixtures closer to what is deployed in operational networks 🌈

5.2.2. Physical Link Failure on Remote/Emulator End 📡

Objective:

This test measures the route convergence time due to a local link failure event at the Tester's Local Interface.

Reference Test Setup:

This test uses the setup shown in Figure 1. The shutdown event is defined as a shutdown of the Tester's local interface via a logical shutdown event. The procedure used in Section 5.2.1 is used for the termination 🫶

5.2.3. ECMP Link Failure on DUT End 🦋

okay bestie, this one measures how long routing takes to recover after a local link dies on an ECMP member 🛣️✨ The FIB config and BGP are set up so two ECMP routes can get installed, but policy only lets the routes go out over one of the paths. so it's giving "two options on paper, one real路 path in practice" 💅

Reference Test Setup:

Same setup as Figure 1, and the procedure from Section 5.2.1 🎀

5.3. BGP Adjacency Failure (Non-Physical Link Failure) on Emulator

Objective:

This test measures route convergence time when a BGP adjacency fails on the emulator 🌸 (no physical link is pulled here, the session just goes down, which is giving "ghosting" energy 👻)

Reference Test Setup:

Same setup as Figure 1 🦋

Procedure:

A. Every variable that affects convergence, like authentication, policies, and timers, should be set to basic-policy. Clean slate, bestie 🧼

B. Set up two BGP adjacencies from the DUT to the emulator. One goes over the Best Egress Interface and the other goes over the Next-Best Egress Interface 👯‍♀️

C. Advertise the same route, routeA, over both adjacencies, with preferences set so that the Best Egress Interface for the preferred next hop is the (Emp1) interface 👑

D. To make sure the adjacencies actually come up, wait for three keepalives to be received from the DUT, or wait a configurable delay, before you move on with the rest of the test ⏳

E. Start traffic from the emulator toward the DUT, aimed at a specific route (e.g., routeA). At first, the traffic should show up on the Best Egress Interface 🌈

F. Remove the BGP adjacency with a software adjacency down on the emulator, on the Best Egress Interface. This moment is called BGPadj-down-time, also termed BGPpeer-down 💀

G. Measure how long it takes for the event to be detected and for traffic to be forwarded out the Next-Best Egress Interface. This time is Tr-rr2, also called TR2-traffic-on 🔥

Convergence = TR2-traffic-on - BGPpeer-down

H. Stop the offered load, wait for the queues to drain, and then restart the data flow 🧹

I. Bring the BGP adjacency back up on the emulator over the Best Egress Interface. This time is BGP-adj-up, also called BGPpeer-up 🦋

J. Measure how long it takes for traffic to get rerouted back onto the Best Egress Interface. This time is Tr-rr1, also called TR1-traffic-on 🎉

Convergence = TR1-traffic-on - BGPpeer-up

5.4. BGP Hard Reset Test Cases

5.4.1. BGP Non-Recovering Hard Reset Event on DUT

Objective:

This test measures route convergence time when the DUT gets hit with a hard reset 💥

Reference Test Setup:

Same setup as Figure 1 🎀

Procedure:

A. The requirement for this test case is that the hard reset event should be non-recovering, and it should only affect the adjacency between the DUT and the emulator on the Best Egress Interface 🙅‍♀️

B. Every variable that affects the test SHOULD be set to basic-test values. This one is a strong recommendation, not a suggestion 🫶

C. Set up two BGP adjacencies from the DUT to the emulator. One goes over the Best Egress Interface and the other goes over the Next-Best Egress Interface 👯‍♀️

D. Advertise the same route, routeA, over both adjacencies, with preferences set so that the Best Egress Interface for the preferred next hop is the (Emp1) interface 👑

E. To make sure the adjacencies actually come up, wait for three keepalives to be received from the DUT, or wait a configurable delay, before you move on with the rest of the test ⏳

F. Start traffic from the emulator toward the DUT, aimed at a specific route (e.g., routeA). At first, the traffic should show up on the Best Egress Interface 🌈

G. Trigger the hard reset event on the Best Egress Interface of the DUT. This moment is called time reset ⚡

H. The event gets detected and traffic is forwarded out the Next-Best Egress Interface. This moment is called time-traffic flow 🦋

I. Measure how long it takes for the event to be detected and for traffic to be forwarded out the Next-Best Egress Interface.

Time of convergence = time-traffic flow - time-reset

J. Stop the offered load, wait for the queues to drain, and restart 🧹

K. It is recommended that the test be repeated with a varying number of routes and route mixtures, or with a number of routes and route mixtures closer to what gets deployed in operational networks 🌍

L. When a varying number of routes is used, convergence time is measured using the Loss-Derived method [RFC6412] 📊

M. Convergence time in this scenario is influenced by failure detection time on the Tester, BGP keepalive time, and routing and forwarding table update time ⏱️

5.5. BGP Soft Reset

Objective:

This test measures how long an implementation takes to service a BGP Route Refresh message and advertise a route 🔁

Reference Test Setup:

Same setup as Figure 2 🦋

Procedure:

A. The BGP implementation on the DUT and the Helper Node needs to support the BGP Route Refresh Capability [RFC2918] 🎀

B. All devices MUST be synchronized using NTP or some local reference clock. No clock drift drama allowed 🕰️

C. Every variable that affects convergence, like authentication, policies, and timers, should be set to basic-test defaults 🧼

D. The DUT and the Helper Node are configured in the same AS, whereas the emulator is configured under a different AS 🏠

E. Establish a BGP adjacency between the DUT and the emulator 🤝

F. Establish a BGP adjacency between the DUT and the Helper Node 🤝

G. To make sure the adjacencies actually come up, wait for three keepalives to be received from the DUT, or wait a configurable delay, before you move on with the rest of the test ⏳

H. Configure a policy under BGP on the Helper Node to deny routes received from the DUT 🚫

I. Advertise routeA from the emulator to the DUT 📣

J. The DUT will try to advertise the route to the Helper Node, and it will get denied 🙅‍♀️

K. Wait for three keepalives 🫧

L. Start traffic from the emulator toward the Helper Node, aimed at a specific route, say routeA. At first, no traffic should be observed on the egress interface, because routeA isn't present there yet 👻

M. Remove the policy on the Helper Node and issue a route refresh request toward the DUT. Note the timestamp of this event. This is the RefreshTime ⏰

N. Record the time when the traffic aimed at routeA is received on the egress interface. This is RecTime 📝

O. The following equation gives the Route Refresh Convergence Time per route ✨

Route Refresh Convergence Time = (RecTime - RefreshTime)

5.6. BGP Route Withdrawal Convergence Time

Objective:

This test measures how long an implementation takes to service a BGP withdraw message and advertise the withdraw 🗑️

Reference Test Setup:

Same setup as Figure 2 🎀

Procedure:

A. This test has two steps, used to figure out the Total Withdraw Processing Time 🧮

B. Step 1:

(1) All devices MUST be synchronized using NTP or some local reference clock. Clocks, but make it consistent 🕰️

(2) All variables should be set to basic-test parameters 🧼

(3) The DUT and Helper Node are configured in the same AS, whereas the emulator is configured under a different AS 🏠

(4) Establish a BGP adjacency between the DUT and the emulator 🤝

(5) To make sure the adjacency actually comes up, wait for three keepalives to be received from the DUT, or wait a configurable delay, before you move on with the rest of the test ⏳

(6) Start traffic from the emulator toward the DUT, aimed at a specific route (e.g., routeA). At first, no traffic should be observed on the egress interface, because routeA isn't on the DUT yet 👻

(7) Advertise routeA from the emulator to the DUT 📣

(8) Traffic aimed at routeA is received on the egress interface 🌈

(9) Now the Tester sends a request to withdraw routeA to the DUT. TRx(Awith) is also called WdrawTime1(Rt-A) 🗑️

(10) Record the time when no traffic is observed, as determined by the emulator. This is the RouteRemoveTime1(Rt-A) ⏹️

(11) The difference between RouteRemoveTime1 and WdrawTime1 is the WdrawConvTime1 🧠

WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) -
WdrawTime1(Rt-A)

C. Step 2:

(1) Continuing from Step 1, re-advertise routeA from the Tester back to the DUT 🔄

(2) The DUT will try to advertise routeA to the Helper Node (this assumes there is a session between the DUT and the Helper Node) 🫶

(3) Start traffic from the emulator toward the Helper Node, aimed at a specific route (e.g., routeA). Traffic will be observed on the egress interface once routeA is received by the Helper Node 🌊

WATime=time traffic first flows

(4) Now the Tester sends a request to withdraw routeA to the DUT. This is the WdrawTime2(Rt-A) 🗑️

WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A)

(5) The DUT processes the withdraw and sends it to the Helper Node 📤

(6) Record the time when no traffic is observed, as determined by the emulator. This is:

TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A)

(7) The Total Withdraw Processing Time is:

TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) -
WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A))

5.7. BGP Path Attribute Change Convergence Time

Objective:

This test measures how long an implementation takes to service a BGP Path Attribute Change 🔀

Reference Test Setup:

Same setup as Figure 1 🦋

Procedure:

A. This test only applies to Well-Known Mandatory Attributes, like origin, AS path, and next hop 🏷️

B. In each iteration of the test, only one of these mandatory attributes gets varied, and the others stay the same 🎯

C. All devices MUST be synchronized using NTP or some local reference clock 🕰️

D. All variables should be set to basic-test parameters 🧼

E. Advertise the same route, routeA, over both adjacencies, with preferences set so that the Best Egress Interface for the preferred next hop is the (Emp1) interface 👑

F. To make sure the adjacencies actually come up, wait for three keepalives to be received from the DUT, or wait a configurable delay, before you move on with the rest of the test ⏳

G. Start traffic from the emulator toward the DUT, aimed at the specific route (e.g., routeA). At first, the traffic should show up on the Best Egress Interface 🌈

H. Now advertise the same route, routeA, on the Next-Best Egress Interface, but vary one of the well-known mandatory attributes so it has a preferred value over that interface. This is called Tbetter. The other values need to match what was advertised on the Best-Egress adjacency 💅

TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A)

I. Measure how long it takes for the event to be detected and for traffic to be forwarded out the Next-Best Egress Interface.

DUT(Path-Change, Rt-A) = Path-switch time(Rt-A)

Convergence = Path-switch time(Rt-A) - Path Change Event
Time(Rt-A)

J. Stop the offered load, wait for the queues to drain, and restart 🧹

K. Repeat the test for the various attributes 🔁

5.8. BGP Graceful Restart Convergence Time ✨

okay so bestie, this one is all about how fast a BGP router bounces back when it goes through a Graceful Restart Event 🔄 the whole point is to measure how long the DUT (the device under test, aka the star of the show 💅) takes to service that restart and get a route advertised again. the terminology lives in [RFC4098] 📖

Objective:

The objective is to measure the route convergence time taken by an implementation during a Graceful Restart Event, as detailed in the terminology document [RFC4098]. 💖

Reference Test Setup:

This test uses the setup as shown in Figure 4. 🎀

Procedure:

A. It measures the time taken by an implementation to service a BGP Graceful Restart Event and advertise a route. 🦋

B. The Helper Nodes are the same model as the DUT and run the same BGP implementation as the DUT. 👯‍♀️

C. The BGP implementation on the DUT and Helper Node needs to support the BGP Graceful Restart Mechanism [RFC4724]. 🌸

D. All devices MUST be synchronized using NTP or some local reference clock. ⏰ this one is a MUST, so no skipping it, periodt 💅

E. All variables are set to basic-test values. ✨

F. The DUT and Helper Node 1 (HLP1) are configured in the same AS, whereas the emulator and Helper Node 2 (HLP2) are configured under different ASs. 🧚

G. Establish BGP adjacency between the DUT and Helper Nodes. 🤝

H. Establish BGP adjacency between the Helper Node 2 and the emulator. 🤝

I. To ensure adjacency establishment, wait for three keepalives to be received from the DUT or a configurable delay before proceeding with the rest of the test. ⏳

J. Configure a policy under the BGP on Helper Node 1 to deny routes received from the DUT. 🚫

K. Advertise routeA from the emulator to Helper Node 2. 📣

L. Helper Node 2 advertises the route to the DUT and the DUT will try to advertise the route to Helper Node 1, which will be denied. so the DUT tries, HLP1 says nope 🙅‍♀️

M. Wait for three keepalives. 💜

N. Start the traffic from the emulator towards the Helper Node 1 targeted at the specific route (e.g., routeA). Initially, no traffic would be observed on the egress interface as routeA is not present. 👀 no traffic yet, that's the plan

O. Perform a Graceful Restart Trigger Event on the DUT and note the time. This is the GREventTime. ⏱️ this timestamp is the anchor for everything, so write it down bestie 📝

P. Remove the policy on Helper Node 1. 🔓

Q. Record the time when the traffic targeted towards routeA is received on the egress interface.

This is TRr(DUT, routeA), also called RecTime(Rt-A). 🎯

R. The following equation represents the Graceful Restart Convergence Time.

Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - GREventTime) - RIB-IN)

the math, lowkey iconic 🧮 take the recorded time, subtract the event time, then subtract RIB-IN 🍓

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 the BGP Refresh messages. The reason for this assumption is that there is a narrow window of time where after switchover, when we remove the policy from Helper Node 1, implementations might generate Route Refresh automatically and this request might be serviced before the DUT actually switches over and re-establishes BGP adjacencies with the peers. 🙈 so basically, the timing is tricky: a Route Refresh could sneak in before the DUT is fully back up, and this assumption keeps that from messing up the results 💀

6. Reporting Format 📊

okay the reporting part, this is where you get organized bestie 🗂️

For each test case, it is recommended that the reporting tables below are completed, and all time values SHOULD be reported with resolution as specified in [RFC4098]. 🌈 the tables are recommended, but the time values SHOULD use the resolution from [RFC4098], so keep those precise ✨

 Parameter                        Units or Description
 ===========================      ==========================
 Test case                        Test case number

 Test topology                    1, 2, 3, or 4

 Parallel links                   Number of parallel links

 Interface type                   Gigabit Ethernet (GigE),
                                  Packet over SONET (POS), ATM, other

 Convergence Event                Hard reset, soft reset, link
                                  failure, or other defined

 eBGP sessions                    Number of eBGP sessions

 iBGP sessions                    Number of iBGP sessions

 eBGP neighbor                    Number of eBGP neighbors

 iBGP neighbor                    Number of iBGP neighbors

 Routes per peer                  Number of routes

 Total unique routes              Number of routes

 Total non-unique routes          Number of routes

 IGP configured                   IS-IS, OSPF, static, or other

 Route mixture                    Description of route mixture

 Route packing                    Number of routes included in an update

 Policy configured                Yes, No

 SIDR origin authentication       Yes, No
 [RFC7115]

 bgp-sec [BGPsec]                 Yes, No
 Packet size offered              Bytes
 to the DUT

 Offered load                     Packets per second

 Packet sampling interval         Seconds
 on Tester

 Forwarding delay threshold       Seconds

 Timer values configured on DUT

   Interface failure              Seconds
    indication delay
   Hold time                      Seconds
   MinRouteAdvertisementInterval  Seconds
      (MRAI)
   MinASOriginationInterval       Seconds
      (MAOI)
   Keepalive time                 Seconds
   ConnectRetry                   Seconds

 TCP parameters for DUT and Tester
   Maximum Segment Size (MSS)     Bytes
   Slow start threshold           Bytes
   Maximum window size            Bytes

   Test Details:

   a.  If the Offered Load matches a subset of routes, describe how this
       subset is selected.

   b.  Describe how the convergence event is applied; does it cause
       instantaneous traffic loss or not?

   c.  If there is any policy configured, describe the configured
       policy.

   Complete the table below for the initial convergence event and the
   reversion convergence event.

        Parameter                        Unit
        ===========================      ==========================
        Convergence Event                Initial or reversion

        Traffic Forwarding Metrics
          Total number of packets        Number of packets
           offered to the DUT
          Total number of packets        Number of packets
           forwarded by the DUT
          Connectivity packet loss       Number of packets
          Convergence packet loss        Number of packets
          Out-of-order packets           Number of packets
          Duplicate packets              Number of packets

        Convergence Benchmarks

          Rate-Derived Method [RFC6412]:
           First route convergence       Seconds
            time
           Full convergence time         Seconds

          Loss-Derived Method [RFC6412]:
           Loss-Derived convergence      Seconds
            time

          Route-Specific (R-S) Loss-Derived
          Method:
           Minimum R-S convergence       Seconds
            time
           Maximum R-S convergence       Seconds
            time
           Median R-S convergence        Seconds
            time
           Average R-S convergence       Seconds
            time

        Loss of Connectivity (LoC) Benchmarks

          Loss-Derived Method:
           Loss-Derived loss of          Seconds
            connectivity period

          Route-Specific Loss-Derived
           Method:
           Minimum LoC period [n]        Array of seconds
           Minimum Route LoC period      Seconds
           Maximum Route LoC period      Seconds
           Median Route LoC period       Seconds
           Average Route LoC period      Seconds

7. Security Considerations 🔐

this section is SERIOUS bestie, no snacks during this part 😤 it's a whole lab-safety talk and it's important 💅

Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above. 🧪

The benchmarking network topology is an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network. 🚨 MUST NOT means MUST NOT, so keep that test lab isolated, no exceptions 🙅‍♀️

Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable and external to the DUT/SUT. 📦 we only look at what we can see from the outside, no peeking inside the box 👀

Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks. 🛡️ so the device shouldn't get a secret benchmark mode, and its security should look the same in the lab as it does in the real world 🫶

8. References 📚

8.1. Normative References 🎀

[IEEE.802.11] IEEE, "IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks -- Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6178209>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <http://www.rfc-editor.org/info/rfc2918>.

[RFC4098] Berkowitz, H., Davies, E., Ed., Hares, S., Krishnaswamy, P., and M. Lepp, "Terminology for Benchmarking BGP Device Convergence in the Control Plane", RFC 4098, DOI 10.17487/RFC4098, June 2005, <http://www.rfc-editor.org/info/rfc4098>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, DOI 10.17487/RFC6412, November 2011, <http://www.rfc-editor.org/info/rfc6412>.

8.2. Informative References ✨

okay bestie, these are the extra reads that back up the spec 📚🫶

[BGPsec] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Work in Progress, draft-ietf-sidr-bgpsec-protocol-15, March 2016.
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, http://www.rfc-editor.org/info/rfc1242.
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, RFC 1983, DOI 10.17487/RFC1983, August 1996, http://www.rfc-editor.org/info/rfc1983.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, DOI 10.17487/RFC2285, February 1998, http://www.rfc-editor.org/info/rfc2285.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, http://www.rfc-editor.org/info/rfc2545.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, http://www.rfc-editor.org/info/rfc4724.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, http://www.rfc-editor.org/info/rfc4760.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, http://www.rfc-editor.org/info/rfc5925.
[RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, "Benchmarking Terminology for Protection Performance", RFC 6414, DOI 10.17487/RFC6414, November 2011, http://www.rfc-editor.org/info/rfc6414.
[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, http://www.rfc-editor.org/info/rfc7115.

Acknowledgements

the people who helped make this doc happen 🥹💖 huge thanks to Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay Karthik, and Eric Brendel for their input and convos on different sections of the document. we also want to shout out Will Liu, Hubert Gee, Semion Lisyansky, and Faisal Shah for reviewing it and giving feedback 🫶✨

Authors' Addresses

the squad behind the doc 💅🎀

Rajiv Papneja, Huawei Technologies, Email: rajiv.papneja@huawei.com
Bhavani Parise, Skyport Systems, Email: bparise@skyportsystems.com
Susan Hares, Huawei Technologies, Email: shares@ndzh.com
Dean Lee, IXIA, Email: dlee@ixiacom.com
Ilya Varlashkin, Google, Email: ilya@nobulus.com

📦 where this page comes from

ietf: rfc7747 2016-04
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 7747

Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence 💖

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

1.1. Benchmarking Definitions

1.2. Purpose of BGP FIB (Data-Plane) Convergence

1.3. Control-Plane Convergence

1.4. Benchmarking Testing

2. Existing Definitions and Requirements

3. Test Topologies ✨

3.1. General Reference Topologies

4. Test Considerations 🌸

4.1. Number of Peers

4.2. Number of Routes per Peer

4.3. Policy Processing/Reconfiguration

4.4. Configured Parameters (Timers, etc.)

4.5. Interface Types

4.6. Measurement Accuracy

4.7. Measurement Statistics

4.8. Authentication

4.9. Convergence Events

4.10. High Availability

5. Test Cases 🎀

5.1. Basic Convergence Tests 🌸

5.1.1. RIB-IN Convergence 📥

5.1.2. RIB-OUT Convergence 📤

5.1.3. eBGP Convergence 🌍

5.1.4. iBGP Convergence 🏠

5.1.5. eBGP Multihop Convergence 🦋

5.2. BGP Failure/Convergence Events 💥

5.2.1. Physical Link Failure on DUT End 🔌

5.2.2. Physical Link Failure on Remote/Emulator End 📡

5.2.3. ECMP Link Failure on DUT End 🦋

5.3. BGP Adjacency Failure (Non-Physical Link Failure) on Emulator

5.4. BGP Hard Reset Test Cases

5.4.1. BGP Non-Recovering Hard Reset Event on DUT

5.5. BGP Soft Reset

5.6. BGP Route Withdrawal Convergence Time

5.7. BGP Path Attribute Change Convergence Time

5.8. BGP Graceful Restart Convergence Time ✨

6. Reporting Format 📊

7. Security Considerations 🔐

8. References 📚

8.1. Normative References 🎀

8.2. Informative References ✨

Acknowledgements

Authors' Addresses