idnits 2.17.1 draft-ietf-bmwg-bgp-basic-convergence-01.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 (Mar 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MPLSProt' is mentioned on line 442, but not defined == Missing Reference: 'IGPData' is mentioned on line 931, but not defined == Unused Reference: 'RFC6412' is defined on line 1366, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6412 Summary: 1 error (**), 0 flaws (~~), 5 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: Standards Track B. Parise 5 Expires: September 2, 2014 Cisco Systems 6 S. Hares 7 Adara Networks 8 D. Lee 9 IXIA 10 I. Varlashkin 11 Easynet Global Services 12 Mar 2014 14 Basic BGP Convergence Benchmarking Methodology for Data Plane 15 Convergence 16 draft-ietf-bmwg-bgp-basic-convergence-01.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 September 2, 2014. 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. Precise Benchmarking Definition . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 14 97 5.1.3. eBGP Convergence . . . . . . . . . . . . . . . . . . . 16 98 5.1.4. iBGP Convergence . . . . . . . . . . . . . . . . . . . 16 99 5.1.5. eBGP Multihop Convergence . . . . . . . . . . . . . . 16 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 . . . . . 19 103 5.2.3. ECMP Link Failure on DUT End . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . 22 109 5.6. BGP Route Withdrawal Convergence Time . . . . . . . . . . 23 110 5.7. BGP Path Attribute Change Convergence Time . . . . . . . . 25 111 5.8. BGP Graceful Restart Convergence Time . . . . . . . . . . 26 112 6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 28 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 121 1. Introduction 123 This document defines the methodology for benchmarking data plane FIB 124 convergence performance of BGP in router and switches for simple 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]. 131 The scope of this companion document is limited to basic BGP protocol 132 FIB convergence measurements. BGP extensions outside of carrying 133 IPv6 in (MP-BGP) [RFC4760, RFC2545] are outside the scope of this 134 document. Interaction with IGPs (IGP interworking) is outside the 135 scope of this document. 137 1.1. Precise Benchmarking Definition 139 Since benchmarking is science of precision, let us restate the 140 purpose of this document in benchmarking terms. This document 141 defines methodology to test 143 - data plane convergence on a single BGP device that supports the BGP 144 [RFC4271] functionality 146 - in test topology of 3 or 4 nodes 148 - using Basic BGP. 150 Data plane convergence is defined as the completion of all FIB 151 changes so that all forwarded traffic now takes the new proposed 152 route. RFC 4098 defines the terms BGP device, FIB and the forwarded 153 traffic. Data plane convergence is different than control plane 154 convergence within a node. 156 Basic BGP is defined as RFC 4271 functional with Multi-Protocol BGP 157 (MP-BGP) [RFC4760, RFC2545] for IPv6. The use of other extensions of 158 BGP to support layer-2, layer-3 virtual private networks (VPN) are 159 out of scope of this document. 161 The terminology used in this document is defined in [RFC4098]. One 162 additional term is defined in this draft: FIB (Data plane) BGP 163 Convergence. 165 1.2. Purpose of BGP FIB (Data Plane) Convergence 167 In the current Internet architecture the Inter-Autonomous System 168 (inter-AS) transit is primarily available through BGP. To maintain a 169 reliable connectivity within intra-domains or across inter-domains, 170 fast recovery from failures remains most critical. To ensure minimal 171 traffic losses, many service providers are requiring BGP 172 implementations to converge the entire Internet routing table within 173 sub-seconds at FIB level. 175 Furthermore, to compare these numbers amongst various devices, 176 service providers are also looking at ways to standardize the 177 convergence measurement methods. This document offers test methods 178 for simple topologies. These simple tests will provide a quick high- 179 level check, of the BGP data plane convergence across multiple 180 implementations. 182 1.3. Control Plane Convergence 184 The convergence of BGP occurs at two levels: RIB and FIB convergence. 185 RFC 4098 defines terms for BGP control plane convergence. 186 Methodologies which test control plane convergence are out of scope 187 for this draft. 189 1.4. Benchmarking Testing 191 In order to ensure that the results obtained in tests are repeatable, 192 careful setup of initial conditions and exact steps are required. 194 This document proposes these initial conditions, test steps, and 195 result checking. To ensure uniformity of the results all optional 196 parameters SHOULD be disabled and all settings SHOULD be changed to 197 default, these may include BGP timers as well. 199 2. Existing Definitions and Requirements 201 RFC 1242, "Benchmarking Terminology for Network Interconnect Devices" 202 [RFC1242] and RFC 2285, "Benchmarking Terminology for LAN Switching 203 Devices" [RFC2285] SHOULD be reviewed in conjunction with this 204 document. WLAN-specific terms and definitions are also provided in 205 Clauses 3 and 4 of the IEEE 802.11 standard [802.11]. Commonly used 206 terms may also be found in RFC 1983 [RFC1983]. 208 For the sake of clarity and continuity, this document adopts the 209 general template for benchmarking terminology set out in Section 2 of 210 RFC 1242. Definitions are organized in alphabetical order, and 211 grouped into sections for ease of reference. The following terms are 212 assumed to be taken as defined in RFC 1242 [RFC1242]: Throughput, 213 Latency, Constant Load, Frame Loss Rate, and Overhead Behavior. In 214 addition, the following terms are taken as defined in [RFC2285]: 215 Forwarding Rates, Maximum Forwarding Rate, Loads, Device Under Test 216 (DUT), and System Under Test (SUT). 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 3. Test Topologies 224 This section describes simple test setups for use in BGP benchmarking 225 tests measuring convergence of the FIB (data plane) after the BGP 226 updates has been received. 228 These simple test nodes have 3 or 4 nodes with the following 229 configuration: 231 1. Basic Test Setup 233 2. Three node setup for iBGP or eBGP convergence 235 3. Setup for eBGP multihop test scenario 237 4. Four node setup for iBGP or eBGP convergence 239 Individual tests refer to these topologies. 241 Figures 1-4 use the following conventions 243 o AS-X: Autonomous System X 245 o Loopback Int: Loopback interface on the BGP enabled device 247 o R2: Helper router 249 3.1. General Reference Topologies 251 Emulator acts as 1 or more BGP peers for different testcases. 253 +----------+ +------------+ 254 | | traffic interfaces | | 255 | |-----------------------1---- | tx | 256 | |-----------------------2---- | tr1 | 257 | |-----------------------3-----| tr2 | 258 | DUT | routing interfaces | Emulator | 259 | | | | 260 | Dp1 |--------------------------- |Emp1 | 261 | | BGP Peering | | 262 | Dp2 |---------------------------- |Emp2 | 263 | | BGP Peering | | 264 +----------+ +------------+ 266 Figure 1 Basic Test Setup 268 +------------+ +-----------+ +-----------+ 269 | | | | | | 270 | | | | | | 271 | HLP | | DUT | | Emulator | 272 | (AS-X) |--------| (AS-Y) |-----------| (AS-Z) | 273 | | | | | | 274 | | | | | | 275 | | | | | | 276 +------------+ +-----------+ +-----------+ 277 | | 278 | | 279 +--------------------------------------------+ 281 Figure 2 Three Node Setup for eBGP and iBGP Convergence 282 +----------------------------------------------+ 283 | | 284 | | 285 +------------+ +-----------+ +-----------+ 286 | | | | | | 287 | | | | | | 288 | HLP | | DUT | | Emulator | 289 | (AS-X) |--------| (AS-Y) |-----------| (AS-Z) | 290 | | | | | | 291 | | | | | | 292 | | | | | | 293 +------------+ +-----------+ +-----------+ 294 |Loopback-Int |Loopback-Int 295 | | 296 + + 298 Figure 3 BGP Convergence for eBGP Multihop Scenario 300 +---------+ +--------+ +--------+ +---------+ 301 | | | | | | | | 302 | | | | | | | | 303 | HLP1 | | DUT | | HLP2 | |Emulator | 304 | (AS-X) |-----| (AS-X) |-----| (AS-Y) |-----| (AS-Z) | 305 | | | | | | | | 306 | | | | | | | | 307 | | | | | | | | 308 +---------+ +--------+ +--------+ +---------+ 309 | | 310 | | 311 +---------------------------------------------+ 313 Figure 4 Four Node Setup for EBGP and IBGP Convergence 315 4. Test Considerations 317 The test cases for measuring convergence for iBGP and eBGP are 318 different. Both iBGP and eBGP use different mechanisms to advertise, 319 install and learn the routes. Typically, an iBGP route on the DUT is 320 installed and exported when the next-hop is valid. For eBGP the 321 route is installed on the DUT with the remote interface address as 322 the next-hop, with the exception of the multihop test case (as 323 specified in the test). 325 4.1. Number of Peers 327 Number of Peers is defined as the number of BGP neighbors or sessions 328 the DUT has at the beginning of the test. The peers are established 329 before the tests begin. The relationship could be either, iBGP or 330 eBGP peering depending upon the test case requirement. 332 The DUT establishes one or more BGP sessions with one more emulated 333 routers or helper nodes. Additional peers can be added based on the 334 testing requirements. The number of peers enabled during the testing 335 should be well documented in the report matrix. 337 4.2. Number of Routes per Peer 339 Number of Routes per Peer is defined as the number of routes 340 advertised or learnt by the DUT per session or through neighbor 341 relationship with an emulator or helper node. The tester, emulating 342 as neighbor MUST advertise at least one route per peer. 344 Each test run must identify the route stream in terms of route 345 packing, route mixture, and number of routes. This route stream must 346 be well documented in the reporting stream. RFC 4098 defines these 347 terms. 349 It is RECOMMENDED that the user may consider advertising the entire 350 current Internet routing table per peering session using an Internet 351 route mixture with unique or non-unique routes. If multiple peers 352 are used, it is important to precisely document the timing sequence 353 between the peer sending routes (as defined in RFC 4098). 355 4.3. Policy Processing/Reconfiguration 357 The DUT MUST run one baseline test where policy is Minimal policy as 358 defined in RFC 4098. Additional runs may be done with policy set-up 359 before the tests begin. Exact policy settings should be documented 360 as part of the test. 362 4.4. Configured Parameters (Timers, etc..) 364 There are configured parameters and timers that may impact the 365 measured BGP convergence times. 367 The benchmark metrics MAY be measured at any fixed values for these 368 configured parameters. 370 It is RECOMMENDED these configure parameters have the following 371 settings: a)default values specified by the respective RFC 372 b)platform-specific default parameters and c)values as expected in 373 the operational network. All optional BGP settings MUST be kept 374 consistent across iterations of any specific tests 376 Examples of the configured parameters that may impact measured BGP 377 convergence time include, but are not limited to: 379 1. Interface failure detection timer 381 2. BGP Keepalive timer 383 3. BGP Holdtime 385 4. BGP update delay timer 387 5. ConnectRetry timer 389 6. TCP Segment Size 391 7. Minimum Route Advertisement Interval (MRAI) 393 8. MinASOriginationInterval (MAOI) 395 9. Route Flap Dampening parameters 397 10. TCP MD5 399 11. Maximum TCP Window Size 401 12. MTU 403 The basic-test settings for the parameters should be: 405 1. Interface failure detection timer (0 ms) 407 2. BGP Keepalive timer (1 min) 409 3. BGP Holdtime (3 min) 411 4. BGP update delay timer (0 s) 412 5. ConnectRetry timer (1 s) 414 6. TCP Segment Size (4096) 416 7. Minimum Route Advertisement Interval (MRAI) (0 s) 418 8. MinASOriginationInterval (MAOI)(0 s) 420 9. Route Flap Dampening parameters (off) 422 10. TCP MD5 (off) 424 4.5. Interface Types 426 The type of media dictate which test cases may be executed, each 427 interface type has unique mechanism for detecting link failures and 428 the speed at which that mechanism operates will influence the 429 measurement results. All interfaces MUST be of the same media and 430 throughput for each test case. 432 4.6. Measurement Accuracy 434 Since observed packet loss is used to measure the route convergence 435 time, the time between two successive packets offered to each 436 individual route is the highest possible accuracy of any packet-loss 437 based measurement. When packet jitter is much less than the 438 convergence time, it is a negligible source of error and hence it 439 will be treated as within tolerance. 441 Other options to measure convergence are the Time-Based Loss Method 442 (TBLM) and Timestamp Based Method(TBM)[MPLSProt]. 444 An exterior measurement on the input media (such Ethernet)is defined 445 by this specification. 447 4.7. Measurement Statistics 449 The benchmark measurements may vary for each trial, due to the 450 statistical nature of timer expirations, CPU scheduling, etc. It is 451 recommended to repeat the test multiple times. Evaluation of the 452 test data must be done with an understanding of generally accepted 453 testing practices regarding repeatability, variance and statistical 454 significance of a small number of trials. 456 For any repeated tests that are averaged to remove variance, all 457 parameters MUST remain the same. 459 4.8. Authentication 461 Authentication in BGP is done using the TCP MD5 Signature Option 462 [RFC5925]. The processing of the MD5 hash, particularly in devices 463 with a large number of BGP peers and a large amount of update 464 traffic, can have an impact on the control plane of the device. If 465 authentication is enabled, it SHOULD be documented correctly in the 466 reporting format. 468 4.9. Convergence Events 470 Convergence events or triggers are defined as abnormal occurrences in 471 the network, which initiate route flapping in the network, and hence 472 forces the re-convergence of a steady state network. In a real 473 network, a series of convergence events may cause convergence latency 474 operators desire to test. 476 These convergence events must be defined in terms of the sequences 477 defined in RFC 4098. This basic document begins all tests with a 478 router initial set-up. Additional documents will define BGP data 479 plane convergence based on peer initialization. 481 The convergence events may or may not be tied to the actual failure A 482 Soft Reset (RFC 4098) does not clear the RIB or FIB tables. A Hard 483 reset clears the BGP peer sessions, the RIB tables, and FIB tables. 485 4.10. High Availability 487 Due to the different Non-Stop-Routing (sometimes referred to High- 488 Availability) solutions available from different vendors, it is 489 RECOMMENDED that any redundancy available in the routing processors 490 should be disabled during the convergence measurements. 492 5. Test Cases 494 All tests defined under this section assume the following: 496 a. BGP peers should be brought to BGP Peer established state 498 b. BGP peers should be brought down and reestablished between each 499 test iteration. This is recommended to ensure each test 500 iteration starts with a clean state. 502 c. Furthermore the traffic generation and routing should be verified 503 in the topology to ensure there is no packet loss observed on any 504 advertised routes 506 5.1. Basic Convergence Tests 508 These test cases measure characteristics of a BGP implementation in 509 non-failure scenarios like: 511 1. RIB-IN Convergence 513 2. RIB-OUT Convergence 515 3. eBGP Convergence 517 4. iBGP Convergence 519 5.1.1. RIB-IN Convergence 521 Objective: 523 This test measures the convergence time taken to receive and 524 install a route in RIB using BGP. 526 Reference Test Setup: 528 This test uses the setup as shown in figure 1 530 Procedure: 532 A. All variables affecting Convergence should be set to a basic 533 test state (as defined in section 4-4). 535 B. Establish BGP adjacency between DUT and peer x of Emulator. 537 C. To ensure adjacency establishment, wait for 3 KeepAlives from 538 the DUT or a configurable delay before proceeding with the 539 rest of the test. 541 D. Start the traffic from the Emulator peer-x towards the DUT 542 targeted at a routes specified in route mixture (ex. route A) 543 Initially no traffic SHOULD be observed on the egress 544 interface as the route A is not installed in the forwarding 545 database of the DUT. 547 E. Advertise route A from the Peer-x to the DUT and record the 548 time. 550 This is Tup(EMx,Rt-A) also named 'XMT-Rt-time(Rt-A)'. 552 F. Record the time when the route A from Peer-x is received at 553 the DUT. 555 This Tup(DUT,Rt-A) also named 'RCV-Rt-time(Rt-A)'. 557 G. Record the time when the traffic targeted towards route A is 558 received by Emulator on appropriate traffic egress interface. 560 This is TR(TDr,Rt-A). This is also named DUT-XMT-Data- 561 Time(Rt-A). 563 H. The difference between the Tup(DUT,RT-A) and traffic received 564 time (TR (TDr, Rt-A) is the FIB Convergence Time for route A 565 in the route mixture. A full convergence for the route update 566 is the measurement between the 1st route (Rt-A) and the last 567 route (Rt-last) 569 Route update convergence is 571 TR(TDr, Rt-last)- Tup(DUT, Rt-A) or 573 (DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A) 575 Note: It is recommended that a single test with the same route 576 mixture be repeated several times. A report should provide the Stand 577 Deviation of all tests and the Average. 579 Running tests with a varying number of routes and route mixtures is 580 important to get a full characterization of a single peer. 582 5.1.2. RIB-OUT Convergence 584 Objective: 586 This test measures the convergence time taken by an implementation 587 to receive, install and advertise a route using BGP. 589 Reference Test Setup: 591 This test uses the setup as shown in figure 2. 593 Procedure: 595 A. The Helper node (HLP) run same version of BGP as DUT. 597 B. All devices MUST be synchronized using NTP or some local 598 reference clock. 600 C. All configuration variables for HLP, DUT and Emulator SHOULD 601 be set to the same values. These values MAY be basic-test or 602 a unique set completely described in the test set-up. 604 D. Establish BGP adjacency between DUT and Emulator. 606 E. Establish BGP adjacency between DUT and Helper Node. 608 F. To ensure adjacency establishment, wait for 3 KeepAlives from 609 the DUT or a configurable delay before proceeding with the 610 rest of the test. 612 G. Start the traffic from the Emulator towards the Helper Node 613 targeted at a specific route (e.g. route A). Initially no 614 traffic SHOULD be observed on the egress interface as the 615 route A is not installed in the forwarding database of the 616 DUT. 618 H. Advertise route A from the Emulator to the DUT and note the 619 time. 621 This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A) 623 I. Record when route A is received by DUT. 625 This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A) 627 J. Record the time when the route A is forwarded by DUT towards 628 the Helper node. 630 This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A) 632 K. Record the time when the traffic targeted towards route A is 633 received on the Route Egress Interface. This is TR(EMr, 634 Rt-A), also named DUT-XMT-Data Time(Rt-A). 636 FIB convergence = (DUT-RCV-Rt-Time - 637 DUT-XMT-Data-Time)(Rt-A) 639 RIB convergence = (DUT-RCV-Rt-Time - DUT-XMT-Rt-Time)(Rt-A) 640 Convergence for a route stream is characterized by 642 a) Individual route convergence for FIB, RIB 644 b) All route convergence of 646 FIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Data- 647 Time(last) 649 RIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Rt- 650 Time(last) 652 5.1.3. eBGP Convergence 654 Objective: 656 This test measures the convergence time taken by an implementation 657 to receive, install and advertise a route in an eBGP Scenario. 659 Reference Test Setup: 661 This test uses the setup as shown in figure 2 and the scenarios 662 described in RIB-IN and RIB-OUT are applicable to this test case. 664 5.1.4. iBGP Convergence 666 Objective: 668 This test measures the convergence time taken by an implementation 669 to receive, install and advertise a route in an iBGP Scenario. 671 Reference Test Setup: 673 This test uses the setup as shown in figure 2 and the scenarios 674 described in RIB-IN and RIB-OUT are applicable to this test case. 676 5.1.5. eBGP Multihop Convergence 678 Objective: 680 This test measures the convergence time taken by an implementation 681 to receive, install and advertise a route in an eBGP Multihop 682 Scenario. 684 Reference Test Setup: 686 This test uses the setup as shown in figure 3. DUT is used along 687 with a helper node. 689 Procedure: 691 A. The Helper Node (HLP) runs the same BGP version as DUT. 693 B. All devices to be synchronized using NTP. 695 C. All variables affecting Convergence like authentication, 696 policies, timers should be set to basic-settings 698 D. All 3 devices, DUT, Emulator and Helper Node are configured 699 with different Autonomous Systems. 701 E. Loopback Interfaces are configured on DUT and Helper Node and 702 connectivity is established between them using any config 703 options available on the DUT. 705 F. Establish BGP adjacency between DUT and Emulator. 707 G. Establish BGP adjacency between DUT and Helper Node. 709 H. To ensure adjacency establishment, wait for 3 KeepAlives from 710 the DUT or a configurable delay before proceeding with the 711 rest of the tes.t 713 I. Start the traffic from the Emulator towards the DUT targeted 714 at a specific route (e.g. route A). 716 J. Initially no traffic SHOULD be observed on the egress 717 interface as the route A is not installed in the forwarding 718 database of the DUT. 720 K. Advertise route A from the Emulator to the DUT and note the 721 time (Tup(EMx,RouteA) also named Route-Tx-time(Rt-A). 723 L. Record the time when the route is received by the DUT. This 724 is Tup(EMr,DUT) named Route-Rcv-time(Rt-A). 726 M. Record the time when the traffic targeted towards route A is 727 received from Egress Interface of DUT on emulator. This is 728 Tup(EMd,DUT) named Data-Rcv-time(Rt-A) 730 N. Record the time when the route A is forwarded by DUT towards 731 the Helper node. This is Tup(EMf,DUT) also named Route-Fwd- 732 time(Rt-A) 734 FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A) 736 RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A) 738 Note: It is recommended that the test be repeated with varying number 739 of routes and route mixtures. With each set route mixture, the test 740 should be repeated multiple times. The results should record 741 average, mean, Standard Deviation 743 5.2. BGP Failure/Convergence Events 745 5.2.1. Physical Link Failure on DUT End 747 Objective: 749 This test measures the route convergence time due to local link 750 failure event at DUT's Local Interface. 752 Reference Test Setup: 754 This test uses the setup as shown in figure 1. Shutdown event is 755 defined as an administrative shutdown event on the DUT. 757 Procedure: 759 A. All variables affecting Convergence like authentication, 760 policies, timers should be set to basic-test policy. 762 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 763 peer interface and the other using a second peer interface. 765 C. Advertise the same route, route A over both the adjacencies 766 and (Tx1)Interface to be the preferred next hop. 768 D. To ensure adjacency establishment, wait for 3 KeepAlives from 769 the DUT or a configurable delay before proceeding with the 770 rest of the test. 772 E. Start the traffic from the Emulator towards the DUT targeted 773 at a specific route (e.g. route A). Initially traffic would 774 be observed on the best egress route (Emp1) instead of Trr2. 776 F. Trigger the shutdown event of Best Egress Interface on DUT 777 (Drr1). 779 G. Measure the Convergence Time for the event to be detected and 780 traffic to be forwarded to Next-Best Egress Interface (rr2) 782 Time = Data-detect(rr2) - Shutdown time 784 H. Stop the offered load and wait for the queues to drain and 785 Restart. 787 I. Bring up the link on DUT Best Egress Interface. 789 J. Measure the convergence time taken for the traffic to be 790 rerouted from (rr2) to Best Interface (rr1) 792 Time = Data-detect(rr1) - Bring Up time 794 K. It is recommended that the test be repeated with varying 795 number of routes and route mixtures or with number of routes & 796 route mixtures closer to what is deployed in operational 797 networks. 799 5.2.2. Physical Link Failure on Remote/Emulator End 801 Objective: 803 This test measures the route convergence time due to local link 804 failure event at Tester's Local Interface. 806 Reference Test Setup: 808 This test uses the setup as shown in figure 1. Shutdown event is 809 defined as shutdown of the local interface of Tester via logical 810 shutdown event. The procedure used in 5.2.1 is used for the 811 termination. 813 5.2.3. ECMP Link Failure on DUT End 815 Objective: 817 This test measures the route convergence time due to local link 818 failure event at ECMP Member. The FIB configuration and BGP is 819 set to allow two ECMP routes to be installed. However, policy 820 directs the routes to be sent only over one of the paths 822 Reference Test Setup: 824 This test uses the setup as shown in figure 1 and the procedure 825 uses 5.2.1. 827 5.3. BGP Adjacency Failure (Non-Physical Link Failure) on Emulator 829 Objective: 831 This test measures the route convergence time due to BGP Adjacency 832 Failure on Emulator. 834 Reference Test Setup: 836 This test uses the setup as shown in figure 1. 838 Procedure: 840 A. All variables affecting Convergence like authentication, 841 policies, timers should be basic-policy set. 843 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 844 Best Egress Interface and the other using the Next-Best Egress 845 Interface. 847 C. Advertise the same route, routeA over both the adjacencies and 848 make Best Egress Interface to be the preferred next hop 850 D. To ensure adjacency establishment, wait for 3 KeepAlives from 851 the DUT or a configurable delay before proceeding with the 852 rest of the test. 854 E. Start the traffic from the Emulator towards the DUT targeted 855 at a specific route say routeA. Initially traffic would be 856 observed on the Best Egress interface. 858 F. Remove BGP adjacency via a software adjacency down on the 859 Emulator on the Best Egress Interface. This time is called 860 BGPadj-down-time also termed BGPpeer-down 862 G. Measure the Convergence Time for the event to be detected and 863 traffic to be forwarded to Next-Best Egress Interface. This 864 time is Tr-rr2 also called TR2-traffic-on 866 Convergence = TR2-traffic-on - BGPpeer-down 868 H. Stop the offered load and wait for the queues to drain and 869 Restart. 871 I. Bring up BGP adjacency on the Emulator over the Best Egress 872 Interface. This time is BGP-adj-up also called BGPpeer-up 874 J. Measure the convergence time taken for the traffic to be 875 rerouted to Best Interface. This time is BGP-adj-up also 876 called BGPpeer-up 878 5.4. BGP Hard Reset Test Cases 880 5.4.1. BGP Non-Recovering Hard Reset Event on DUT 882 Objective: 884 This test measures the route convergence time due to Hard Reset on 885 the DUT. 887 Reference Test Setup: 889 This test uses the setup as shown in figure 1. 891 Procedure: 893 A. The requirement for this test case is that the Hard Reset 894 Event should be non-recovering and should affect only the 895 adjacency between DUT and Emulator on the Best Egress 896 Interface. 898 B. All variables affecting SHOULD be set to basic-test values. 900 C. Establish 2 BGP adjacencies from DUT to Emulator, one over the 901 Best Egress Interface and the other using the Next-Best Egress 902 Interface. 904 D. Advertise the same route, routeA over both the adjacencies and 905 make Best Egress Interface to be the preferred next hop. 907 E. To ensure adjacency establishment, wait for 3 KeepAlives from 908 the DUT or a configurable delay before proceeding with the 909 rest of the test. 911 F. Start the traffic from the Emulator towards the DUT targeted 912 at a specific route (e.g route A). Initially traffic would be 913 observed on the Best Egress interface. 915 G. Trigger the Hard Reset event of Best Egress Interface on DUT. 917 H. Measure the Convergence Time for the event to be detected and 918 traffic to be forwarded to Next-Best Egress Interface. 920 Time of convergence = time-traffic flow - time-reset 922 I. Stop the offered load and wait for the queues to drain and 923 Restart. 925 J. It is recommended that the test be repeated with varying 926 number of routes and route mixtures or with number of routes & 927 route mixtures closer to what is deployed in operational 928 networks. 930 K. When varying number of routes are used, convergence Time is 931 measured using the Loss Derived method [IGPData]. 933 L. Convergence Time in this scenario is influenced by Failure 934 detection time on Tester, BGP Keep Alive Time and routing, 935 forwarding table update time. 937 5.5. BGP Soft Reset 939 Objective: 941 This test measures the route convergence time taken by an 942 implementation to service a BGP Route Refresh message and 943 advertise a route. 945 Reference Test Setup: 947 This test uses the setup as shown in figure 2. 949 Procedure: 951 A. The BGP implementation on DUT & Helper Node needs to support 952 BGP Route Refresh Capability [RFC2918]. 954 B. All devices to be synchronized using NTP. 956 C. All variables affecting Convergence like authentication, 957 policies, timers should be set to basic-test defaults. 959 D. DUT and Helper Node are configured in the same Autonomous 960 System whereas Emulator is configured under a different 961 Autonomous System. 963 E. Establish BGP adjacency between DUT and Emulator. 965 F. Establish BGP adjacency between DUT and Helper Node. 967 G. To ensure adjacency establishment, wait for 3 KeepAlives from 968 the DUT or a configurable delay before proceeding with the 969 rest of the test. 971 H. Configure a policy under BGP on Helper Node to deny routes 972 received from DUT. 974 I. Advertise routeA from the Emulator to the DUT. 976 J. The DUT will try to advertise the route to Helper Node will be 977 denied. 979 K. Wait for 3 KeepAlives. 981 L. Start the traffic from the Emulator towards the Helper Node 982 targeted at a specific route say routeA. Initially no traffic 983 would be observed on the Egress interface, as routeA is not 984 present. 986 M. Remove the policy on Helper Node and issue a Route Refresh 987 request towards DUT. Note the timestamp of this event. This 988 is the RefreshTime. 990 N. Record the time when the traffic targeted towards routeA is 991 received on the Egress Interface. This is RecTime. 993 O. The following equation represents the Route Refresh 994 Convergence Time per route. 996 Route Refresh Convergence Time = (RecTime - RefreshTime) 998 5.6. BGP Route Withdrawal Convergence Time 1000 Objective: 1002 This test measures the route convergence time taken by an 1003 implementation to service a BGP Withdraw message and advertise the 1004 withdraw. 1006 Reference Test Setup: 1008 This test uses the setup as shown in figure 2. 1010 Procedure: 1012 A. This test consists of 2 steps to determine the Total Withdraw 1013 Processing Time. 1015 B. Step 1: 1017 (1) All devices to be synchronized using NTP. 1019 (2) All variables should be set to basic-test parameters. 1021 (3) DUT and Helper Node are configured in the same 1022 Autonomous System whereas Emulator is configured under a 1023 different Autonomous System. 1025 (4) Establish BGP adjacency between DUT and Emulator. 1027 (5) To ensure adjacency establishment, wait for 3 KeepAlives 1028 from the DUT or a configurable delay before proceeding 1029 with the rest of the test. 1031 (6) Start the traffic from the Emulator towards the DUT 1032 targeted at a specific route (e.g. route A). Initially 1033 no traffic would be observed on the Egress interface as 1034 the route A is not present on DUT. 1036 (7) Advertise route A from the Emulator to the DUT. 1038 (8) The traffic targeted towards route A is received on the 1039 Egress Interface. 1041 (9) Now the Tester sends request to withdraw route A to DUT, 1042 TRx(Awith) also called WdrawTime1(Rt-A). 1044 (10) Record the time when no traffic is observed on the 1045 Egress Interface. This is the RouteRemoveTime1(Rt-A). 1047 (11) The difference between the RouteRemoveTime1 and 1048 WdrawTime1 is the WdrawConvTime1 1050 WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - 1051 WdrawTime1(Rt-A) 1053 C. Step 2: 1055 (1) Continuing from Step 1, re-advertise route A back to DUT 1056 from Tester. 1058 (2) The DUT will try to advertise the route A to Helper Node 1059 (This assumes there exists a session between DUT and 1060 helper node). 1062 (3) Start the traffic from the Emulator towards the Helper 1063 Node targeted at a specific route (e.g. route A). 1064 Traffic would be observed on the Egress interface after 1065 route A is received by the Helper Node 1067 WATime=time traffic first flows 1069 (4) Now the Tester sends a request to withdraw route A to 1070 DUT. This is the WdrawTime2(Rt-A) 1072 WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A) 1074 (5) DUT processes the withdraw and sends it to Helper Node. 1076 (6) Record the time when no traffic is observed on the Egress 1077 Interface of Helper Node. This is 1079 TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A) 1081 (7) Total withdraw processing time is 1083 TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) - 1084 WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A)) 1086 5.7. BGP Path Attribute Change Convergence Time 1088 Objective: 1090 This test measures the convergence time taken by an implementation 1091 to service a BGP Path Attribute Change. 1093 Reference Test Setup: 1095 This test uses the setup as shown in figure 1. 1097 Procedure: 1099 A. This test only applies to Well-Known Mandatory Attributes like 1100 Origin, AS Path, Next Hop. 1102 B. In each iteration of test only one of these mandatory 1103 attributes need to be varied whereas the others remain the 1104 same. 1106 C. All devices to be synchronized using NTP. 1108 D. All variables should be set to basic-test parameters. 1110 E. Advertise the route, route A over the Best Egress Interface 1111 only, making it the preferred named Tbest. 1113 F. To ensure adjacency establishment, wait for 3 KeepAlives from 1114 the DUT or a configurable delay before proceeding with the 1115 rest of the test. 1117 G. Start the traffic from the Emulator towards the DUT targeted 1118 at the specific route (e.g. route A). Initially traffic would 1119 be observed on the Best Egress interface. 1121 H. Now advertise the same route route A on the Next-Best Egress 1122 Interface but by varying one of the well-known mandatory 1123 attributes to have a preferred value over that interface. We 1124 call this Tbetter. The other values need to be same as what 1125 was advertised on the Best-Egress adjacency 1127 TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A) 1129 I. Measure the Convergence Time for the event to be detected and 1130 traffic to be forwarded to Next-Best Egress Interface 1132 DUT(Path-Change, Rt-A) = Path-switch time(Rt-A) 1134 Convergence = Path-switch time(Rt-A) - Path Change Event 1135 Time(Rt-A) 1137 J. Stop the offered load and wait for the queues to drain and 1138 Restart. 1140 K. Repeat the test for various attributes. 1142 5.8. BGP Graceful Restart Convergence Time 1144 Objective: 1146 This test measures the route convergence time taken by an 1147 implementation during a Graceful Restart Event. 1149 Reference Test Setup: 1151 This test uses the setup as shown in figure 4. 1153 Procedure: 1155 A. It measures the time taken by an implementation to service a 1156 BGP Graceful Restart Event and advertise a route. 1158 B. The Helper Nodes are the same model as DUT and run the same 1159 BGP implementation as DUT. 1161 C. The BGP implementation on DUT & Helper Node needs to support 1162 BGP Graceful Restart Mechanism [RFC4724]. 1164 D. All devices to be synchronized using NTP. 1166 E. All variables are set to basic-test values. 1168 F. DUT and Helper Node-1(HLP1) are configured in the same 1169 Autonomous System whereas Emulator and Helper Node-2(HLP2) are 1170 configured under different Autonomous System.s 1172 G. Establish BGP adjacency between DUT and Helper Nodes. 1174 H. Establish BGP adjacency between Helper Node-2 and Emulator. 1176 I. To ensure adjacency establishment, wait for 3 KeepAlives from 1177 the DUT or a configurable delay before proceeding with the 1178 rest of the test. 1180 J. Configure a policy under BGP on Helper Node-1 to deny routes 1181 received from DUT. 1183 K. Advertise route A from the Emulator to Helper Node-2. 1185 L. Helper Node-2 advertises the route to DUT and DUT will try to 1186 advertise the route to Helper Node-1 which will be denied. 1188 M. Wait for 3 KeepAlives. 1190 N. Start the traffic from the Emulator towards the Helper Node-1 1191 targeted at the specific route (e.g. route A). Initially no 1192 traffic would be observed on the Egress interface as the route 1193 A is not present. 1195 O. Perform a Graceful Restart Trigger Event on DUT and note the 1196 time. This is the GREventTime. 1198 P. Remove the policy on Helper Node-1. 1200 Q. Record the time when the traffic targeted towards route A is 1201 received on the Egress Interface 1203 TRr(DUT, routeA). This is also called RecTime(Rt-A) 1205 R. The following equation represents the Graceful Restart 1206 Convergence Time 1208 Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - 1209 GREventTime) - RIB-IN) 1211 S. It is assumed in this test case that after a Switchover is 1212 triggered on the DUT, it will not have any cycles to process 1213 BGP Refresh messages. The reason for this assumption is that 1214 there is a narrow window of time where after switchover when 1215 we remove the policy from Helper Node -1, implementations 1216 might generate Route-Refresh automatically and this request 1217 might be serviced before the DUT actually switches over and 1218 reestablishes BGP adjacencies with the peers. 1220 6. Reporting Format 1222 For each test case, it is recommended that the reporting tables below 1223 are completed and all time values SHOULD be reported with resolution 1224 as specified in [RFC4098]. 1226 Parameter Units 1227 Test case Test case number 1228 Test topology 1,2,3 or 4 1229 Parallel links Number of parallel links 1230 Interface type GigE, POS, ATM, other 1231 Convergence Event Hard reset, Soft reset, link 1232 failure, or other defined 1233 eBGP sessions Number of eBGP sessions 1234 iBGP sessions Number of iBGP sessions 1235 eBGP neighbor Number of eBGP neighbors 1236 iBGP neighbor Number of iBGP neighbors 1237 Routes per peer Number of routes 1238 Total unique routes Number of routes 1239 Total non-unique routes Number of routes 1240 IGP configured ISIS, OSPF, static, or other 1241 Route Mixture Description of Route mixture 1242 Route Packing Number of routes in an update 1243 Policy configured Yes, No 1244 Packet size offered to the DUT Bytes 1245 Offered load Packets per second 1246 Packet sampling interval on Seconds 1247 tester 1248 Forwarding delay threshold Seconds 1249 Timer Values configured on DUT 1250 Interface failure indication Seconds 1251 delay 1252 Hold time Seconds 1253 MinRouteAdvertisementInterval Seconds 1254 (MRAI) 1255 MinASOriginationInterval Seconds 1256 (MAOI) 1257 Keepalive Time Seconds 1258 ConnectRetry Seconds 1259 TCP Parameters for DUT and tester 1260 MSS Bytes 1261 Slow start threshold Bytes 1262 Maximum window size Bytes 1264 Test Details: 1266 a. If the Offered Load matches a subset of routes, describe how this 1267 subset is selected. 1269 b. Describe how the Convergence Event is applied, does it cause 1270 instantaneous traffic loss or not. 1272 c. If there is any policy configured, describe the configured 1273 policy. 1275 Complete the table below for the initial Convergence Event and the 1276 reversion Convergence Event 1277 Parameter Unit 1278 Convergence Event Initial or reversion 1279 Traffic Forwarding Metrics 1280 Total number of packets Number of packets 1281 offered to DUT 1282 Total number of packets Number of packets 1283 forwarded by DUT 1284 Connectivity Packet Loss Number of packets 1285 Convergence Packet Loss Number of packets 1286 Out-of-order packets Number of packets 1287 Duplicate packets Number of packets 1288 Convergence Benchmarks 1289 Rate-derived Method[IGP- 1290 Data]: 1291 First route convergence Seconds 1292 time 1293 Full convergence time Seconds 1294 Loss-derived Method [IGP- 1295 Data]: 1296 Loss-derived convergence Seconds 1297 time 1298 Route-Specific Loss-Derived 1299 Method: 1300 Minimum R-S convergence Seconds 1301 time 1302 Maximum R-S convergence Seconds 1303 time 1304 Median R-S convergence Seconds 1305 time 1306 Average R-S convergence Seconds 1307 time 1309 Loss of Connectivity Benchmarks 1310 Loss-derived Method: 1311 Loss-derived loss of Seconds 1312 connectivity period 1313 Route-Specific loss-derived 1314 Method: 1315 Minimum LoC period [n] Array of seconds 1316 Minimum Route LoC period Seconds 1317 Maximum Route LoC period Seconds 1318 Median Route LoC period Seconds 1319 Average Route LoC period Seconds 1321 7. IANA Considerations 1323 This draft does not require any new allocations by IANA. 1325 8. Security Considerations 1327 Benchmarking activities as described in this memo are limited to 1328 technology characterization using controlled stimuli in a laboratory 1329 environment, with dedicated address space and the constraints 1330 specified in the sections above. 1332 The benchmarking network topology will be an independent test setup 1333 and MUST NOT be connected to devices that may forward the test 1334 traffic into a production network, or misroute traffic to the test 1335 management network. 1337 Further, benchmarking is performed on a "black-box" basis, relying 1338 solely on measurements observable external to the DUT/SUT. 1340 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 1341 benchmarking purposes. Any implications for network security arising 1342 from the DUT/SUT SHOULD be identical in the lab and in production 1343 networks. 1345 9. Acknowledgements 1347 We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay 1348 Karthik, Eric Brendel for their input and discussions on various 1349 sections in the document. We also like to acknowledge Will Liu, 1350 Semion Lisyansky, Faisal Shah for their review and feedback to the 1351 document. 1353 10. References 1355 10.1. Normative References 1357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1358 Requirement Levels", BCP 14, RFC 2119, March 1997. 1360 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 1361 September 2000. 1363 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1364 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1366 [RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology 1367 for Benchmarking Link-State IGP Data-Plane Route 1368 Convergence", RFC 6412, November 2011. 1370 10.2. Informative References 1372 [RFC1242] Bradner, S., "Benchmarking terminology for network 1373 interconnection devices", RFC 1242, July 1991. 1375 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1376 August 1996. 1378 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1379 Switching Devices", RFC 2285, February 1998. 1381 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1382 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1383 March 1999. 1385 [RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P., 1386 and M. Lepp, "Terminology for Benchmarking BGP Device 1387 Convergence in the Control Plane", RFC 4098, June 2005. 1389 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1390 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1391 January 2007. 1393 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1394 "Multiprotocol Extensions for BGP-4", RFC 4760, 1395 January 2007. 1397 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1398 Authentication Option", RFC 5925, June 2010. 1400 Authors' Addresses 1402 Rajiv Papneja 1403 Huawei Technologies 1405 Email: rajiv.papneja@huawei.com 1407 Bhavani Parise 1408 Cisco Systems 1410 Email: bhavani@cisco.com 1411 Susan Hares 1412 Adara Networks 1414 Email: shares@ndzh.com 1416 Dean Lee 1417 IXIA 1419 Email: dlee@ixiacom.com 1421 Ilya Varlashkin 1422 Easynet Global Services 1424 Email: ilya.varlashkin@easynet.com