doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc7747.txt b/doc/rfc/rfc7747.txt
new file mode 100644
index 0000000..a59c2ce
--- /dev/null
+++ b/doc/rfc/rfc7747.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Papneja
+Request for Comments: 7747                           Huawei Technologies
+Category: Informational                                        B. Parise
+ISSN: 2070-1721                                          Skyport Systems
+                                                                S. Hares
+                                                     Huawei Technologies
+                                                                  D. Lee
+                                                                    IXIA
+                                                           I. Varlashkin
+                                                                  Google
+                                                              April 2016
+
+
+             Basic BGP Convergence Benchmarking Methodology
+                       for Data-Plane Convergence
+
+Abstract
+
+   BGP is widely deployed and used by several service providers as the
+   default inter-AS (Autonomous System) routing protocol.  It is of
+   utmost importance to 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 paths are installed.  This document provides the
+   basic BGP benchmarking methodology using existing BGP convergence
+   terminology as defined in RFC 4098.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7747.
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 1]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 2]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+Table of Contents
+
+   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
+
+
+
+
+Papneja, et al.               Informational                     [Page 3]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+1.  Introduction
+
+   This document defines the methodology for benchmarking data-plane
+   Forwarding Information Base (FIB) convergence performance of BGP in
+   routers and switches using topologies of three or four nodes.  The
+   methodology proposed in this document applies to both IPv4 and IPv6,
+   and if a particular test is unique to one version, it is marked
+   accordingly.  For IPv6 benchmarking, the Device Under Test (DUT) will
+   require the support of Multiprotocol BGP (MP-BGP) [RFC4760]
+   [RFC2545].  Similarly, both Internal BGP (iBGP) and External BGP
+   (eBGP) are covered in the tests as applicable.
+
+   The scope of this document is to provide methodology for BGP FIB
+   convergence measurements with BGP functionality limited to IPv4 and
+   IPv6 as defined in [RFC4271] and MP-BGP [RFC4760] [RFC2545].  Other
+   BGP extensions to support Layer 2 and Layer 3 Virtual Private
+   Networks (VPNs) are outside the scope of this document.  Interaction
+   with IGPs (IGP interworking) is outside the scope of this document.
+
+1.1.  Benchmarking Definitions
+
+   The terminology used in this document is defined in [RFC4098].  One
+   additional term is defined in this document as follows.
+
+   FIB (data-plane) convergence is defined as the completion of all FIB
+   changes so that all forwarded traffic then takes the newly proposed
+   route.  RFC 4098 defines the terms 'BGP device', 'FIB', and
+   'forwarded traffic'.  Data-plane convergence is different than
+   control-plane convergence within a node.
+
+   This document defines methodology to test
+
+   o  data-plane convergence on a single BGP device that supports the
+      BGP functionality with a scope as outlined above; and
+
+   o  using test topology of three or four nodes that are sufficient to
+      recreate the convergence events used in the various tests of this
+      document.
+
+1.2.  Purpose of BGP FIB (Data-Plane) Convergence
+
+   In the current Internet architecture, the inter-AS transit is
+   primarily available through BGP.  To maintain reliable connectivity
+   within intra-domains or across inter-domains, fast recovery from
+   failures remains most critical.  To ensure minimal traffic losses,
+   many service providers are requiring BGP implementations to converge
+   the entire Internet routing table within sub-seconds at FIB level.
+
+
+
+
+Papneja, et al.               Informational                     [Page 4]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   Furthermore, to compare these numbers amongst various devices,
+   service providers are also looking at ways to standardize the
+   convergence measurement methods.  This document offers test methods
+   for simple topologies.  These simple tests will provide a quick high-
+   level check of BGP data-plane convergence across multiple
+   implementations from different vendors.
+
+1.3.  Control-Plane Convergence
+
+   The convergence of BGP occurs at two levels: Routing Information Base
+   (RIB) and FIB convergence.  RFC 4098 defines terms for BGP control-
+   plane convergence.  Methodologies that test control-plane convergence
+   are out of scope for this document.
+
+1.4.  Benchmarking Testing
+
+   In order to ensure that the results obtained in tests are repeatable,
+   careful setup of initial conditions and exact steps are required.
+
+   This document proposes these initial conditions, test steps, and
+   result checking.  To ensure uniformity of the results, all optional
+   parameters SHOULD be disabled and all settings SHOULD be changed to
+   default; these may include BGP timers as well.
+
+2.  Existing Definitions and Requirements
+
+   "Benchmarking Terminology for Network Interconnect Devices" [RFC1242]
+   and "Benchmarking Terminology for LAN Switching Devices" [RFC2285]
+   SHOULD be reviewed in conjunction with this document.  WLAN-specific
+   terms and definitions are also provided in Clauses 3 and 4 of the
+   IEEE 802.11 standard [IEEE.802.11].  Commonly used terms may also be
+   found in RFC 1983 [RFC1983].
+
+   For the sake of clarity and continuity, this document adopts the
+   general template for benchmarking terminology set out in Section 2 of
+   [RFC1242].  Definitions are organized in alphabetical order and
+   grouped into sections for ease of reference.  The following terms are
+   assumed to be taken as defined in RFC 1242 [RFC1242]: Throughput,
+   Latency, Constant Load, Frame Loss Rate, and Overhead Behavior.  In
+   addition, the following terms 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].
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 5]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+3.  Test Topologies
+
+   This section describes the test setups for use in BGP benchmarking
+   tests measuring convergence of the FIB (data-plane) after BGP updates
+   have been received.
+
+   These test setups have three or four nodes with the following
+   configuration:
+
+   1.  Basic test setup
+
+   2.  Three-node setup for iBGP or eBGP convergence
+
+   3.  Setup for eBGP multihop test Scenario
+
+   4.  Four-node setup for iBGP or eBGP convergence
+
+   Individual tests refer to these topologies.
+
+   Figures 1 through 4 use the following conventions:
+
+   o  AS-X: Autonomous System X
+
+   o  Loopback Int: Loopback interface on a BGP-enabled device
+
+   o  HLP, HLP1, HLP2: Helper routers running the same version of BGP as
+      the DUT
+
+   o  All devices MUST be synchronized using NTP or some other clock
+      synchronization mechanism
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 6]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+3.1.  General Reference Topologies
+
+   Emulator acts as one or more BGP peers for different test cases.
+
+           +----------+                             +------------+
+           |          |   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 7]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+              +----------------------------------------------+
+              |                                              |
+              |                                              |
+         +------------+        +-----------+           +-----------+
+         |            |        |           |           |           |
+         |            |        |           |           |           |
+         |   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 test cases for measuring convergence for iBGP and eBGP are
+   different.  Both iBGP and eBGP use different mechanisms to advertise,
+   install, and learn the routes.  Typically, an iBGP route on the DUT
+   is installed and exported when the next hop is valid.  For eBGP, the
+   route is installed on the DUT with the remote interface address as
+   the next hop, with the exception of the multihop test case (as
+   specified in the test).
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 8]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+4.1.  Number of Peers
+
+   "Number of Peers" is defined as the number of BGP neighbors or
+   sessions the DUT has at the beginning of the test.  The peers are
+   established before the tests begin.  The relationship could be either
+   iBGP or eBGP peering depending upon the test case requirement.
+
+   The DUT establishes one or more BGP peer sessions with one or more
+   emulated routers or Helper Nodes.  Additional peers can be added
+   based on the testing requirements.  The number of peers enabled
+   during the testing should be well documented in the report matrix.
+
+4.2.  Number of Routes per Peer
+
+   "Number of Routes per Peer" is defined as 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, emulating
+   as a BGP neighbor, MUST advertise at least one route per BGP peer.
+
+   Each test run must identify the route stream in terms of route
+   packing, route mixture, and number of routes.  This route stream must
+   be well documented in the reporting stream.  RFC 4098 defines these
+   terms.
+
+   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 multiple peers
+   are used, it is 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 policy is the Minimal policy
+   as defined in RFC 4098.  Additional runs may be done with the policy
+   that was set up before the tests began.  Exact policy settings MUST
+   be documented as part of the test.
+
+4.4.  Configured Parameters (Timers, etc.)
+
+   There are configured parameters and timers that may impact the
+   measured BGP convergence times.
+
+   The benchmark metrics MAY be measured at any fixed values for these
+   configured parameters.
+
+
+
+
+
+
+
+Papneja, et al.               Informational                     [Page 9]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   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
+
+   Examples of the configured parameters that may impact measured BGP
+   convergence time include, but are not limited to:
+
+      1.  Interface failure detection timer
+
+      2.  BGP keepalive timer
+
+      3.  BGP holdtime
+
+      4.  BGP update delay timer
+
+      5.  ConnectRetry timer
+
+      6.  TCP segment size
+
+      7.  Minimum Route Advertisement Interval (MRAI)
+
+      8.  MinASOriginationInterval (MAOI)
+
+      9.  Route flap damping parameters
+
+      10.  TCP Authentication Option (TCP AO or TCP MD5)
+
+      11.  Maximum TCP window size
+
+      12.  MTU
+
+   The basic-test settings for the parameters should be:
+
+      1.  Interface failure detection timer (0 ms)
+
+      2.  BGP keepalive timer (1 min)
+
+      3.  BGP holdtime (3 min)
+
+      4.  BGP update delay timer (0 s)
+
+      5.  ConnectRetry timer (1 s)
+
+      6.  TCP segment size (4096 bytes)
+
+      7.  Minimum Route Advertisement Interval (MRAI) (0 s)
+
+
+
+Papneja, et al.               Informational                    [Page 10]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+      8.  MinASOriginationInterval (MAOI) (0 s)
+
+      9.  Route flap damping parameters (off)
+
+      10.  TCP Authentication Option (off)
+
+4.5.  Interface Types
+
+   The type of media dictates which test cases may be executed; each
+   interface type has a unique mechanism for detecting link failures,
+   and the speed at which that mechanism operates will influence the
+   measurement results.  All interfaces MUST be of the same media and
+   throughput for all iterations of each test case.
+
+4.6.  Measurement Accuracy
+
+   Since observed packet loss is used to measure the route convergence
+   time, 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 is a negligible source of error, and hence, it
+   will be treated as within tolerance.
+
+   Other options to measure convergence are the Time-Based Loss Method
+   (TBLM) and Timestamp-Based Method (TBM) [RFC6414].
+
+   An exterior measurement on the input media (such as Ethernet) is
+   defined by this specification.
+
+4.7.  Measurement Statistics
+
+   The benchmark measurements may vary for each trial due to the
+   statistical nature of timer expirations, CPU scheduling, etc.  It is
+   recommended to repeat the test multiple times.  Evaluation of the
+   test data must be done with an understanding of generally accepted
+   testing practices regarding repeatability, variance, and statistical
+   significance of a small number of trials.
+
+   For any repeated tests that are 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, the authentication may still
+   be with TCP MD5).  The processing of the authentication hash,
+   particularly in devices with a large number of BGP peers and a large
+   amount of update traffic, can have an impact on the control plane of
+
+
+
+Papneja, et al.               Informational                    [Page 11]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   the device.  If authentication is enabled, it MUST be documented
+   correctly in the reporting format.
+
+   Also, it is recommended that trials MUST be with the same Secure
+   Inter-Domain Routing (SIDR) features [RFC7115] [BGPsec].  The best
+   convergence tests would be with no SIDR features and then to repeat
+   the convergence tests with the same SIDR features.
+
+4.9.  Convergence Events
+
+   Convergence events or triggers are defined as abnormal occurrences in
+   the network, which initiate route flapping in the network and hence
+   forces the reconvergence of a steady state network.  In a real
+   network, a series of convergence events may cause convergence latency
+   operators desire 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.  Additional documents will define BGP data-
+   plane convergence based on peer initialization.
+
+   The convergence events may or may not be tied to the 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
+
+   Due to the different Non-Stop-Routing (sometimes referred to High-
+   Availability) solutions available from different vendors, it is
+   RECOMMENDED that any redundancy available in the routing processors
+   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 impact on the measurements is out of
+   scope of this document.
+
+5.  Test Cases
+
+   All tests defined under this section assume the following:
+
+   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 to ensure that all tests start
+       with BGP peers being forced back to Idle state and databases
+       flushed.
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 12]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   c.  Furthermore, the traffic generation and routing should be
+       verified in the topology to ensure there is no packet loss
+       observed on any advertised routes.
+
+   d.  The arrival timestamp of advertised routes can be measured by
+       installing an inline monitoring device between the emulator and
+       the DUT or by using the span port of the DUT connected with an
+       external analyzer.  The time base of such an inline monitor or
+       external analyzer needs to be synchronized with the protocol and
+       traffic emulator.  Some modern emulators may have the capability
+       to capture and timestamp every NLRI packet leaving and arriving
+       at the emulator ports.  The timestamps of these NLRI packets 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:
+
+   1.  RIB-IN Convergence
+
+   2.  RIB-OUT Convergence
+
+   3.  eBGP Convergence
+
+   4.  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 as 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.
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 13]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   C.  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.
+
+   D.  Start the traffic from the emulator tx towards the DUT targeted
+       at a route specified in the route mixture (e.g., routeA).
+       Initially, no traffic SHOULD be observed on the egress interface
+       as routeA is not installed in the forwarding database of the DUT.
+
+   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 towards 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 the Tup(DUT,RT-A) and traffic received
+       time (TR (TDr, Rt-A) is the FIB convergence time for routeA in
+       the route mixture.  A full convergence for the route update is
+       the measurement between the first route (Rt-A) and the last route
+       (Rt-last).
+
+          Route update convergence is
+
+          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 to get a full characterization of a single peer.
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 14]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+5.1.2.  RIB-OUT Convergence
+
+   Objective:
+
+      This test measures the convergence time taken by an implementation
+      to receive, install, and advertise a route using BGP.
+
+   Reference Test Setup:
+
+      This test uses the setup as 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 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.
+
+   G.  Start the traffic from the emulator towards the Helper Node
+       targeted at a specific route (e.g., routeA).  Initially, no
+       traffic SHOULD be observed on the egress interface as routeA is
+       not installed in the forwarding database of the DUT.
+
+   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).
+
+
+
+Papneja, et al.               Informational                    [Page 15]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   K.  Record the time when the traffic targeted towards routeA is
+       received on the Route Egress Interface.  This is TR(EMr, Rt-A),
+       also named DUT-XMT-Data Time(Rt-A).
+
+          FIB convergence = (DUT-XMT-Data-Time -DUT-RCV-Rt-Time)(Rt-A)
+
+          RIB convergence = (DUT-XMT-Rt-Time - DUT-RCV-Rt-Time)(Rt-A)
+
+          Convergence for a route stream is characterized by
+
+          a) individual route convergence for FIB and RIB, and
+
+          b) all route convergence of
+
+          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 taken by an implementation
+      to receive, install, and advertise a route in an eBGP Scenario.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 2, and the scenarios
+      described in RIB-IN and RIB-OUT are applicable to this test case.
+
+5.1.4.  iBGP Convergence
+
+   Objective:
+
+      This test measures the convergence time taken by an implementation
+      to receive, install, and advertise a route in an iBGP Scenario.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 2, and the scenarios
+      described in RIB-IN and RIB-OUT are applicable to this test case.
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 16]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+5.1.5.  eBGP Multihop Convergence
+
+   Objective:
+
+      This test measures the convergence time taken by an implementation
+      to receive, install, and advertise a route in an eBGP Multihop
+      Scenario.
+
+   Reference Test Setup:
+
+      This test uses the setup as 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, emulator, and Helper Node, are
+       configured with different ASs.
+
+   E.  Loopback interfaces are configured on the DUT and 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 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
+
+   I.  Start the traffic from the emulator towards the DUT targeted at a
+       specific route (e.g., routeA).
+
+   J.  Initially, no traffic SHOULD be observed on the egress interface
+       as routeA is not installed in the forwarding database of the DUT.
+
+   K.  Advertise routeA from the emulator to the DUT and note the time
+       (Tup(EMx,RouteA), also named Route-Tx-time(Rt-A).
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 17]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   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 towards 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.  With each set route mixture,
+   the test should be repeated multiple times.  The results should
+   record the average, mean, 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 as 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 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 so that the Best Egress Interface for the preferred
+       next hop is (Emp1) interface.
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 18]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   D.  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.
+
+   E.  Start the traffic from the emulator towards the DUT targeted at a
+       specific route (e.g., routeA).  Initially, traffic would be
+       observed on the best egress route, Emp1, instead of Emp2.
+
+   F.  Trigger the shutdown event of 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
+       traffic to be forwarded to Next-Best Egress Interface (Dp2).
+
+          Time = Data-detect(Emp2) - Shutdown time
+
+   H.  Stop the offered load and wait for the queues to drain.  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 to 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 as shown in Figure 1.  The shutdown event
+      is defined as a shutdown of the local interface of the Tester via
+      a logical shutdown event.  The procedure used in Section 5.2.1 is
+      used for the termination.
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 19]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+5.2.3.  ECMP Link Failure on DUT End
+
+   Objective:
+
+      This test measures the route convergence time due to a local link
+      failure event at the ECMP member.  The FIB configuration and BGP
+      are set to allow two ECMP routes to be installed.  However, policy
+      directs the routes to be sent only over one of the paths.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 1, and the procedure
+      used in Section 5.2.1.
+
+5.3.  BGP Adjacency Failure (Non-Physical Link Failure) on Emulator
+
+   Objective:
+
+      This test measures the route convergence time due to BGP Adjacency
+      Failure on the emulator.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 1.
+
+   Procedure:
+
+   A.  All variables affecting convergence, like authentication,
+       policies, and timers, should be set to basic-policy.
+
+   B.  Establish two BGP adjacencies from the DUT to the emulator: one
+       over the Best Egress Interface and the other using the Next-Best
+       Egress Interface.
+
+   C.  Advertise the same route, routeA, over both adjacencies with
+       preferences so that the Best Egress Interface for the preferred
+       next hop is (Emp1) interface.
+
+   D.  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.
+
+   E.  Start the traffic from the emulator towards the DUT targeted at a
+       specific route (e.g., routeA).  Initially, traffic would be
+       observed on the Best Egress Interface.
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 20]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   F.  Remove BGP adjacency via a software adjacency down on the
+       emulator on the Best Egress Interface.  This time is called
+       BGPadj-down-time, also termed BGPpeer-down.
+
+   G.  Measure the convergence time for the event to be detected and
+       traffic to be forwarded to 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 and wait for the queues to drain and
+       restart the data flow.
+
+   I.  Bring up BGP adjacency on the emulator over the Best Egress
+       Interface.  This time is BGP-adj-up, also called BGPpeer-up.
+
+   J.  Measure the convergence time taken for the traffic to be rerouted
+       to 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 the route convergence time due to a hard reset
+      on the DUT.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 1.
+
+   Procedure:
+
+   A.  The requirement for this test case is that the hard reset event
+       should be non-recovering and should affect only the adjacency
+       between the DUT and the emulator on the Best Egress Interface.
+
+   B.  All variables affecting the test SHOULD be set to basic-test
+       values.
+
+   C.  Establish two BGP adjacencies from the DUT to the emulator: one
+       over the Best Egress Interface and the other using the Next-Best
+       Egress Interface.
+
+
+
+
+Papneja, et al.               Informational                    [Page 21]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   D.  Advertise the same route, routeA, over both adjacencies with
+       preferences so that the Best Egress Interface for the preferred
+       next hop is (Emp1) interface.
+
+   E.  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.
+
+   F.  Start the traffic from the emulator towards the DUT targeted at a
+       specific route (e.g., routeA).  Initially, traffic would be
+       observed on the Best Egress Interface.
+
+   G.  Trigger the hard reset event of the Best Egress Interface on the
+       DUT.  This time is called time reset.
+
+   H.  This event is detected and traffic is forwarded to the Next-Best
+       Egress Interface.  This time is called time-traffic flow.
+
+   I.  Measure the convergence time for the event to be detected and
+       traffic to be forwarded to Next-Best Egress Interface.
+
+          Time of convergence = time-traffic flow - time-reset
+
+   J.  Stop the offered load and 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 is deployed in operational networks.
+
+   L.  When varying number of routes are 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 the route convergence time taken by an
+      implementation to service a BGP Route Refresh message and
+      advertise a route.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 2.
+
+
+
+Papneja, et al.               Informational                    [Page 22]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   Procedure:
+
+   A.  The BGP implementation on the DUT and Helper Node needs to
+       support BGP Route Refresh Capability [RFC2918].
+
+   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-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 BGP adjacency between the DUT and the emulator.
+
+   F.  Establish BGP adjacency between the DUT and the Helper Node.
+
+   G.  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.
+
+   H.  Configure a policy under the 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; it
+       will be denied.
+
+   K.  Wait for three keepalives.
+
+   L.  Start the traffic from the emulator towards the Helper Node
+       targeted at a specific route, say routeA.  Initially, no traffic
+       would be observed on the egress interface, as routeA is not
+       present.
+
+   M.  Remove the policy on the Helper Node and issue a route refresh
+       request towards the DUT.  Note the timestamp of this event.  This
+       is the RefreshTime.
+
+   N.  Record the time when the traffic targeted towards routeA is
+       received on the egress interface.  This is RecTime.
+
+   O.  The following equation represents the Route Refresh Convergence
+       Time per route.
+
+          Route Refresh Convergence Time = (RecTime - RefreshTime)
+
+
+
+Papneja, et al.               Informational                    [Page 23]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+5.6.  BGP Route Withdrawal Convergence Time
+
+   Objective:
+
+      This test measures the route convergence time taken by an
+      implementation to service a BGP withdraw message and advertise the
+      withdraw.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in Figure 2.
+
+   Procedure:
+
+   A.  This test consists of two steps to determine the Total Withdraw
+       Processing Time.
+
+   B.  Step 1:
+
+       (1)   All devices MUST be synchronized using NTP or some local
+             reference clock.
+
+       (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 BGP adjacency between the DUT and the emulator.
+
+       (5)   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.
+
+       (6)   Start the traffic from the emulator towards the DUT
+             targeted at a specific route (e.g., routeA).  Initially, no
+             traffic would be observed on the egress interface as routeA
+             is not present on the DUT.
+
+       (7)   Advertise routeA from the emulator to the DUT.
+
+       (8)   The traffic targeted towards 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).
+
+
+
+Papneja, et al.               Informational                    [Page 24]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+       (11)  The difference between the 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 back to the DUT
+            from the Tester.
+
+       (2)  The DUT will try to advertise routeA to the Helper Node
+            (this assumes there exists a session between the DUT and
+            Helper Node).
+
+       (3)  Start the traffic from the emulator towards the Helper Node
+            targeted at a specific route (e.g., routeA).  Traffic would
+            be observed on the egress interface after routeA is received
+            by the Helper Node.
+
+               WATime=time traffic first flows
+
+       (4)  Now the Tester sends a request to withdraw routeA to DUT.
+            This is the WdrawTime2(Rt-A).
+
+               WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A)
+
+       (5)  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)  Total Withdraw Processing Time is:
+
+               TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) -
+               WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A))
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 25]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+5.7.  BGP Path Attribute Change Convergence Time
+
+   Objective:
+
+      This test measures the convergence time taken by an implementation
+      to service a BGP Path Attribute Change.
+
+   Reference Test Setup:
+
+      This test uses the setup as shown in 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 need to be varied whereas the others remain 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 so that the Best Egress Interface for the preferred
+       next hop is (Emp1) interface.
+
+   F.  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.
+
+   G.  Start the traffic from the emulator towards the DUT targeted at
+       the specific route (e.g., routeA).  Initially, traffic would be
+       observed on the Best Egress Interface.
+
+   H.  Now advertise the same route, routeA, on the Next-Best Egress
+       Interface but by varying one of the well-known mandatory
+       attributes to have a preferred value over that interface.  We
+       call this Tbetter.  The other values need to be the same as what
+       was advertised on the Best-Egress adjacency.
+
+          TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A)
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 26]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   I.  Measure the convergence time for the event to be detected and
+       traffic to be forwarded to 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 and wait for the queues to drain and
+       restart.
+
+   K.  Repeat the test for various attributes.
+
+5.8.  BGP Graceful Restart Convergence Time
+
+   Objective:
+
+      This test measures 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.
+
+   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.
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 27]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   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.
+
+   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.
+
+   O.  Perform a Graceful Restart Trigger Event on the DUT and note the
+       time.  This is the GREventTime.
+
+   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)
+
+   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.
+
+
+
+
+Papneja, et al.               Informational                    [Page 28]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+6.  Reporting Format
+
+   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].
+
+ 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
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 29]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 30]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   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
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 31]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+          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
+
+   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.
+
+   Further, benchmarking is performed on a "black-box" basis, relying
+   solely on measurements observable and external to the DUT/SUT.
+
+   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.
+
+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>.
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 32]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   [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
+
+   [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>.
+
+
+
+
+Papneja, et al.               Informational                    [Page 33]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+   [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
+
+   We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay
+   Karthik, and Eric Brendel for their input and discussions on various
+   sections in the document.  We also like to acknowledge Will Liu,
+   Hubert Gee, Semion Lisyansky, and Faisal Shah for their review and
+   feedback on the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 34]
+
+RFC 7747               BGP Convergence Methodology            April 2016
+
+
+Authors' Addresses
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Papneja, et al.               Informational                    [Page 35]
+