From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7747.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc7747.txt (limited to 'doc/rfc/rfc7747.txt') 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, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + + +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, + . + + [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, + . + + [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, + . + + [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, . + +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, . + + [RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, + RFC 1983, DOI 10.17487/RFC1983, August 1996, + . + + [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN + Switching Devices", RFC 2285, DOI 10.17487/RFC2285, + February 1998, . + + [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, + . + + [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, + . + + + + +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, + . + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, . + + [RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, + "Benchmarking Terminology for Protection Performance", + RFC 6414, DOI 10.17487/RFC6414, November 2011, + . + + [RFC7115] Bush, R., "Origin Validation Operation Based on the + Resource Public Key Infrastructure (RPKI)", BCP 185, + RFC 7115, DOI 10.17487/RFC7115, January 2014, + . + +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] + -- cgit v1.2.3