idnits 2.17.1 draft-ietf-bmwg-bgp-basic-convergence-00.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 (July 2013) is 3935 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 924, but not defined == Unused Reference: 'I-D.ietf-bmwg-igp-dataplane-conv-term' is defined on line 1348, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-term (ref. 'I-D.ietf-bmwg-igp-dataplane-conv-term') 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: January 2, 2014 Cisco Systems 6 S. Hares 7 Adara Networks 8 D. Lee 9 IXIA 10 I. Varlashkin 11 Easynet Global Services 12 July 2013 14 Basic BGP Convergence Benchmarking Methodology for Data Plane 15 Convergence 16 draft-ietf-bmwg-bgp-basic-convergence-00.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 January 2, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . 12 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. Furthermore the traffic generation and routing should be verified 499 in the topology 501 5.1. Basic Convergence Tests 503 These test cases measure characteristics of a BGP implementation in 504 non-failure scenarios like: 506 1. RIB-IN Convergence 508 2. RIB-OUT Convergence 510 3. eBGP Convergence 512 4. iBGP Convergence 514 5.1.1. RIB-IN Convergence 516 Objective: 518 This test measures the convergence time taken to receive and 519 install a route in RIB using BGP. 521 Reference Test Setup: 523 This test uses the setup as shown in figure 1 525 Procedure: 527 A. All variables affecting Convergence should be set to a basic 528 test state (as defined in section 4-4). 530 B. Establish BGP adjacency between DUT and peer x of Emulator. 532 C. To ensure adjacency establishment, wait for 3 KeepAlives from 533 the DUT or a configurable delay before proceeding with the 534 rest of the test. 536 D. Start the traffic from the Emulator peer-x towards the DUT 537 targeted at a routes specified in route mixture (ex. route A) 538 Initially no traffic SHOULD be observed on the egress 539 interface as the route A is not installed in the forwarding 540 database of the DUT. 542 E. Advertise route A from the Peer-x to the DUT and record the 543 time. 545 This is Tup(EMx,Rt-A) also named 'XMT-Rt-time(Rt-A)'. 547 F. Record the time when the route A from Peer-x is received at 548 the DUT. 550 This Tup(DUT,Rt-A) also named 'RCV-Rt-time(Rt-A)'. 552 G. Record the time when the traffic targeted towards route A is 553 received by Emulator on appropriate traffic egress interface. 555 This is TR(TDr,Rt-A). This is also named DUT-XMT-Data- 556 Time(Rt-A). 558 H. The difference between the Tup(DUT,RT-A) and traffic received 559 time (TR (TDr, Rt-A) is the FIB Convergence Time for route A 560 in the route mixture. A full convergence for the route update 561 is the measurement between the 1st route (Rt-A) and the last 562 route (Rt-last) 564 Route update convergence is 566 TR(TDr, Rt-last)- Tup(DUT, Rt-A) or 568 (DUT-XMT-Data-Time - RCV-Rt-Time)(Rt-A) 570 Note: It is recommended that a single test with the same route 571 mixture be repeated several times. A report should provide the Stand 572 Deviation of all tests and the Average. 574 Running tests with a varying number of routes and route mixtures is 575 important to get a full characterization of a single peer. 577 5.1.2. RIB-OUT Convergence 579 Objective: 581 This test measures the convergence time taken by an implementation 582 to receive, install and advertise a route using BGP. 584 Reference Test Setup: 586 This test uses the setup as shown in figure 2. 588 Procedure: 590 A. The Helper node (HLP) run same version of BGP as DUT. 592 B. All devices MUST be synchronized using NTP or some local 593 reference clock. 595 C. All configuration variables for HLP, DUT and Emulator SHOULD 596 be set to the same values. These values MAY be basic-test or 597 a unique set completely described in the test set-up. 599 D. Establish BGP adjacency between DUT and Emulator. 601 E. Establish BGP adjacency between DUT and Helper Node. 603 F. To ensure adjacency establishment, wait for 3 KeepAlives from 604 the DUT or a configurable delay before proceeding with the 605 rest of the test. 607 G. Start the traffic from the Emulator towards the Helper Node 608 targeted at a specific route (e.g. route A). Initially no 609 traffic SHOULD be observed on the egress interface as the 610 route A is not installed in the forwarding database of the 611 DUT. 613 H. Advertise route A from the Emulator to the DUT and note the 614 time. 616 This is Tup(EMx, Rt-A), also named EM-XMT-Data-Time(Rt-A) 618 I. Record when route A is received by DUT. 620 This is Tup(DUTr, Rt-A), also named DUT-RCV-Rt-Time(Rt-A) 622 J. Record the time when the route A is forwarded by DUT towards 623 the Helper node. 625 This is Tup(DUTx, Rt-A), also named DUT-XMT-Rt-Time(Rt-A) 627 K. Record the time when the traffic targeted towards route A is 628 received on the Route Egress Interface. This is TR(EMr, 629 Rt-A), also named DUT-XMT-Data Time(Rt-A). 631 FIB convergence = (DUT-RCV-Rt-Time - 632 DUT-XMT-Data-Time)(Rt-A) 634 RIB convergence = (DUT-RCV-Rt-Time - DUT-XMT-Rt-Time)(Rt-A) 636 Convergence for a route stream is characterized by 637 a) Individual route convergence for FIB, RIB 639 b) All route convergence of 641 FIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Data- 642 Time(last) 644 RIB-convergence =DUT-RCV-Rt-Time(first)-DUT-XMT-Rt- 645 Time(last) 647 5.1.3. eBGP Convergence 649 Objective: 651 This test measures the convergence time taken by an implementation 652 to receive, install and advertise a route in an eBGP Scenario. 654 Reference Test Setup: 656 This test uses the setup as shown in figure 2 and the scenarios 657 described in RIB-IN and RIB-OUT are applicable to this test case. 659 5.1.4. iBGP Convergence 661 Objective: 663 This test measures the convergence time taken by an implementation 664 to receive, install and advertise a route in an iBGP Scenario. 666 Reference Test Setup: 668 This test uses the setup as shown in figure 2 and the scenarios 669 described in RIB-IN and RIB-OUT are applicable to this test case. 671 5.1.5. eBGP Multihop Convergence 673 Objective: 675 This test measures the convergence time taken by an implementation 676 to receive, install and advertise a route in an eBGP Multihop 677 Scenario. 679 Reference Test Setup: 681 This test uses the setup as shown in figure 3. DUT is used along 682 with a helper node. 684 Procedure: 686 A. The Helper Node (HLP) runs the same BGP version as DUT. 688 B. All devices to be synchronized using NTP. 690 C. All variables affecting Convergence like authentication, 691 policies, timers should be set to basic-settings 693 D. All 3 devices, DUT, Emulator and Helper Node are configured 694 with different Autonomous Systems. 696 E. Loopback Interfaces are configured on DUT and Helper Node and 697 connectivity is established between them using any config 698 options available on the DUT. 700 F. Establish BGP adjacency between DUT and Emulator. 702 G. Establish BGP adjacency between DUT and Helper Node. 704 H. To ensure adjacency establishment, wait for 3 KeepAlives from 705 the DUT or a configurable delay before proceeding with the 706 rest of the tes.t 708 I. Start the traffic from the Emulator towards the DUT targeted 709 at a specific route (e.g. route A). 711 J. Initially no traffic SHOULD be observed on the egress 712 interface as the route A is not installed in the forwarding 713 database of the DUT. 715 K. Advertise route A from the Emulator to the DUT and note the 716 time (Tup(EMx,RouteA) also named Route-Tx-time(Rt-A). 718 L. Record the time when the route is received by the DUT. This 719 is Tup(EMr,DUT) named Route-Rcv-time(Rt-A). 721 M. Record the time when the traffic targeted towards route A is 722 received from Egress Interface of DUT on emulator. This is 723 Tup(EMd,DUT) named Data-Rcv-time(Rt-A) 725 N. Record the time when the route A is forwarded by DUT towards 726 the Helper node. This is Tup(EMf,DUT) also named Route-Fwd- 727 time(Rt-A) 729 FIB Convergence = (Data-Rcv-time - Route-Rcv-time)(Rt-A) 730 RIB Convergence = (Route-Fwd-time - Route-Rcv-time)(Rt-A) 732 Note: It is recommended that the test be repeated with varying number 733 of routes and route mixtures. With each set route mixture, the test 734 should be repeated multiple times. The results should record 735 average, mean, Standard Deviation 737 5.2. BGP Failure/Convergence Events 739 5.2.1. Physical Link Failure on DUT End 741 Objective: 743 This test measures the route convergence time due to local link 744 failure event at DUT's Local Interface. 746 Reference Test Setup: 748 This test uses the setup as shown in figure 1. Shutdown event is 749 defined as an administrative shutdown event on the DUT. 751 Procedure: 753 A. All variables affecting Convergence like authentication, 754 policies, timers should be set to basic-test policy. 756 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 757 peer interface and the other using a second peer interface. 759 C. Advertise the same route, route A over both the adjacencies 760 and (Tx1)Interface to be the preferred next hop. 762 D. To ensure adjacency establishment, wait for 3 KeepAlives from 763 the DUT or a configurable delay before proceeding with the 764 rest of the test. 766 E. Start the traffic from the Emulator towards the DUT targeted 767 at a specific route (e.g. route A). Initially traffic would 768 be observed on the best egress route (Emp1) instead of Trr2. 770 F. Trigger the shutdown event of Best Egress Interface on DUT 771 (Drr1). 773 G. Measure the Convergence Time for the event to be detected and 774 traffic to be forwarded to Next-Best Egress Interface (rr2) 775 Time = Data-detect(rr2) - Shutdown time 777 H. Stop the offered load and wait for the queues to drain and 778 Restart. 780 I. Bring up the link on DUT Best Egress Interface. 782 J. Measure the convergence time taken for the traffic to be 783 rerouted from (rr2) to Best Interface (rr1) 785 Time = Data-detect(rr1) - Bring Up time 787 K. It is recommended that the test be repeated with varying 788 number of routes and route mixtures or with number of routes & 789 route mixtures closer to what is deployed in operational 790 networks. 792 5.2.2. Physical Link Failure on Remote/Emulator End 794 Objective: 796 This test measures the route convergence time due to local link 797 failure event at Tester's Local Interface. 799 Reference Test Setup: 801 This test uses the setup as shown in figure 1. Shutdown event is 802 defined as shutdown of the local interface of Tester via logical 803 shutdown event. The procedure used in 5.2.1 is used for the 804 termination. 806 5.2.3. ECMP Link Failure on DUT End 808 Objective: 810 This test measures the route convergence time due to local link 811 failure event at ECMP Member. The FIB configuration and BGP is 812 set to allow two ECMP routes to be installed. However, policy 813 directs the routes to be sent only over one of the paths 815 Reference Test Setup: 817 This test uses the setup as shown in figure 1 and the procedure 818 uses 5.2.1. 820 5.3. BGP Adjacency Failure (Non-Physical Link Failure) on Emulator 822 Objective: 824 This test measures the route convergence time due to BGP Adjacency 825 Failure on Emulator. 827 Reference Test Setup: 829 This test uses the setup as shown in figure 1. 831 Procedure: 833 A. All variables affecting Convergence like authentication, 834 policies, timers should be basic-policy set. 836 B. Establish 2 BGP adjacencies from DUT to Emulator, one over the 837 Best Egress Interface and the other using the Next-Best Egress 838 Interface. 840 C. Advertise the same route, routeA over both the adjacencies and 841 make Best Egress Interface to be the preferred next hop 843 D. To ensure adjacency establishment, wait for 3 KeepAlives from 844 the DUT or a configurable delay before proceeding with the 845 rest of the test. 847 E. Start the traffic from the Emulator towards the DUT targeted 848 at a specific route say routeA. Initially traffic would be 849 observed on the Best Egress interface. 851 F. Remove BGP adjacency via a software adjacency down on the 852 Emulator on the Best Egress Interface. This time is called 853 BGPadj-down-time also termed BGPpeer-down 855 G. Measure the Convergence Time for the event to be detected and 856 traffic to be forwarded to Next-Best Egress Interface. This 857 time is Tr-rr2 also called TR2-traffic-on 859 Convergence = TR2-traffic-on - BGPpeer-down 861 H. Stop the offered load and wait for the queues to drain and 862 Restart. 864 I. Bring up BGP adjacency on the Emulator over the Best Egress 865 Interface. This time is BGP-adj-up also called BGPpeer-up 867 J. Measure the convergence time taken for the traffic to be 868 rerouted to Best Interface. This time is BGP-adj-up also 869 called BGPpeer-up 871 5.4. BGP Hard Reset Test Cases 873 5.4.1. BGP Non-Recovering Hard Reset Event on DUT 875 Objective: 877 This test measures the route convergence time due to Hard Reset on 878 the DUT. 880 Reference Test Setup: 882 This test uses the setup as shown in figure 1. 884 Procedure: 886 A. The requirement for this test case is that the Hard Reset 887 Event should be non-recovering and should affect only the 888 adjacency between DUT and Emulator on the Best Egress 889 Interface. 891 B. All variables affecting SHOULD be set to basic-test values. 893 C. Establish 2 BGP adjacencies from DUT to Emulator, one over the 894 Best Egress Interface and the other using the Next-Best Egress 895 Interface. 897 D. Advertise the same route, routeA over both the adjacencies and 898 make Best Egress Interface to be the preferred next hop. 900 E. To ensure adjacency establishment, wait for 3 KeepAlives from 901 the DUT or a configurable delay before proceeding with the 902 rest of the test. 904 F. Start the traffic from the Emulator towards the DUT targeted 905 at a specific route (e.g route A). Initially traffic would be 906 observed on the Best Egress interface. 908 G. Trigger the Hard Reset event of Best Egress Interface on DUT. 910 H. Measure the Convergence Time for the event to be detected and 911 traffic to be forwarded to Next-Best Egress Interface. 913 Time of convergence = time-traffic flow - time-reset 915 I. Stop the offered load and wait for the queues to drain and 916 Restart. 918 J. It is recommended that the test be repeated with varying 919 number of routes and route mixtures or with number of routes & 920 route mixtures closer to what is deployed in operational 921 networks. 923 K. When varying number of routes are used, convergence Time is 924 measured using the Loss Derived method [IGPData]. 926 L. Convergence Time in this scenario is influenced by Failure 927 detection time on Tester, BGP Keep Alive Time and routing, 928 forwarding table update time. 930 5.5. BGP Soft Reset 932 Objective: 934 This test measures the route convergence time taken by an 935 implementation to service a BGP Route Refresh message and 936 advertise a route. 938 Reference Test Setup: 940 This test uses the setup as shown in figure 2. 942 Procedure: 944 A. The BGP implementation on DUT & Helper Node needs to support 945 BGP Route Refresh Capability [RFC2918]. 947 B. All devices to be synchronized using NTP. 949 C. All variables affecting Convergence like authentication, 950 policies, timers should be set to basic-test defaults. 952 D. DUT and Helper Node are configured in the same Autonomous 953 System whereas Emulator is configured under a different 954 Autonomous System. 956 E. Establish BGP adjacency between DUT and Emulator. 958 F. Establish BGP adjacency between DUT and Helper Node. 960 G. To ensure adjacency establishment, wait for 3 KeepAlives from 961 the DUT or a configurable delay before proceeding with the 962 rest of the test. 964 H. Configure a policy under BGP on Helper Node to deny routes 965 received from DUT. 967 I. Advertise routeA from the Emulator to the DUT. 969 J. The DUT will try to advertise the route to Helper Node will be 970 denied. 972 K. Wait for 3 KeepAlives. 974 L. Start the traffic from the Emulator towards the Helper Node 975 targeted at a specific route say routeA. Initially no traffic 976 would be observed on the Egress interface, as routeA is not 977 present. 979 M. Remove the policy on Helper Node and issue a Route Refresh 980 request towards DUT. Note the timestamp of this event. This 981 is the RefreshTime. 983 N. Record the time when the traffic targeted towards routeA is 984 received on the Egress Interface. This is RecTime. 986 O. The following equation represents the Route Refresh 987 Convergence Time per route. 989 Route Refresh Convergence Time = (RecTime - RefreshTime) 991 5.6. BGP Route Withdrawal Convergence Time 993 Objective: 995 This test measures the route convergence time taken by an 996 implementation to service a BGP Withdraw message and advertise the 997 withdraw. 999 Reference Test Setup: 1001 This test uses the setup as shown in figure 2. 1003 Procedure: 1005 A. This test consists of 2 steps to determine the Total Withdraw 1006 Processing Time. 1008 B. Step 1: 1010 (1) All devices to be synchronized using NTP. 1012 (2) All variables should be set to basic-test parameters. 1014 (3) DUT and Helper Node are configured in the same 1015 Autonomous System whereas Emulator is configured under a 1016 different Autonomous System. 1018 (4) Establish BGP adjacency between DUT and Emulator. 1020 (5) To ensure adjacency establishment, wait for 3 KeepAlives 1021 from the DUT or a configurable delay before proceeding 1022 with the rest of the test. 1024 (6) Start the traffic from the Emulator towards the DUT 1025 targeted at a specific route (e.g. route A). Initially 1026 no traffic would be observed on the Egress interface as 1027 the route A is not present on DUT. 1029 (7) Advertise route A from the Emulator to the DUT. 1031 (8) The traffic targeted towards route A is received on the 1032 Egress Interface. 1034 (9) Now the Tester sends request to withdraw route A to DUT, 1035 TRx(Awith) also called WdrawTime1(Rt-A). 1037 (10) Record the time when no traffic is observed on the 1038 Egress Interface. This is the RouteRemoveTime1(Rt-A). 1040 (11) The difference between the RouteRemoveTime1 and 1041 WdrawTime1 is the WdrawConvTime1 1043 WdrawConvTime1(Rt-A) = RouteRemoveTime1(Rt-A) - 1044 WdrawTime1(Rt-A) 1046 C. Step 2: 1048 (1) Continuing from Step 1, re-advertise route A back to DUT 1049 from Tester. 1051 (2) The DUT will try to advertise the route A to Helper Node 1052 (This assumes there exists a session between DUT and 1053 helper node). 1055 (3) Start the traffic from the Emulator towards the Helper 1056 Node targeted at a specific route (e.g. route A). 1057 Traffic would be observed on the Egress interface after 1058 route A is received by the Helper Node 1060 WATime=time traffic first flows 1062 (4) Now the Tester sends a request to withdraw route A to 1063 DUT. This is the WdrawTime2(Rt-A) 1065 WAWtime-TRx(Rt-A) = WdrawTime2(Rt-A) 1067 (5) DUT processes the withdraw and sends it to Helper Node. 1069 (6) Record the time when no traffic is observed on the Egress 1070 Interface of Helper Node. This is 1072 TR-WAW(DUT,RouteA) = RouteRemoveTime2(Rt-A) 1074 (7) Total withdraw processing time is 1076 TotalWdrawTime(Rt-A) = ((RouteRemoveTime2(Rt-A) - 1077 WdrawTime2(Rt-A)) - WdrawConvTime1(Rt-A)) 1079 5.7. BGP Path Attribute Change Convergence Time 1081 Objective: 1083 This test measures the convergence time taken by an implementation 1084 to service a BGP Path Attribute Change. 1086 Reference Test Setup: 1088 This test uses the setup as shown in figure 1. 1090 Procedure: 1092 A. This test only applies to Well-Known Mandatory Attributes like 1093 Origin, AS Path, Next Hop. 1095 B. In each iteration of test only one of these mandatory 1096 attributes need to be varied whereas the others remain the 1097 same. 1099 C. All devices to be synchronized using NTP. 1101 D. All variables should be set to basic-test parameters. 1103 E. Advertise the route, route A over the Best Egress Interface 1104 only, making it the preferred named Tbest. 1106 F. To ensure adjacency establishment, wait for 3 KeepAlives from 1107 the DUT or a configurable delay before proceeding with the 1108 rest of the test. 1110 G. Start the traffic from the Emulator towards the DUT targeted 1111 at the specific route (e.g. route A). Initially traffic would 1112 be observed on the Best Egress interface. 1114 H. Now advertise the same route route A on the Next-Best Egress 1115 Interface but by varying one of the well-known mandatory 1116 attributes to have a preferred value over that interface. We 1117 call this Tbetter. The other values need to be same as what 1118 was advertised on the Best-Egress adjacency 1120 TRx(Path-Change(Rt-A)) = Path Change Event Time(Rt-A) 1122 I. Measure the Convergence Time for the event to be detected and 1123 traffic to be forwarded to Next-Best Egress Interface 1125 DUT(Path-Change, Rt-A) = Path-switch time(Rt-A) 1127 Convergence = Path-switch time(Rt-A) - Path Change Event 1128 Time(Rt-A) 1130 J. Stop the offered load and wait for the queues to drain and 1131 Restart. 1133 K. Repeat the test for various attributes. 1135 5.8. BGP Graceful Restart Convergence Time 1137 Objective: 1139 This test measures the route convergence time taken by an 1140 implementation during a Graceful Restart Event. 1142 Reference Test Setup: 1144 This test uses the setup as shown in figure 4. 1146 Procedure: 1148 A. It measures the time taken by an implementation to service a 1149 BGP Graceful Restart Event and advertise a route. 1151 B. The Helper Nodes are the same model as DUT and run the same 1152 BGP implementation as DUT. 1154 C. The BGP implementation on DUT & Helper Node needs to support 1155 BGP Graceful Restart Mechanism [RFC4724]. 1157 D. All devices to be synchronized using NTP. 1159 E. All variables are set to basic-test values. 1161 F. DUT and Helper Node-1(HLP1) are configured in the same 1162 Autonomous System whereas Emulator and Helper Node-2(HLP2) are 1163 configured under different Autonomous System.s 1165 G. Establish BGP adjacency between DUT and Helper Nodes. 1167 H. Establish BGP adjacency between Helper Node-2 and Emulator. 1169 I. To ensure adjacency establishment, wait for 3 KeepAlives from 1170 the DUT or a configurable delay before proceeding with the 1171 rest of the test. 1173 J. Configure a policy under BGP on Helper Node-1 to deny routes 1174 received from DUT. 1176 K. Advertise route A from the Emulator to Helper Node-2. 1178 L. Helper Node-2 advertises the route to DUT and DUT will try to 1179 advertise the route to Helper Node-1 which will be denied. 1181 M. Wait for 3 KeepAlives. 1183 N. Start the traffic from the Emulator towards the Helper Node-1 1184 targeted at the specific route (e.g. route A). Initially no 1185 traffic would be observed on the Egress interface as the route 1186 A is not present. 1188 O. Perform a Graceful Restart Trigger Event on DUT and note the 1189 time. This is the GREventTime. 1191 P. Remove the policy on Helper Node-1. 1193 Q. Record the time when the traffic targeted towards route A is 1194 received on the Egress Interface 1196 TRr(DUT, routeA). This is also called RecTime(Rt-A) 1198 R. The following equation represents the Graceful Restart 1199 Convergence Time 1201 Graceful Restart Convergence Time(Rt-A) = ((RecTime(Rt-A) - 1202 GREventTime) - RIB-IN) 1204 S. It is assumed in this test case that after a Switchover is 1205 triggered on the DUT, it will not have any cycles to process 1206 BGP Refresh messages. The reason for this assumption is that 1207 there is a narrow window of time where after switchover when 1208 we remove the policy from Helper Node -1, implementations 1209 might generate Route-Refresh automatically and this request 1210 might be serviced before the DUT actually switches over and 1211 reestablishes BGP adjacencies with the peers. 1213 6. Reporting Format 1215 For each test case, it is recommended that the reporting tables below 1216 are completed and all time values SHOULD be reported with resolution 1217 as specified in [RFC4098]. 1219 Parameter Units 1220 Test case Test case number 1221 Test topology 1,2,3 or 4 1222 Parallel links Number of parallel links 1223 Interface type GigE, POS, ATM, other 1224 Convergence Event Hard reset, Soft reset, link 1225 failure, or other defined 1226 eBGP sessions Number of eBGP sessions 1227 iBGP sessions Number of iBGP sessions 1228 eBGP neighbor Number of eBGP neighbors 1229 iBGP neighbor Number of iBGP neighbors 1230 Routes per peer Number of routes 1231 Total unique routes Number of routes 1232 Total non-unique routes Number of routes 1233 IGP configured ISIS, OSPF, static, or other 1234 Route Mixture Description of Route mixture 1235 Route Packing Number of routes in an update 1236 Policy configured Yes, No 1237 Packet size offered to the DUT Bytes 1238 Offered load Packets per second 1239 Packet sampling interval on Seconds 1240 tester 1241 Forwarding delay threshold Seconds 1242 Timer Values configured on DUT 1243 Interface failure indication Seconds 1244 delay 1245 Hold time Seconds 1246 MinRouteAdvertisementInterval Seconds 1247 (MRAI) 1248 MinASOriginationInterval Seconds 1249 (MAOI) 1250 Keepalive Time Seconds 1251 ConnectRetry Seconds 1252 TCP Parameters for DUT and tester 1253 MSS Bytes 1254 Slow start threshold Bytes 1255 Maximum window size Bytes 1257 Test Details: 1259 a. If the Offered Load matches a subset of routes, describe how this 1260 subset is selected. 1262 b. Describe how the Convergence Event is applied, does it cause 1263 instantaneous traffic loss or not. 1265 c. If there is any policy configured, describe the configured 1266 policy. 1268 Complete the table below for the initial Convergence Event and the 1269 reversion Convergence Event 1270 Parameter Unit 1271 Convergence Event Initial or reversion 1272 Traffic Forwarding Metrics 1273 Total number of packets Number of packets 1274 offered to DUT 1275 Total number of packets Number of packets 1276 forwarded by DUT 1277 Connectivity Packet Loss Number of packets 1278 Convergence Packet Loss Number of packets 1279 Out-of-order packets Number of packets 1280 Duplicate packets Number of packets 1281 Convergence Benchmarks 1282 Rate-derived Method[IGP- 1283 Data]: 1284 First route convergence Seconds 1285 time 1286 Full convergence time Seconds 1287 Loss-derived Method [IGP- 1288 Data]: 1289 Loss-derived convergence Seconds 1290 time 1291 Route-Specific Loss-Derived 1292 Method: 1293 Minimum R-S convergence Seconds 1294 time 1295 Maximum R-S convergence Seconds 1296 time 1297 Median R-S convergence Seconds 1298 time 1299 Average R-S convergence Seconds 1300 time 1302 Loss of Connectivity Benchmarks 1303 Loss-derived Method: 1304 Loss-derived loss of Seconds 1305 connectivity period 1306 Route-Specific loss-derived 1307 Method: 1308 Minimum LoC period [n] Array of seconds 1309 Minimum Route LoC period Seconds 1310 Maximum Route LoC period Seconds 1311 Median Route LoC period Seconds 1312 Average Route LoC period Seconds 1314 7. IANA Considerations 1316 This draft does not require any new allocations by IANA. 1318 8. Security Considerations 1320 Benchmarking activities as described in this memo are limited to 1321 technology characterization using controlled stimuli in a laboratory 1322 environment, with dedicated address space and the constraints 1323 specified in the sections above. 1325 The benchmarking network topology will be an independent test setup 1326 and MUST NOT be connected to devices that may forward the test 1327 traffic into a production network, or misroute traffic to the test 1328 management network. 1330 Further, benchmarking is performed on a "black-box" basis, relying 1331 solely on measurements observable external to the DUT/SUT. 1333 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 1334 benchmarking purposes. Any implications for network security arising 1335 from the DUT/SUT SHOULD be identical in the lab and in production 1336 networks. 1338 9. Acknowledgements 1340 We would like to thank Anil Tandon, Arvind Pandey, Mohan Nanduri, Jay 1341 Karthik and Eric Brendel, for their input and discussions on various 1342 sections in the document. 1344 10. References 1346 10.1. Normative References 1348 [I-D.ietf-bmwg-igp-dataplane-conv-term] 1349 Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology 1350 for Benchmarking Link-State IGP Data Plane Route 1351 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-23 1352 (work in progress), February 2011. 1354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1355 Requirement Levels", BCP 14, RFC 2119, March 1997. 1357 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 1358 September 2000. 1360 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1361 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1363 10.2. Informative References 1365 [RFC1242] Bradner, S., "Benchmarking terminology for network 1366 interconnection devices", RFC 1242, July 1991. 1368 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1369 August 1996. 1371 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1372 Switching Devices", RFC 2285, February 1998. 1374 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1375 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1376 March 1999. 1378 [RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P., 1379 and M. Lepp, "Terminology for Benchmarking BGP Device 1380 Convergence in the Control Plane", RFC 4098, June 2005. 1382 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1383 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1384 January 2007. 1386 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1387 "Multiprotocol Extensions for BGP-4", RFC 4760, 1388 January 2007. 1390 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1391 Authentication Option", RFC 5925, June 2010. 1393 Authors' Addresses 1395 Rajiv Papneja 1396 Huawei Technologies 1398 Email: rajiv.papneja@huawei.com 1400 Bhavani Parise 1401 Cisco Systems 1403 Email: bhavani@cisco.com 1404 Susan Hares 1405 Adara Networks 1407 Email: shares@ndzh.com 1409 Dean Lee 1410 IXIA 1412 Email: dlee@ixiacom.com 1414 Ilya Varlashkin 1415 Easynet Global Services 1417 Email: ilya.varlashkin@easynet.com