idnits 2.17.1 draft-ietf-bmwg-bgp-basic-convergence-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MPLSProt' is mentioned on line 441, but not defined == Missing Reference: 'IGPData' is mentioned on line 949, but not defined == Missing Reference: 'BGPSec' is mentioned on line 1286, but not defined == Unused Reference: 'I-D.ietf-sidr-bgpsec-protocol' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'RFC6412' is defined on line 1434, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-09 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group R. Papneja 3 Internet-Draft Huawei Technologies 4 Intended status: Informational B. Parise 5 Expires: April 29, 2015 Cisco Systems 6 S. Hares 7 Huawei Technologies 8 D. Lee 9 IXIA 10 I. Varlashkin 11 Google 12 October 26, 2014 14 Basic BGP Convergence Benchmarking Methodology for Data Plane 15 Convergence 16 draft-ietf-bmwg-bgp-basic-convergence-04.txt 18 Abstract 20 BGP is widely deployed and used by several service providers as the 21 default Inter AS routing protocol. It is of utmost importance to 22 ensure that when a BGP peer or a downstream link of a BGP peer fails, 23 the alternate paths are rapidly used and routes via these alternate 24 paths are installed. This document provides the basic BGP 25 Benchmarking Methodology using existing BGP Convergence Terminology, 26 RFC 4098. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 29, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Benchmarking Definitions . . . . . . . . . . . . . . . . . 4 76 1.2. Purpose of BGP FIB (Data Plane) Convergence . . . . . . . 4 77 1.3. Control Plane Convergence . . . . . . . . . . . . . . . . 5 78 1.4. Benchmarking Testing . . . . . . . . . . . . . . . . . . . 5 79 2. Existing Definitions and Requirements . . . . . . . . . . . . 5 80 3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. General Reference Topologies . . . . . . . . . . . . . . . 6 82 4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. Number of Peers . . . . . . . . . . . . . . . . . . . . . 9 84 4.2. Number of Routes per Peer . . . . . . . . . . . . . . . . 9 85 4.3. Policy Processing/Reconfiguration . . . . . . . . . . . . 9 86 4.4. Configured Parameters (Timers, etc..) . . . . . . . . . . 9 87 4.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 11 88 4.6. Measurement Accuracy . . . . . . . . . . . . . . . . . . . 11 89 4.7. Measurement Statistics . . . . . . . . . . . . . . . . . . 11 90 4.8. Authentication . . . . . . . . . . . . . . . . . . . . . . 12 91 4.9. Convergence Events . . . . . . . . . . . . . . . . . . . . 12 92 4.10. High Availability . . . . . . . . . . . . . . . . . . . . 12 93 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 5.1. Basic Convergence Tests . . . . . . . . . . . . . . . . . 13 95 5.1.1. RIB-IN Convergence . . . . . . . . . . . . . . . . . . 13 96 5.1.2. RIB-OUT Convergence . . . . . . . . . . . . . . . . . 15 97 5.1.3. eBGP Convergence . . . . . . . . . . . . . . . . . . . 16 98 5.1.4. iBGP Convergence . . . . . . . . . . . . . . . . . . . 17 99 5.1.5. eBGP Multihop Convergence . . . . . . . . . . . . . . 17 100 5.2. BGP Failure/Convergence Events . . . . . . . . . . . . . . 18 101 5.2.1. Physical Link Failure on DUT End . . . . . . . . . . . 18 102 5.2.2. Physical Link Failure on Remote/Emulator End . . . . . 20 103 5.2.3. ECMP Link Failure on DUT End . . . . . . . . . . . . . 20 104 5.3. BGP Adjacency Failure (Non-Physical Link Failure) on 105 Emulator . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 5.4. BGP Hard Reset Test Cases . . . . . . . . . . . . . . . . 21 107 5.4.1. BGP Non-Recovering Hard Reset Event on DUT . . . . . . 21 108 5.5. BGP Soft Reset . . . . . . . . . . . . . . . . . . . . . . 23 109 5.6. BGP Route Withdrawal Convergence Time . . . . . . . . . . 24 110 5.7. BGP Path Attribute Change Convergence Time . . . . . . . . 26 111 5.8. BGP Graceful Restart Convergence Time . . . . . . . . . . 27 112 6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 29 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 121 1. Introduction 123 This document defines the methodology for benchmarking data plane FIB 124 convergence performance of BGP in routers and switches using 125 topologies of 3 or 4 nodes. The methodology proposed in this 126 document applies to both IPv4 and IPv6 and if a particular test is 127 unique to one version, it is marked accordingly. For IPv6 128 benchmarking the device under test will require the support of Multi- 129 Protocol BGP (MP-BGP) [RFC4760, RFC2545]. Similarly both iBGP & eBGP 130 are covered in the tests as applicable. 132 The scope of this document is to provide methodology for BGP protocol 133 FIB convergence measurements with BGP functionality limited to IPv4 & 134 IPv6 as defined in RFC 4271 and Multi-Protocol BGP (MP-BGP) [RFC4760, 135 RFC2545]. Other BGP extensions to support layer-2, layer-3 virtual 136 private networks (VPN) are outside the scope of this document. 137 Interaction with IGPs (IGP interworking) is outside the scope of this 138 document. 140 1.1. Benchmarking Definitions 142 The terminology used in this document is defined in [RFC4098]. One 143 additional term is defined in this draft: FIB (Data plane) BGP 144 Convergence. 146 FIB (Data plane) convergence is defined as the completion of all FIB 147 changes so that all forwarded traffic now takes the new proposed 148 route. RFC 4098 defines the terms BGP device, FIB and the forwarded 149 traffic. Data plane convergence is different than control plane 150 convergence within a node. 152 This document defines methodology to test 154 - Data plane convergence on a single BGP device that supports the BGP 155 functionality with scope as outlined above 157 - using test topology of 3 or 4 nodes which are sufficient to 158 recreate the Convergence events used in the various tests of this 159 draft 161 1.2. Purpose of BGP FIB (Data Plane) Convergence 163 In the current Internet architecture the Inter-Autonomous System 164 (inter-AS) transit is primarily available through BGP. To maintain 165 reliable connectivity within intra-domains or across inter-domains, 166 fast recovery from failures remains most critical. To ensure minimal 167 traffic losses, many service providers are requiring BGP 168 implementations to converge the entire Internet routing table within 169 sub-seconds at FIB level. 171 Furthermore, to compare these numbers amongst various devices, 172 service providers are also looking at ways to standardize the 173 convergence measurement methods. This document offers test methods 174 for simple topologies. These simple tests will provide a quick high- 175 level check of the BGP data plane convergence across multiple 176 implementations from different vendors. 178 1.3. Control Plane Convergence 180 The convergence of BGP occurs at two levels: RIB and FIB convergence. 181 RFC 4098 defines terms for BGP control plane convergence. 182 Methodologies which test control plane convergence are out of scope 183 for this draft. 185 1.4. Benchmarking Testing 187 In order to ensure that the results obtained in tests are repeatable, 188 careful setup of initial conditions and exact steps are required. 190 This document proposes these initial conditions, test steps, and 191 result checking. To ensure uniformity of the results all optional 192 parameters SHOULD be disabled and all settings SHOULD be changed to 193 default, these may include BGP timers as well. 195 2. Existing Definitions and Requirements 197 RFC 1242, "Benchmarking Terminology for Network Interconnect Devices" 198 [RFC1242] and RFC 2285, "Benchmarking Terminology for LAN Switching 199 Devices" [RFC2285] SHOULD be reviewed in conjunction with this 200 document. WLAN-specific terms and definitions are also provided in 201 Clauses 3 and 4 of the IEEE 802.11 standard [802.11]. Commonly used 202 terms may also be found in RFC 1983 [RFC1983]. 204 For the sake of clarity and continuity, this document adopts the 205 general template for benchmarking terminology set out in Section 2 of 206 RFC 1242. Definitions are organized in alphabetical order, and 207 grouped into sections for ease of reference. The following terms are 208 assumed to be taken as defined in RFC 1242 [RFC1242]: Throughput, 209 Latency, Constant Load, Frame Loss Rate, and Overhead Behavior. In 210 addition, the following terms are taken as defined in [RFC2285]: 211 Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test 212 (DUT), and System Under Test (SUT). 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in RFC 2119 [RFC2119]. 218 3. Test Topologies 220 This section describes the test setups for use in BGP benchmarking 221 tests measuring convergence of the FIB (data plane) after the BGP 222 updates has been received. 224 These test setups have 3 or 4 nodes with the following configuration: 226 1. Basic Test Setup 228 2. Three node setup for iBGP or eBGP convergence 230 3. Setup for eBGP multihop test scenario 232 4. Four node setup for iBGP or eBGP convergence 234 Individual tests refer to these topologies. 236 Figures 1-4 use the following conventions 238 o AS-X: Autonomous System X 240 o Loopback Int: Loopback interface on the BGP enabled device 242 o HLP,HLP1,HLP2: Helper routers running the same version of BGP as 243 DUT 245 o Enable NTP or use any external clock source to synchronize to the 246 nodes 248 3.1. General Reference Topologies 250 Emulator acts as 1 or more BGP peers for different testcases. 252 +----------+ +------------+ 253 | | traffic interfaces | | 254 | |-----------------------1---- | tx | 255 | |-----------------------2---- | tr1 | 256 | |-----------------------3-----| tr2 | 257 | DUT | | Emulator | 258 | | routing interfaces | | 259 | Dp1 |--------------------------- |Emp1 | 260 | | BGP Peering | | 261 | Dp2 |---------------------------- |Emp2 | 262 | | BGP Peering | | 263 +----------+ +------------+ 265 Figure 1 Basic Test Setup 267 +------------+ +-----------+ +-----------+ 268 | | | | | | 269 | | | | | | 270 | HLP | | DUT | | Emulator | 271 | (AS-X) |--------| (AS-Y) |-----------| (AS-Z) | 272 | | | | | | 273 | | | | | | 274 | | | | | | 275 +------------+ +-----------+ +-----------+ 276 | | 277 | | 278 +--------------------------------------------+ 280 Figure 2 Three Node Setup for eBGP and iBGP Convergence 281 +----------------------------------------------+ 282 | | 283 | | 284 +------------+ +-----------+ +-----------+ 285 | | | | | | 286 | | | | | | 287 | HLP | | DUT | | Emulator | 288 | (AS-X) |--------| (AS-Y) |-----------| (AS-Z) | 289 | | | | | | 290 | | | | | | 291 | | | | | | 292 +------------+ +-----------+ +-----------+ 293 |Loopback-Int |Loopback-Int 294 | | 295 + + 297 Figure 3 BGP Convergence for eBGP Multihop Scenario 299 +---------+ +--------+ +--------+ +---------+ 300 | | | | | | | | 301 | | | | | | | | 302 | HLP1 | | DUT | | HLP2 | |Emulator | 303 | (AS-X) |-----| (AS-X) |-----| (AS-Y) |-----| (AS-Z) | 304 | | | | | | | | 305 | | | | | | | | 306 | | | | | | | | 307 +---------+ +--------+ +--------+ +---------+ 308 | | 309 | | 310 +---------------------------------------------+ 312 Figure 4 Four Node Setup for EBGP and IBGP Convergence 314 4. Test Considerations 316 The test cases for measuring convergence for iBGP and eBGP are 317 different. Both iBGP and eBGP use different mechanisms to advertise, 318 install and learn the routes. Typically, an iBGP route on the DUT is 319 installed and exported when the next-hop is valid. For eBGP the 320 route is installed on the DUT with the remote interface address as 321 the next-hop, with the exception of the multihop test case (as 322 specified in the test). 324 4.1. Number of Peers 326 Number of Peers is defined as the number of BGP neighbors or sessions 327 the DUT has at the beginning of the test. The peers are established 328 before the tests begin. The relationship could be either, iBGP or 329 eBGP peering depending upon the test case requirement. 331 The DUT establishes one or more BGP sessions with one more emulated 332 routers or helper nodes. Additional peers can be added based on the 333 testing requirements. The number of peers enabled during the testing 334 should be well documented in the report matrix. 336 4.2. Number of Routes per Peer 338 Number of Routes per Peer is defined as the number of routes 339 advertised or learnt by the DUT per session or through a neighbor 340 relationship with an emulator or helper node. The tester, emulating 341 as neighbor MUST advertise at least one route per peer. 343 Each test run must identify the route stream in terms of route 344 packing, route mixture, and number of routes. This route stream must 345 be well documented in the reporting stream. RFC 4098 defines these 346 terms. 348 It is RECOMMENDED that the user consider advertising the entire 349 current Internet routing table per peering session using an Internet 350 route mixture with unique or non-unique routes. If multiple peers 351 are used, it is important to precisely document the timing sequence 352 between the peer sending routes (as defined in RFC 4098). 354 4.3. Policy Processing/Reconfiguration 356 The DUT MUST run one baseline test where policy is Minimal policy as 357 defined in RFC 4098. Additional runs may be done with policy set-up 358 before the tests begin. Exact policy settings MUST be documented as 359 part of the test. 361 4.4. Configured Parameters (Timers, etc..) 363 There are configured parameters and timers that may impact the 364 measured BGP convergence times. 366 The benchmark metrics MAY be measured at any fixed values for these 367 configured parameters. 369 It is RECOMMENDED these configure parameters have the following 370 settings: a) default values specified by the respective RFC b) 371 platform-specific default parameters and c) values as expected in the 372 operational network. All optional BGP settings MUST be kept 373 consistent across iterations of any specific tests 375 Examples of the configured parameters that may impact measured BGP 376 convergence time include, but are not limited to: 378 1. Interface failure detection timer 380 2. BGP Keepalive timer 382 3. BGP Holdtime 384 4. BGP update delay timer 386 5. ConnectRetry timer 388 6. TCP Segment Size 390 7. Minimum Route Advertisement Interval (MRAI) 392 8. MinASOriginationInterval (MAOI) 394 9. Route Flap Dampening parameters 396 10. TCP MD5 398 11. Maximum TCP Window Size 400 12. MTU 402 The basic-test settings for the parameters should be: 404 1. Interface failure detection timer (0 ms) 406 2. BGP Keepalive timer (1 min) 408 3. BGP Holdtime (3 min) 410 4. BGP update delay timer (0 s) 411 5. ConnectRetry timer (1 s) 413 6. TCP Segment Size (4096) 415 7. Minimum Route Advertisement Interval (MRAI) (0 s) 417 8. MinASOriginationInterval (MAOI)(0 s) 419 9. Route Flap Dampening parameters (off) 421 10. TCP MD5 (off) 423 4.5. Interface Types 425 The type of media dictate which test cases may be executed, each 426 interface type has unique mechanism for detecting link failures and 427 the speed at which that mechanism operates will influence the 428 measurement results. All interfaces MUST be of the same media and 429 throughput for all iterations of each test case. 431 4.6. Measurement Accuracy 433 Since observed packet loss is used to measure the route convergence 434 time, the time between two successive packets offered to each 435 individual route is the highest possible accuracy of any packet-loss 436 based measurement. When packet jitter is much less than the 437 convergence time, it is a negligible source of error and hence it 438 will be treated as within tolerance. 440 Other options to measure convergence are the Time-Based Loss Method 441 (TBLM) and Timestamp Based Method(TBM)[MPLSProt]. 443 An exterior measurement on the input media (such as Ethernet) is 444 defined by this specification. 446 4.7. Measurement Statistics 448 The benchmark measurements may vary for each trial, due to the 449 statistical nature of timer expirations, CPU scheduling, etc. It is 450 recommended to repeat the test multiple times. Evaluation of the 451 test data must be done with an understanding of generally accepted 452 testing practices regarding repeatability, variance and statistical 453 significance of a small number of trials. 455 For any repeated tests that are averaged to remove variance, all 456 parameters MUST remain the same. 458 4.8. Authentication 460 Authentication in BGP is done using the TCP MD5 Signature Option 461 [RFC5925]. The processing of the MD5 hash, particularly in devices 462 with a large number of BGP peers and a large amount of update 463 traffic, can have an impact on the control plane of the device. If 464 authentication is enabled, it MUST be documented correctly in the 465 reporting format. 467 Also it is recommended that trials MUST be with the same SIDR 468 features (RFC7115 & BGPSec). The best convergence tests would be 469 with No SIDR features, and then with the same SIDR features. 471 4.9. Convergence Events 473 Convergence events or triggers are defined as abnormal occurrences in 474 the network, which initiate route flapping in the network, and hence 475 forces the re-convergence of a steady state network. In a real 476 network, a series of convergence events may cause convergence latency 477 operators desire to test. 479 These convergence events must be defined in terms of the sequences 480 defined in RFC 4098. This basic document begins all tests with a 481 router initial set-up. Additional documents will define BGP data 482 plane convergence based on peer initialization. 484 The convergence events may or may not be tied to the actual failure A 485 Soft Reset (RFC 4098) does not clear the RIB or FIB tables. A Hard 486 reset clears the BGP peer sessions, the RIB tables, and FIB tables. 488 4.10. High Availability 490 Due to the different Non-Stop-Routing (sometimes referred to High- 491 Availability) solutions available from different vendors, it is 492 RECOMMENDED that any redundancy available in the routing processors 493 should be disabled during the convergence measurements. For cases 494 where the redundancy cannot be disabled, the results are no longer 495 comparable and the level of impacts on the measurements is out of 496 scope of this document. 498 5. Test Cases 500 All tests defined under this section assume the following: 502 a. BGP peers are in established state 503 b. BGP state should be cleared from established state to idle prior 504 to each test. This is recommended to ensure that all tests start 505 with the BGP peers being forced back to idle state and databases 506 flushed. 508 c. Furthermore the traffic generation and routing should be verified 509 in the topology to ensure there is no packet loss observed on any 510 advertised routes 512 d. The arrival timestamp of advertised routes can be measured by 513 installing an inline monitoring device between the emulator and 514 DUT, or by the span port of DUT connected with an external 515 analyzer. The time base of such inline monitor or external 516 analyzer needs to be synchronized with the protocol and traffic 517 emulator. Some modern emulator may have the capability to 518 capture and timestamp every NLRI packets leaving and arriving at 519 the emulator ports. The timestamps of these NLRI packets will be 520 almost identical to the arrival time at DUT if the cable distance 521 between the emulator and DUT is relatively short. 523 5.1. Basic Convergence Tests 525 These test cases measure characteristics of a BGP implementation in 526 non-failure scenarios like: 528 1. RIB-IN Convergence 530 2. RIB-OUT Convergence 532 3. eBGP Convergence 534 4. iBGP Convergence 536 5.1.1. RIB-IN Convergence 538 Objective: 540 This test measures the convergence time taken to receive and 541 install a route in RIB using BGP. 543 Reference Test Setup: 545 This test uses the setup as shown in figure 1 547 Procedure: 549 A. All variables affecting Convergence should be set to a basic 550 test state (as defined in section 4-4). 552 B. Establish BGP adjacency between DUT and one peer of Emulator, 553 Emp1. 555 C. To ensure adjacency establishment, wait for 3 KeepAlives from 556 the DUT or a configurable delay before proceeding with the 557 rest of the test. 559 D. Start the traffic from the Emulator tx towards the DUT 560 targeted at a routes specified in route mixture (ex. routeA) 561 Initially no traffic SHOULD be observed on the egress 562 interface as the routeA is not installed in the forwarding 563 database of the DUT. 565 E. Advertise routeA from the peer(Emp1) to the DUT and record the 566 time. 568 This is Tup(EMp1,Rt-A) also named 'XMT-Rt-time(Rt-A)'. 570 F. Record the time when the routeA from Emp1 is received at the 571 DUT. 573 This Tup(DUT,Rt-A) also named 'RCV-Rt-time(Rt-A)'. 575 G. Record the time when the traffic targeted towards routeA is 576 received by Emulator on appropriate traffic egress interface. 578 This is TR(TDr,Rt-A). This is also named DUT-XMT-Data- 579 Time(Rt-A). 581 H. The difference between the Tup(DUT,RT-A) and traffic received 582 time (TR (TDr, Rt-A) is the FIB Convergence Time for routeA in 583 the route mixture. A full convergence for the route update is 584 the measurement between the 1st route (Rt-A) and the last 585 route (Rt-last) 587 Route update convergence is 589 TR(TDr, Rt-last)- Tup(DUT, Rt-A) or 590 (DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A) 592 Note: It is recommended that a single test with the same route 593 mixture be repeated several times. A report should provide the 594 Standard Deviation of all tests and the Average. 596 Running tests with a varying number of routes and route mixtures is 597 important to get a full characterization of a single peer. 599 5.1.2. RIB-OUT Convergence 601 Objective: 603 This test measures the convergence time taken by an implementation 604 to receive, install and advertise a route using BGP. 606 Reference Test Setup: 608 This test uses the setup as shown in figure 2. 610 Procedure: 612 A. The Helper node (HLP) MUST run same version of BGP as DUT. 614 B. All devices MUST be synchronized using NTP or some local 615 reference clock. 617 C. All configuration variables for HLP, DUT and Emulator SHOULD 618 be set to the same values. These values MAY be basic-test or 619 a unique set completely described in the test set-up. 621 D. Establish BGP adjacency between DUT and Emulator. 623 E. Establish BGP adjacency between DUT and Helper Node. 625 F. To ensure adjacency establishment, wait for 3 KeepAlives from 626 the DUT or a configurable delay before proceeding with the 627 rest of the test. 629 G. Start the traffic from the Emulator towards the Helper Node 630 targeted at a specific route (e.g. routeA). Initially no 631 traffic SHOULD be observed on the egress interface as the 632 routeA is not installed in the forwarding database of the DUT. 634 H. Advertise routeA from the Emulator to the DUT and note the 635 time. 637 This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A) 639 I. Record when routeA is received by DUT. 641 This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A) 643 J. Record the time when the routeA is forwarded by DUT towards 644 the Helper node. 646 This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A) 648 K. Record the time when the traffic targeted towards routeA is 649 received on the Route Egress Interface. This is TR(EMr, 650 Rt-A), also named DUT-XMT-Data Time(Rt-A). 652 FIB convergence = (DUT-RCV-Rt-Time - 653 DUT-XMT-Data-Time)(Rt-A) 655 RIB convergence = (DUT-RCV-Rt-Time - DUT-XMT-Rt-Time)(Rt-A) 657 Convergence for a route stream is characterized by 659 a) Individual route convergence for FIB, RIB 661 b) All route convergence of 663 FIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Data- 664 Time(last) 666 RIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Rt- 667 Time(last) 669 5.1.3. eBGP Convergence 671 Objective: 673 This test measures the convergence time taken by an implementation 674 to receive, install and advertise a route in an eBGP Scenario. 676 Reference Test Setup: 678 This test uses the setup as shown in figure 2 and the scenarios 679 described in RIB-IN and RIB-OUT are applicable to this test case. 681 5.1.4. iBGP Convergence 683 Objective: 685 This test measures the convergence time taken by an implementation 686 to receive, install and advertise a route in an iBGP Scenario. 688 Reference Test Setup: 690 This test uses the setup as shown in figure 2 and the scenarios 691 described in RIB-IN and RIB-OUT are applicable to this test case. 693 5.1.5. eBGP Multihop Convergence 695 Objective: 697 This test measures the convergence time taken by an implementation 698 to receive, install and advertise a route in an eBGP Multihop 699 Scenario. 701 Reference Test Setup: 703 This test uses the setup as shown in figure 3. DUT is used along 704 with a helper node. 706 Procedure: 708 A. The Helper Node (HLP) MUST run the same version of BGP as DUT. 710 B. All devices MUST be synchronized using NTP or some local 711 reference clock. 713 C. All variables affecting Convergence like authentication, 714 policies, timers SHOULD be set to basic-settings 716 D. All 3 devices, DUT, Emulator and Helper Node are configured 717 with different Autonomous Systems. 719 E. Loopback Interfaces are configured on DUT and Helper Node and 720 connectivity is established between them using any config 721 options available on the DUT. 723 F. Establish BGP adjacency between DUT and Emulator. 725 G. Establish BGP adjacency between DUT and Helper Node. 727 H. To ensure adjacency establishment, wait for 3 KeepAlives from 728 the DUT or a configurable delay before proceeding with the 729 rest of the test 731 I. Start the traffic from the Emulator towards the DUT targeted 732 at a specific route (e.g. routeA). 734 J. Initially no traffic SHOULD be observed on the egress 735 interface as the routeA is not installed in the forwarding 736 database of the DUT. 738 K. Advertise routeA from the Emulator to the DUT and note the 739 time (Tup(EMx,RouteA) also named Route-Tx-time(Rt-A). 741 L. Record the time when the route is received by the DUT. This 742 is Tup(EMr,DUT) named Route-Rcv-time(Rt-A). 744 M. Record the time when the traffic targeted towards routeA is 745 received from Egress Interface of DUT on emulator. This is 746 Tup(EMd,DUT) named Data-Rcv-time(Rt-A) 748 N. Record the time when the routeA is forwarded by DUT towards 749 the Helper node. This is Tup(EMf,DUT) also named Route-Fwd- 750 time(Rt-A) 752 FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A) 754 RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A) 756 Note: It is recommended that the test be repeated with varying number 757 of routes and route mixtures. With each set route mixture, the test 758 should be repeated multiple times. The results should record 759 average, mean, Standard Deviation 761 5.2. BGP Failure/Convergence Events 763 5.2.1. Physical Link Failure on DUT End 765 Objective: 767 This test measures the route convergence time due to local link 768 failure event at DUT's Local Interface. 770 Reference Test Setup: 772 This test uses the setup as shown in figure 1. Shutdown event is 773 defined as an administrative shutdown event on the DUT. 775 Procedure: 777 A. All variables affecting Convergence like authentication, 778 policies, timers should be set to basic-test policy. 780 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 781 peer interface and the other using a second peer interface. 783 C. Advertise the same route, routeA over both the adjacencies and 784 (Emp1) Interface to be the preferred next hop. 786 D. To ensure adjacency establishment, wait for 3 KeepAlives from 787 the DUT or a configurable delay before proceeding with the 788 rest of the test. 790 E. Start the traffic from the Emulator towards the DUT targeted 791 at a specific route (e.g. routeA). Initially traffic would be 792 observed on the best egress route (Emp1) instead of Emp2. 794 F. Trigger the shutdown event of Best Egress Interface on DUT 795 (Dp1). 797 G. Measure the Convergence Time for the event to be detected and 798 traffic to be forwarded to Next-Best Egress Interface (Dp2) 800 Time = Data-detect(Emp2) - Shutdown time 802 H. Stop the offered load and wait for the queues to drain and 803 Restart. 805 I. Bring up the link on DUT Best Egress Interface. 807 J. Measure the convergence time taken for the traffic to be 808 rerouted from (Dp2) to Best Interface (Dp1) 810 Time = Data-detect(Emp1) - Bring Up time 812 K. It is recommended that the test be repeated with varying 813 number of routes and route mixtures or with number of routes & 814 route mixtures closer to what is deployed in operational 815 networks. 817 5.2.2. Physical Link Failure on Remote/Emulator End 819 Objective: 821 This test measures the route convergence time due to local link 822 failure event at Tester's Local Interface. 824 Reference Test Setup: 826 This test uses the setup as shown in figure 1. Shutdown event is 827 defined as shutdown of the local interface of Tester via logical 828 shutdown event. The procedure used in 5.2.1 is used for the 829 termination. 831 5.2.3. ECMP Link Failure on DUT End 833 Objective: 835 This test measures the route convergence time due to local link 836 failure event at ECMP Member. The FIB configuration and BGP is 837 set to allow two ECMP routes to be installed. However, policy 838 directs the routes to be sent only over one of the paths 840 Reference Test Setup: 842 This test uses the setup as shown in figure 1 and the procedure 843 uses 5.2.1. 845 5.3. BGP Adjacency Failure (Non-Physical Link Failure) on Emulator 847 Objective: 849 This test measures the route convergence time due to BGP Adjacency 850 Failure on Emulator. 852 Reference Test Setup: 854 This test uses the setup as shown in figure 1. 856 Procedure: 858 A. All variables affecting Convergence like authentication, 859 policies, timers should be basic-policy set. 861 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 862 Best Egress Interface and the other using the Next-Best Egress 863 Interface. 865 C. Advertise the same route, routeA over both the adjacencies and 866 make Best Egress Interface to be the preferred next hop 868 D. To ensure adjacency establishment, wait for 3 KeepAlives from 869 the DUT or a configurable delay before proceeding with the 870 rest of the test. 872 E. Start the traffic from the Emulator towards the DUT targeted 873 at a specific route (e.g. routeA). Initially traffic would be 874 observed on the Best Egress interface. 876 F. Remove BGP adjacency via a software adjacency down on the 877 Emulator on the Best Egress Interface. This time is called 878 BGPadj-down-time also termed BGPpeer-down 880 G. Measure the Convergence Time for the event to be detected and 881 traffic to be forwarded to Next-Best Egress Interface. This 882 time is Tr-rr2 also called TR2-traffic-on 884 Convergence = TR2-traffic-on - BGPpeer-down 886 H. Stop the offered load and wait for the queues to drain and 887 Restart. 889 I. Bring up BGP adjacency on the Emulator over the Best Egress 890 Interface. This time is BGP-adj-up also called BGPpeer-up 892 J. Measure the convergence time taken for the traffic to be 893 rerouted to Best Interface. This time is BGP-adj-up also 894 called BGPpeer-up 896 5.4. BGP Hard Reset Test Cases 898 5.4.1. BGP Non-Recovering Hard Reset Event on DUT 900 Objective: 902 This test measures the route convergence time due to Hard Reset on 903 the DUT. 905 Reference Test Setup: 907 This test uses the setup as shown in figure 1. 909 Procedure: 911 A. The requirement for this test case is that the Hard Reset 912 Event should be non-recovering and should affect only the 913 adjacency between DUT and Emulator on the Best Egress 914 Interface. 916 B. All variables affecting SHOULD be set to basic-test values. 918 C. Establish 2 BGP adjacencies from DUT to Emulator, one over the 919 Best Egress Interface and the other using the Next-Best Egress 920 Interface. 922 D. Advertise the same route, routeA over both the adjacencies and 923 make Best Egress Interface to be the preferred next hop. 925 E. To ensure adjacency establishment, wait for 3 KeepAlives from 926 the DUT or a configurable delay before proceeding with the 927 rest of the test. 929 F. Start the traffic from the Emulator towards the DUT targeted 930 at a specific route (e.g routeA). Initially traffic would be 931 observed on the Best Egress interface. 933 G. Trigger the Hard Reset event of Best Egress Interface on DUT. 935 H. Measure the Convergence Time for the event to be detected and 936 traffic to be forwarded to Next-Best Egress Interface. 938 Time of convergence = time-traffic flow - time-reset 940 I. Stop the offered load and wait for the queues to drain and 941 Restart. 943 J. It is recommended that the test be repeated with varying 944 number of routes and route mixtures or with number of routes & 945 route mixtures closer to what is deployed in operational 946 networks. 948 K. When varying number of routes are used, convergence Time is 949 measured using the Loss Derived method [IGPData]. 951 L. Convergence Time in this scenario is influenced by Failure 952 detection time on Tester, BGP Keep Alive Time and routing, 953 forwarding table update time. 955 5.5. BGP Soft Reset 957 Objective: 959 This test measures the route convergence time taken by an 960 implementation to service a BGP Route Refresh message and 961 advertise a route. 963 Reference Test Setup: 965 This test uses the setup as shown in figure 2. 967 Procedure: 969 A. The BGP implementation on DUT & Helper Node needs to support 970 BGP Route Refresh Capability [RFC2918]. 972 B. All devices MUST be synchronized using NTP or some local 973 reference clock. 975 C. All variables affecting Convergence like authentication, 976 policies, timers should be set to basic-test defaults. 978 D. DUT and Helper Node are configured in the same Autonomous 979 System whereas Emulator is configured under a different 980 Autonomous System. 982 E. Establish BGP adjacency between DUT and Emulator. 984 F. Establish BGP adjacency between DUT and Helper Node. 986 G. To ensure adjacency establishment, wait for 3 KeepAlives from 987 the DUT or a configurable delay before proceeding with the 988 rest of the test. 990 H. Configure a policy under BGP on Helper Node to deny routes 991 received from DUT. 993 I. Advertise routeA from the Emulator to the DUT. 995 J. The DUT will try to advertise the route to Helper Node will be 996 denied. 998 K. Wait for 3 KeepAlives. 1000 L. Start the traffic from the Emulator towards the Helper Node 1001 targeted at a specific route say routeA. Initially no traffic 1002 would be observed on the Egress interface, as routeA is not 1003 present. 1005 M. Remove the policy on Helper Node and issue a Route Refresh 1006 request towards DUT. Note the timestamp of this event. This 1007 is the RefreshTime. 1009 N. Record the time when the traffic targeted towards routeA is 1010 received on the Egress Interface. This is RecTime. 1012 O. The following equation represents the Route Refresh 1013 Convergence Time per route. 1015 Route Refresh Convergence Time = (RecTime - RefreshTime) 1017 5.6. BGP Route Withdrawal Convergence Time 1019 Objective: 1021 This test measures the route convergence time taken by an 1022 implementation to service a BGP Withdraw message and advertise the 1023 withdraw. 1025 Reference Test Setup: 1027 This test uses the setup as shown in figure 2. 1029 Procedure: 1031 A. This test consists of 2 steps to determine the Total Withdraw 1032 Processing Time. 1034 B. Step 1: 1036 (1) All devices MUST be synchronized using NTP or some local 1037 reference clock. 1039 (2) All variables should be set to basic-test parameters. 1041 (3) DUT and Helper Node are configured in the same 1042 Autonomous System whereas Emulator is configured under a 1043 different Autonomous System. 1045 (4) Establish BGP adjacency between DUT and Emulator. 1047 (5) To ensure adjacency establishment, wait for 3 KeepAlives 1048 from the DUT or a configurable delay before proceeding 1049 with the rest of the test. 1051 (6) Start the traffic from the Emulator towards the DUT 1052 targeted at a specific route (e.g. routeA). Initially 1053 no traffic would be observed on the Egress interface as 1054 the routeA is not present on DUT. 1056 (7) Advertise routeA from the Emulator to the DUT. 1058 (8) The traffic targeted towards routeA is received on the 1059 Egress Interface. 1061 (9) Now the Tester sends request to withdraw routeA to DUT, 1062 TRx(Awith) also called WdrawTime1(Rt-A). 1064 (10) Record the time when no traffic is observed on the 1065 Egress Interface. This is the RouteRemoveTime1(Rt-A). 1067 (11) The difference between the RouteRemoveTime1 and 1068 WdrawTime1 is the WdrawConvTime1 1070 WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - 1071 WdrawTime1(Rt-A) 1073 C. Step 2: 1075 (1) Continuing from Step 1, re-advertise routeA back to DUT 1076 from Tester. 1078 (2) The DUT will try to advertise the routeA to Helper Node 1079 (This assumes there exists a session between DUT and 1080 helper node). 1082 (3) Start the traffic from the Emulator towards the Helper 1083 Node targeted at a specific route (e.g. routeA). Traffic 1084 would be observed on the Egress interface after routeA is 1085 received by the Helper Node 1087 WATime=time traffic first flows 1089 (4) Now the Tester sends a request to withdraw routeA to DUT. 1090 This is the WdrawTime2(Rt-A) 1092 WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A) 1094 (5) DUT processes the withdraw and sends it to Helper Node. 1096 (6) Record the time when no traffic is observed on the Egress 1097 Interface of Helper Node. This is 1099 TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A) 1101 (7) Total withdraw processing time is 1103 TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) - 1104 WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A)) 1106 5.7. BGP Path Attribute Change Convergence Time 1108 Objective: 1110 This test measures the convergence time taken by an implementation 1111 to service a BGP Path Attribute Change. 1113 Reference Test Setup: 1115 This test uses the setup as shown in figure 1. 1117 Procedure: 1119 A. This test only applies to Well-Known Mandatory Attributes like 1120 Origin, AS Path, Next Hop. 1122 B. In each iteration of test only one of these mandatory 1123 attributes need to be varied whereas the others remain the 1124 same. 1126 C. All devices MUST be synchronized using NTP or some local 1127 reference clock. 1129 D. All variables should be set to basic-test parameters. 1131 E. Advertise the route, routeA over the Best Egress Interface 1132 only, making it the preferred named Tbest. 1134 F. To ensure adjacency establishment, wait for 3 KeepAlives from 1135 the DUT or a configurable delay before proceeding with the 1136 rest of the test. 1138 G. Start the traffic from the Emulator towards the DUT targeted 1139 at the specific route (e.g. routeA). Initially traffic would 1140 be observed on the Best Egress interface. 1142 H. Now advertise the same route routeA on the Next-Best Egress 1143 Interface but by varying one of the well-known mandatory 1144 attributes to have a preferred value over that interface. We 1145 call this Tbetter. The other values need to be same as what 1146 was advertised on the Best-Egress adjacency 1148 TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A) 1150 I. Measure the Convergence Time for the event to be detected and 1151 traffic to be forwarded to Next-Best Egress Interface 1153 DUT(Path-Change, Rt-A) = Path-switch time(Rt-A) 1155 Convergence = Path-switch time(Rt-A) - Path Change Event 1156 Time(Rt-A) 1158 J. Stop the offered load and wait for the queues to drain and 1159 Restart. 1161 K. Repeat the test for various attributes. 1163 5.8. BGP Graceful Restart Convergence Time 1165 Objective: 1167 This test measures the route convergence time taken by an 1168 implementation during a Graceful Restart Event as detailed in the 1169 Terminology document [RFC4098]. 1171 Reference Test Setup: 1173 This test uses the setup as shown in figure 4. 1175 Procedure: 1177 A. It measures the time taken by an implementation to service a 1178 BGP Graceful Restart Event and advertise a route. 1180 B. The Helper Nodes are the same model as DUT and run the same 1181 BGP implementation as DUT. 1183 C. The BGP implementation on DUT & Helper Node needs to support 1184 BGP Graceful Restart Mechanism [RFC4724]. 1186 D. All devices MUST be synchronized using NTP or some local 1187 reference clock. 1189 E. All variables are set to basic-test values. 1191 F. DUT and Helper Node-1(HLP1) are configured in the same 1192 Autonomous System whereas Emulator and Helper Node-2(HLP2) are 1193 configured under different Autonomous Systems. 1195 G. Establish BGP adjacency between DUT and Helper Nodes. 1197 H. Establish BGP adjacency between Helper Node-2 and Emulator. 1199 I. To ensure adjacency establishment, wait for 3 KeepAlives from 1200 the DUT or a configurable delay before proceeding with the 1201 rest of the test. 1203 J. Configure a policy under BGP on Helper Node-1 to deny routes 1204 received from DUT. 1206 K. Advertise routeA from the Emulator to Helper Node-2. 1208 L. Helper Node-2 advertises the route to DUT and DUT will try to 1209 advertise the route to Helper Node-1 which will be denied. 1211 M. Wait for 3 KeepAlives. 1213 N. Start the traffic from the Emulator towards the Helper Node-1 1214 targeted at the specific route (e.g. routeA). Initially no 1215 traffic would be observed on the Egress interface as the 1216 routeA is not present. 1218 O. Perform a Graceful Restart Trigger Event on DUT and note the 1219 time. This is the GREventTime. 1221 P. Remove the policy on Helper Node-1. 1223 Q. Record the time when the traffic targeted towards routeA is 1224 received on the Egress Interface 1226 TRr(DUT, routeA). This is also called RecTime(Rt-A) 1228 R. The following equation represents the Graceful Restart 1229 Convergence Time 1231 Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - 1232 GREventTime) - RIB-IN) 1234 S. It is assumed in this test case that after a Switchover is 1235 triggered on the DUT, it will not have any cycles to process 1236 BGP Refresh messages. The reason for this assumption is that 1237 there is a narrow window of time where after switchover when 1238 we remove the policy from Helper Node-1, implementations might 1239 generate Route-Refresh automatically and this request might be 1240 serviced before the DUT actually switches over and 1241 reestablishes BGP adjacencies with the peers. 1243 6. Reporting Format 1245 For each test case, it is recommended that the reporting tables below 1246 are completed and all time values SHOULD be reported with resolution 1247 as specified in [RFC4098]. 1249 Parameter Units 1251 Test case Test case number 1253 Test topology 1,2,3 or 4 1255 Parallel links Number of parallel links 1257 Interface type GigE, POS, ATM, other 1259 Convergence Event Hard reset, Soft reset, link 1260 failure, or other defined 1262 eBGP sessions Number of eBGP sessions 1264 iBGP sessions Number of iBGP sessions 1266 eBGP neighbor Number of eBGP neighbors 1268 iBGP neighbor Number of iBGP neighbors 1270 Routes per peer Number of routes 1272 Total unique routes Number of routes 1273 Total non-unique routes Number of routes 1275 IGP configured ISIS, OSPF, static, or other 1277 Route Mixture Description of Route mixture 1279 Route Packing Number of routes in an update 1281 Policy configured Yes, No 1283 SIDR Origin Authentication Yes, No 1284 [RFC7115] 1286 bgp-sec [BGPSec] Yes, No 1288 Packet size offered to the DUT Bytes 1290 Offered load Packets per second 1292 Packet sampling interval on Seconds 1293 tester 1295 Forwarding delay threshold Seconds 1297 Timer Values configured on DUT 1298 Interface failure indication Seconds 1299 delay 1300 Hold time Seconds 1301 MinRouteAdvertisementInterval Seconds 1302 (MRAI) 1303 MinASOriginationInterval Seconds 1304 (MAOI) 1305 Keepalive Time Seconds 1306 ConnectRetry Seconds 1308 TCP Parameters for DUT and tester 1309 MSS Bytes 1310 Slow start threshold Bytes 1311 Maximum window size Bytes 1313 Test Details: 1315 a. If the Offered Load matches a subset of routes, describe how this 1316 subset is selected. 1318 b. Describe how the Convergence Event is applied, does it cause 1319 instantaneous traffic loss or not. 1321 c. If there is any policy configured, describe the configured 1322 policy. 1324 Complete the table below for the initial Convergence Event and the 1325 reversion Convergence Event 1327 Parameter Unit 1329 Convergence Event Initial or reversion 1331 Traffic Forwarding Metrics 1332 Total number of packets Number of packets 1333 offered to DUT 1334 Total number of packets Number of packets 1335 forwarded by DUT 1336 Connectivity Packet Loss Number of packets 1337 Convergence Packet Loss Number of packets 1338 Out-of-order packets Number of packets 1339 Duplicate packets Number of packets 1341 Convergence Benchmarks 1343 Rate-derived Method[RFC 1344 6412]: 1345 First route convergence Seconds 1346 time 1347 Full convergence time Seconds 1349 Loss-derived Method [RFC 1350 6412]: 1351 Loss-derived convergence Seconds 1352 time 1354 Route-Specific Loss-Derived 1355 Method: 1356 Minimum R-S convergence Seconds 1357 time 1358 Maximum R-S convergence Seconds 1359 time 1360 Median R-S convergence Seconds 1361 time 1362 Average R-S convergence Seconds 1363 time 1365 Loss of Connectivity Benchmarks 1367 Loss-derived Method: 1369 Loss-derived loss of Seconds 1370 connectivity period 1372 Route-Specific loss-derived 1373 Method: 1374 Minimum LoC period [n] Array of seconds 1375 Minimum Route LoC period Seconds 1376 Maximum Route LoC period Seconds 1377 Median Route LoC period Seconds 1378 Average Route LoC period Seconds 1380 7. IANA Considerations 1382 This draft does not require any new allocations by IANA. 1384 8. Security Considerations 1386 Benchmarking activities as described in this memo are limited to 1387 technology characterization using controlled stimuli in a laboratory 1388 environment, with dedicated address space and the constraints 1389 specified in the sections above. 1391 The benchmarking network topology will be an independent test setup 1392 and MUST NOT be connected to devices that may forward the test 1393 traffic into a production network, or misroute traffic to the test 1394 management network. 1396 Further, benchmarking is performed on a "black-box" basis, relying 1397 solely on measurements observable external to the DUT/SUT. 1399 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 1400 benchmarking purposes. Any implications for network security arising 1401 from the DUT/SUT SHOULD be identical in the lab and in production 1402 networks. 1404 9. Acknowledgements 1406 We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay 1407 Karthik, Eric Brendel for their input and discussions on various 1408 sections in the document. We also like to acknowledge Will Liu, 1409 Semion Lisyansky, Faisal Shah for their review and feedback to the 1410 document. 1412 10. References 1414 10.1. Normative References 1416 [I-D.ietf-sidr-bgpsec-protocol] 1417 Lepinski, M., "BGPSEC Protocol Specification", 1418 draft-ietf-sidr-bgpsec-protocol-09 (work in progress), 1419 July 2014. 1421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1422 Requirement Levels", BCP 14, RFC 2119, March 1997. 1424 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 1425 September 2000. 1427 [RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P., 1428 and M. Lepp, "Terminology for Benchmarking BGP Device 1429 Convergence in the Control Plane", RFC 4098, June 2005. 1431 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1432 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1434 [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology 1435 for Benchmarking Link-State IGP Data-Plane Route 1436 Convergence", RFC 6412, November 2011. 1438 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1439 Resource Public Key Infrastructure (RPKI)", BCP 185, 1440 RFC 7115, January 2014. 1442 10.2. Informative References 1444 [RFC1242] Bradner, S., "Benchmarking terminology for network 1445 interconnection devices", RFC 1242, July 1991. 1447 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1448 August 1996. 1450 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1451 Switching Devices", RFC 2285, February 1998. 1453 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1454 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1455 March 1999. 1457 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1458 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1459 January 2007. 1461 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1462 "Multiprotocol Extensions for BGP-4", RFC 4760, 1463 January 2007. 1465 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1466 Authentication Option", RFC 5925, June 2010. 1468 Authors' Addresses 1470 Rajiv Papneja 1471 Huawei Technologies 1473 Email: rajiv.papneja@huawei.com 1475 Bhavani Parise 1476 Cisco Systems 1478 Email: bhavani@cisco.com 1480 Susan Hares 1481 Huawei Technologies 1483 Email: shares@ndzh.com 1485 Dean Lee 1486 IXIA 1488 Email: dlee@ixiacom.com 1490 Ilya Varlashkin 1491 Google 1493 Email: ilya@nobulus.com