idnits 2.17.1 draft-ietf-bmwg-bgp-basic-convergence-05.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 (January 16, 2015) is 3389 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 955, but not defined == Missing Reference: 'BGPSec' is mentioned on line 1293, but not defined == Unused Reference: 'I-D.ietf-sidr-bgpsec-protocol' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1438, but no explicit reference was found in the text == Unused Reference: 'RFC6412' is defined on line 1441, 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: July 20, 2015 Cisco Systems 6 S. Hares 7 Huawei Technologies 8 D. Lee 9 IXIA 10 I. Varlashkin 11 Google 12 January 16, 2015 14 Basic BGP Convergence Benchmarking Methodology for Data Plane 15 Convergence 16 draft-ietf-bmwg-bgp-basic-convergence-05.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 July 20, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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-XMT-Data-Time 653 -DUT-RCV-Rt-Time)(Rt-A) 655 RIB convergence = (DUT-XMT-Rt-Time - DUT-RCV-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-XMT-Data-Time(last) - DUT-RCV-Rt- 664 Time(first) 666 RIB-convergence = DUT-XMT-Rt-Time(last) - DUT-RCV-Rt- 667 Time(first) 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). This time is called Shutdown time 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. 803 Restart the data flow. 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 the data flow. 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 Tr-rr1 also called 894 TR1-traffic-on 896 Convergence = TR1-traffic-on - BGPpeer-up 898 5.4. BGP Hard Reset Test Cases 900 5.4.1. BGP Non-Recovering Hard Reset Event on DUT 902 Objective: 904 This test measures the route convergence time due to Hard Reset on 905 the DUT. 907 Reference Test Setup: 909 This test uses the setup as shown in figure 1. 911 Procedure: 913 A. The requirement for this test case is that the Hard Reset 914 Event should be non-recovering and should affect only the 915 adjacency between DUT and Emulator on the Best Egress 916 Interface. 918 B. All variables affecting SHOULD be set to basic-test values. 920 C. Establish 2 BGP adjacencies from DUT to Emulator, one over the 921 Best Egress Interface and the other using the Next-Best Egress 922 Interface. 924 D. Advertise the same route, routeA over both the adjacencies and 925 make Best Egress Interface to be the preferred next hop. 927 E. To ensure adjacency establishment, wait for 3 KeepAlives from 928 the DUT or a configurable delay before proceeding with the 929 rest of the test. 931 F. Start the traffic from the Emulator towards the DUT targeted 932 at a specific route (e.g routeA). Initially traffic would be 933 observed on the Best Egress interface. 935 G. Trigger the Hard Reset event of Best Egress Interface on DUT. 936 This time is called time-reset 938 H. This event is detected and traffic is forwarded to the Next- 939 Best Egress Interface. This tim e called time-traffic flow. 941 I. Measure the Convergence Time for the event to be detected and 942 traffic to be forwarded to Next-Best Egress Interface. 944 Time of convergence = time-traffic flow - time-reset 946 J. Stop the offered load and wait for the queues to drain and 947 Restart. 949 K. It is recommended that the test be repeated with varying 950 number of routes and route mixtures or with number of routes & 951 route mixtures closer to what is deployed in operational 952 networks. 954 L. When varying number of routes are used, convergence Time is 955 measured using the Loss Derived method [IGPData]. 957 M. Convergence Time in this scenario is influenced by Failure 958 detection time on Tester, BGP Keep Alive Time and routing, 959 forwarding table update time. 961 5.5. BGP Soft Reset 963 Objective: 965 This test measures the route convergence time taken by an 966 implementation to service a BGP Route Refresh message and 967 advertise a route. 969 Reference Test Setup: 971 This test uses the setup as shown in figure 2. 973 Procedure: 975 A. The BGP implementation on DUT & Helper Node needs to support 976 BGP Route Refresh Capability [RFC2918]. 978 B. All devices MUST be synchronized using NTP or some local 979 reference clock. 981 C. All variables affecting Convergence like authentication, 982 policies, timers should be set to basic-test defaults. 984 D. DUT and Helper Node are configured in the same Autonomous 985 System whereas Emulator is configured under a different 986 Autonomous System. 988 E. Establish BGP adjacency between DUT and Emulator. 990 F. Establish BGP adjacency between DUT and Helper Node. 992 G. To ensure adjacency establishment, wait for 3 KeepAlives from 993 the DUT or a configurable delay before proceeding with the 994 rest of the test. 996 H. Configure a policy under BGP on Helper Node to deny routes 997 received from DUT. 999 I. Advertise routeA from the Emulator to the DUT. 1001 J. The DUT will try to advertise the route to Helper Node will be 1002 denied. 1004 K. Wait for 3 KeepAlives. 1006 L. Start the traffic from the Emulator towards the Helper Node 1007 targeted at a specific route say routeA. Initially no traffic 1008 would be observed on the Egress interface, as routeA is not 1009 present. 1011 M. Remove the policy on Helper Node and issue a Route Refresh 1012 request towards DUT. Note the timestamp of this event. This 1013 is the RefreshTime. 1015 N. Record the time when the traffic targeted towards routeA is 1016 received on the Egress Interface. This is RecTime. 1018 O. The following equation represents the Route Refresh 1019 Convergence Time per route. 1021 Route Refresh Convergence Time = (RecTime - RefreshTime) 1023 5.6. BGP Route Withdrawal Convergence Time 1025 Objective: 1027 This test measures the route convergence time taken by an 1028 implementation to service a BGP Withdraw message and advertise the 1029 withdraw. 1031 Reference Test Setup: 1033 This test uses the setup as shown in figure 2. 1035 Procedure: 1037 A. This test consists of 2 steps to determine the Total Withdraw 1038 Processing Time. 1040 B. Step 1: 1042 (1) All devices MUST be synchronized using NTP or some local 1043 reference clock. 1045 (2) All variables should be set to basic-test parameters. 1047 (3) DUT and Helper Node are configured in the same 1048 Autonomous System whereas Emulator is configured under a 1049 different Autonomous System. 1051 (4) Establish BGP adjacency between DUT and Emulator. 1053 (5) To ensure adjacency establishment, wait for 3 KeepAlives 1054 from the DUT or a configurable delay before proceeding 1055 with the rest of the test. 1057 (6) Start the traffic from the Emulator towards the DUT 1058 targeted at a specific route (e.g. routeA). Initially 1059 no traffic would be observed on the Egress interface as 1060 the routeA is not present on DUT. 1062 (7) Advertise routeA from the Emulator to the DUT. 1064 (8) The traffic targeted towards routeA is received on the 1065 Egress Interface. 1067 (9) Now the Tester sends request to withdraw routeA to DUT, 1068 TRx(Awith) also called WdrawTime1(Rt-A). 1070 (10) Record the time when no traffic is observed as 1071 determined by the Emulator. This is the 1072 RouteRemoveTime1(Rt-A). 1074 (11) The difference between the RouteRemoveTime1 and 1075 WdrawTime1 is the WdrawConvTime1 1077 WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - 1078 WdrawTime1(Rt-A) 1080 C. Step 2: 1082 (1) Continuing from Step 1, re-advertise routeA back to DUT 1083 from Tester. 1085 (2) The DUT will try to advertise the routeA to Helper Node 1086 (This assumes there exists a session between DUT and 1087 helper node). 1089 (3) Start the traffic from the Emulator towards the Helper 1090 Node targeted at a specific route (e.g. routeA). Traffic 1091 would be observed on the Egress interface after routeA is 1092 received by the Helper Node 1094 WATime=time traffic first flows 1096 (4) Now the Tester sends a request to withdraw routeA to DUT. 1097 This is the WdrawTime2(Rt-A) 1099 WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A) 1101 (5) DUT processes the withdraw and sends it to Helper Node. 1103 (6) Record the time when no traffic is observed as determined 1104 by the Emulator. This is 1106 TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A) 1108 (7) Total withdraw processing time is 1110 TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) - 1111 WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A)) 1113 5.7. BGP Path Attribute Change Convergence Time 1115 Objective: 1117 This test measures the convergence time taken by an implementation 1118 to service a BGP Path Attribute Change. 1120 Reference Test Setup: 1122 This test uses the setup as shown in figure 1. 1124 Procedure: 1126 A. This test only applies to Well-Known Mandatory Attributes like 1127 Origin, AS Path, Next Hop. 1129 B. In each iteration of test only one of these mandatory 1130 attributes need to be varied whereas the others remain the 1131 same. 1133 C. All devices MUST be synchronized using NTP or some local 1134 reference clock. 1136 D. All variables should be set to basic-test parameters. 1138 E. Advertise the route, routeA over the Best Egress Interface 1139 only, making it the preferred named Tbest. 1141 F. To ensure adjacency establishment, wait for 3 KeepAlives from 1142 the DUT or a configurable delay before proceeding with the 1143 rest of the test. 1145 G. Start the traffic from the Emulator towards the DUT targeted 1146 at the specific route (e.g. routeA). Initially traffic would 1147 be observed on the Best Egress interface. 1149 H. Now advertise the same route routeA on the Next-Best Egress 1150 Interface but by varying one of the well-known mandatory 1151 attributes to have a preferred value over that interface. We 1152 call this Tbetter. The other values need to be same as what 1153 was advertised on the Best-Egress adjacency 1155 TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A) 1157 I. Measure the Convergence Time for the event to be detected and 1158 traffic to be forwarded to Next-Best Egress Interface 1160 DUT(Path-Change, Rt-A) = Path-switch time(Rt-A) 1162 Convergence = Path-switch time(Rt-A) - Path Change Event 1163 Time(Rt-A) 1165 J. Stop the offered load and wait for the queues to drain and 1166 Restart. 1168 K. Repeat the test for various attributes. 1170 5.8. BGP Graceful Restart Convergence Time 1172 Objective: 1174 This test measures the route convergence time taken by an 1175 implementation during a Graceful Restart Event as detailed in the 1176 Terminology document [RFC4098]. 1178 Reference Test Setup: 1180 This test uses the setup as shown in figure 4. 1182 Procedure: 1184 A. It measures the time taken by an implementation to service a 1185 BGP Graceful Restart Event and advertise a route. 1187 B. The Helper Nodes are the same model as DUT and run the same 1188 BGP implementation as DUT. 1190 C. The BGP implementation on DUT & Helper Node needs to support 1191 BGP Graceful Restart Mechanism [RFC4724]. 1193 D. All devices MUST be synchronized using NTP or some local 1194 reference clock. 1196 E. All variables are set to basic-test values. 1198 F. DUT and Helper Node-1(HLP1) are configured in the same 1199 Autonomous System whereas Emulator and Helper Node-2(HLP2) are 1200 configured under different Autonomous Systems. 1202 G. Establish BGP adjacency between DUT and Helper Nodes. 1204 H. Establish BGP adjacency between Helper Node-2 and Emulator. 1206 I. To ensure adjacency establishment, wait for 3 KeepAlives from 1207 the DUT or a configurable delay before proceeding with the 1208 rest of the test. 1210 J. Configure a policy under BGP on Helper Node-1 to deny routes 1211 received from DUT. 1213 K. Advertise routeA from the Emulator to Helper Node-2. 1215 L. Helper Node-2 advertises the route to DUT and DUT will try to 1216 advertise the route to Helper Node-1 which will be denied. 1218 M. Wait for 3 KeepAlives. 1220 N. Start the traffic from the Emulator towards the Helper Node-1 1221 targeted at the specific route (e.g. routeA). Initially no 1222 traffic would be observed on the Egress interface as the 1223 routeA is not present. 1225 O. Perform a Graceful Restart Trigger Event on DUT and note the 1226 time. This is the GREventTime. 1228 P. Remove the policy on Helper Node-1. 1230 Q. Record the time when the traffic targeted towards routeA is 1231 received on the Egress Interface 1233 TRr(DUT, routeA). This is also called RecTime(Rt-A) 1235 R. The following equation represents the Graceful Restart 1236 Convergence Time 1238 Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - 1239 GREventTime) - RIB-IN) 1241 S. It is assumed in this test case that after a Switchover is 1242 triggered on the DUT, it will not have any cycles to process 1243 BGP Refresh messages. The reason for this assumption is that 1244 there is a narrow window of time where after switchover when 1245 we remove the policy from Helper Node-1, implementations might 1246 generate Route-Refresh automatically and this request might be 1247 serviced before the DUT actually switches over and 1248 reestablishes BGP adjacencies with the peers. 1250 6. Reporting Format 1252 For each test case, it is recommended that the reporting tables below 1253 are completed and all time values SHOULD be reported with resolution 1254 as specified in [RFC4098]. 1256 Parameter Units 1258 Test case Test case number 1260 Test topology 1,2,3 or 4 1262 Parallel links Number of parallel links 1264 Interface type GigE, POS, ATM, other 1266 Convergence Event Hard reset, Soft reset, link 1267 failure, or other defined 1269 eBGP sessions Number of eBGP sessions 1271 iBGP sessions Number of iBGP sessions 1273 eBGP neighbor Number of eBGP neighbors 1274 iBGP neighbor Number of iBGP neighbors 1276 Routes per peer Number of routes 1278 Total unique routes Number of routes 1280 Total non-unique routes Number of routes 1282 IGP configured ISIS, OSPF, static, or other 1284 Route Mixture Description of Route mixture 1286 Route Packing Number of routes in an update 1288 Policy configured Yes, No 1290 SIDR Origin Authentication Yes, No 1291 [RFC7115] 1293 bgp-sec [BGPSec] Yes, No 1295 Packet size offered to the DUT Bytes 1297 Offered load Packets per second 1299 Packet sampling interval on Seconds 1300 tester 1302 Forwarding delay threshold Seconds 1304 Timer Values configured on DUT 1305 Interface failure indication Seconds 1306 delay 1307 Hold time Seconds 1308 MinRouteAdvertisementInterval Seconds 1309 (MRAI) 1310 MinASOriginationInterval Seconds 1311 (MAOI) 1312 Keepalive Time Seconds 1313 ConnectRetry Seconds 1315 TCP Parameters for DUT and tester 1316 MSS Bytes 1317 Slow start threshold Bytes 1318 Maximum window size Bytes 1320 Test Details: 1322 a. If the Offered Load matches a subset of routes, describe how this 1323 subset is selected. 1325 b. Describe how the Convergence Event is applied, does it cause 1326 instantaneous traffic loss or not. 1328 c. If there is any policy configured, describe the configured 1329 policy. 1331 Complete the table below for the initial Convergence Event and the 1332 reversion Convergence Event 1334 Parameter Unit 1336 Convergence Event Initial or reversion 1338 Traffic Forwarding Metrics 1339 Total number of packets Number of packets 1340 offered to DUT 1341 Total number of packets Number of packets 1342 forwarded by DUT 1343 Connectivity Packet Loss Number of packets 1344 Convergence Packet Loss Number of packets 1345 Out-of-order packets Number of packets 1346 Duplicate packets Number of packets 1348 Convergence Benchmarks 1350 Rate-derived Method[RFC 1351 6412]: 1352 First route convergence Seconds 1353 time 1354 Full convergence time Seconds 1356 Loss-derived Method [RFC 1357 6412]: 1358 Loss-derived convergence Seconds 1359 time 1361 Route-Specific Loss-Derived 1362 Method: 1363 Minimum R-S convergence Seconds 1364 time 1365 Maximum R-S convergence Seconds 1366 time 1367 Median R-S convergence Seconds 1368 time 1370 Average R-S convergence Seconds 1371 time 1373 Loss of Connectivity Benchmarks 1375 Loss-derived Method: 1376 Loss-derived loss of Seconds 1377 connectivity period 1379 Route-Specific loss-derived 1380 Method: 1381 Minimum LoC period [n] Array of seconds 1382 Minimum Route LoC period Seconds 1383 Maximum Route LoC period Seconds 1384 Median Route LoC period Seconds 1385 Average Route LoC period Seconds 1387 7. IANA Considerations 1389 This draft does not require any new allocations by IANA. 1391 8. Security Considerations 1393 Benchmarking activities as described in this memo are limited to 1394 technology characterization using controlled stimuli in a laboratory 1395 environment, with dedicated address space and the constraints 1396 specified in the sections above. 1398 The benchmarking network topology will be an independent test setup 1399 and MUST NOT be connected to devices that may forward the test 1400 traffic into a production network, or misroute traffic to the test 1401 management network. 1403 Further, benchmarking is performed on a "black-box" basis, relying 1404 solely on measurements observable external to the DUT/SUT. 1406 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 1407 benchmarking purposes. Any implications for network security arising 1408 from the DUT/SUT SHOULD be identical in the lab and in production 1409 networks. 1411 9. Acknowledgements 1413 We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay 1414 Karthik, Eric Brendel for their input and discussions on various 1415 sections in the document. We also like to acknowledge Will Liu, 1416 Semion Lisyansky, Faisal Shah for their review and feedback to the 1417 document. 1419 10. References 1421 10.1. Normative References 1423 [I-D.ietf-sidr-bgpsec-protocol] 1424 Lepinski, M., "BGPSEC Protocol Specification", 1425 draft-ietf-sidr-bgpsec-protocol-09 (work in progress), 1426 July 2014. 1428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", BCP 14, RFC 2119, March 1997. 1431 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 1432 September 2000. 1434 [RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P., 1435 and M. Lepp, "Terminology for Benchmarking BGP Device 1436 Convergence in the Control Plane", RFC 4098, June 2005. 1438 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1439 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1441 [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology 1442 for Benchmarking Link-State IGP Data-Plane Route 1443 Convergence", RFC 6412, November 2011. 1445 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1446 Resource Public Key Infrastructure (RPKI)", BCP 185, 1447 RFC 7115, January 2014. 1449 10.2. Informative References 1451 [RFC1242] Bradner, S., "Benchmarking terminology for network 1452 interconnection devices", RFC 1242, July 1991. 1454 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1455 August 1996. 1457 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1458 Switching Devices", RFC 2285, February 1998. 1460 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1461 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1462 March 1999. 1464 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1465 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1466 January 2007. 1468 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1469 "Multiprotocol Extensions for BGP-4", RFC 4760, 1470 January 2007. 1472 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1473 Authentication Option", RFC 5925, June 2010. 1475 Authors' Addresses 1477 Rajiv Papneja 1478 Huawei Technologies 1480 Email: rajiv.papneja@huawei.com 1482 Bhavani Parise 1483 Cisco Systems 1485 Email: bhavani@cisco.com 1487 Susan Hares 1488 Huawei Technologies 1490 Email: shares@ndzh.com 1492 Dean Lee 1493 IXIA 1495 Email: dlee@ixiacom.com 1497 Ilya Varlashkin 1498 Google 1500 Email: ilya@nobulus.com