idnits 2.17.1 draft-ietf-bmwg-bgpbas-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 538 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 30 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 71 has weird spacing: '...er edge route...' == Line 72 has weird spacing: '...er edge route...' == Line 95 has weird spacing: '...ls will be co...' == Line 127 has weird spacing: '...jective was...' == Line 128 has weird spacing: '...esented in dr...' == (6 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2001) is 8349 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) -- Looks like a reference, but probably isn't: '1' on line 16 == Missing Reference: 'RFC-2119' is mentioned on line 44, but not defined -- Looks like a reference, but probably isn't: '2' on line 44 == Missing Reference: 'RPSL' is mentioned on line 205, but not defined == Unused Reference: 'RFC 2119' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC 2539' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'RFC 2622' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC 2827' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC 2928' is defined on line 416, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Downref: Normative reference to an Informational RFC: RFC 2928 == Outdated reference: A later version (-04) exists of draft-ietf-bmwg-fib-term-00 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-fib-term (ref. 'Trotter') Summary: 9 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H.Berkowitz 3 Internet Draft A.Retana 4 Expires Febuaary 2002 S.Hares 5 draft-ietf-bmwg-bgpbas-00.txt P.Krishnaswamy 6 M. Lepp 8 June 2001 10 Benchmarking Methodology for Basic BGP Convergence 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026[1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or made obsolete by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 35 This draft establishes standards for measuring BGP convergence 36 performance. Its initial emphasis is on the control plane of single 37 BGP routers. We do not address forwarding plane performance. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC-2119]. [2]. 45 Table of Contents 46 1 1. Introduction 2 47 1.1 Overview and Roadmap 2 48 1.2 Scope 3 49 1.3. Types of Single-Router Convergence 3 50 2. Reference Configurations 4 51 3. Basic eBGP tests 4 52 3.1 Connection Conditions 5 53 3.2 Test Streams 5 54 3.3 Order of Received Updates 5 55 3.4 Initial Convergence 6 56 3.4.1 Single Peer Initial Convergence Time 6 57 3.4.2 Multiple Peers 7 58 3.5 Incremental Re-convergence with a Single Peer 7 59 3.5.1 Explicit add of single new route 7 60 3.5.2 Sequential withdraw and reannounce 7 61 3.5.3 Time to Change to Alternate Path after Explicit Withdrawal 7 62 3.6 Incremental Re-convergence with Multiple Peers 8 63 4. Flaps 8 64 4.1 Flap Isolation Test 8 65 4.2 Authentication 8 66 5. Acknowledgements 8 67 6. References 8 68 Appendix A. Representative Scenarios 10 69 A.1 Default-free interprovider peering 10 70 A.2 Interprovider peering with transit 10 71 A.3 Provider edge router 10 72 A.4 Multihomed subscriber edge router 10 74 1. Introduction 75 This document describes a specific set of tests aimed at 76 characterizing the convergence performance of BGP-4 processes in 77 routers or other boxes that incorporate BGP functionality. A key 78 objective is to propose methodology that will standardize the 79 conducting and reporting of convergence-related measurements. 81 Although both convergence and forwarding are 82 essential to basic router operation, this document does not consider 83 the forwarding performance in the Device Under Test (DUT),for two 84 reasons. Forwarding performance is the primary focus in [RFC 2544] and 85 it is expected to be dealt with in work that ensues from [Trotter]. 87 Further, as convergence characterization is a complex process, we 88 deliberately restrict this document basic measurements towards 89 characterizing BGP convergence. 91 Subsequent documents will explore the more intricate aspects of 92 convergence measurement, such as the presence of policy processing, 93 simultaneous traffic on the control and data paths within the DUT, 94 and other realistic performance modifiers. Convergence of 95 Interior Gateway Protocols will be considered in separate 96 drafts. 98 1.1 Overview and Roadmap 100 Measurements of protocols can be classified either as internal or 101 external. Internal measurements are time-stamped within the Device 102 Under Test (DUT). External measurements infer the timing of a process 103 in the DUT to have converged after a downstream measurement device 104 indicates the corresponding advertisement has been received. An 105 alternative type of external measurement is to test for data forwarded 106 to the downstream device that relies upon the new route just computed by 107 the Device Under Test. 109 Internal measurements are plagued with time synchronization issues, 110 since the Network Time Protocol (NTP) hooks may be missing from products 111 or improperly implemented. Of course in a self-contained lab setting or 112 the self-contained measurement of internal processes themselves, 113 synchronized timing is not an issue. 115 For the purposes of this paper, external technique are more readily 116 applicable. However, external measurements have their own problems 117 because they include the time to advertise the new route downstream and 118 transmission times for the advertisement within the device under test. 119 If data forwarding were to feature in the measurement methodology it too 120 would include some extraneous latency- that of the forwarding lookup 121 process in the DUT at the minimum. This document deals only with 122 external measurements limited to route propagation. 124 A characterization of the BGP convergence performance of a device 125 must take into account all distinct stages and aspects of BGP 126 functionality. This requires that the relevant terms and metrics be as 127 specific as possible. A terminology that meets this objective was 128 presented in draft-ietf-bmwg-conterm-00.txt 130 1.2 Scope 132 This document deals with eBGP convergence of a single router Device 133 Under Test (DUT). It restricts the measurement of convergence to events 134 in the control plane, and does not consider the interactions of 135 convergence and forwarding. 137 Convergence measurements among multiple iBGP-connected routers in an AS, 138 and Internet-wide convergence measurements, are outside the scope of 139 this document as well. 141 These additional topics are unquestionably of interest, and it is the 142 intention of this document to form a stepping stone toward them 144 1.3. Types of Single-Router Convergence 146 Two significantly different types of convergence time tend to be lumped 147 together in product specifications. The first is the time needed for a 148 BGP speaker to build a full table after initialization, or for a 149 particular peering session to rebuild its table after a hard reset. The 150 second is the time needed for a router to respond to a new announcement 151 or withdrawal. 153 As stated in the Roadmap, measurements can be defined either as internal 154 or external. Internal measurements examine the RIB/FIB of the DUT 155 directly. While they are more accurate in principle, they require 156 measurement hooks in the implementation, as described in [Ahuja et al]. 158 External measurements start with a stimulus from one or more "upstream" 159 routers and end with a specific event causing an advertisement to be 160 sent to a "downstream" peer. In the reference configuration above, 161 external measurements are defined with respect to TR3 as the downstream 162 router. 164 2. Reference Configurations 166 For tests when the number of peers is not a performance parameter of 167 interest, use the configuration in Figure 1: 169 TR1==========+---------+==========TR3 170 | | | 171 D1 | | 172 | | DUT | 173 TR2==========| | 174 +---------+ 175 Figure 1. Basic Test Configuration. 177 D1 is a prefix reachable by both TR1 and TR2. Neither TR1 or TR2 is the 178 originating AS for the announcement of D1. 180 More complex peering arrangements will involve up to n Test Routers, as 181 shown in Figure 2. It is recommended that the Figure 1 configuration 182 always be tested as a baseline, and then additional reports made that 183 show the effect on performance of increasing the number of peers. 185 TR1==========+---------+==========TR3 186 | | | 187 D1 | | 188 | | DUT | 189 TR2==========| | 190 | | 191 ... 192 TRn==========+---------+ 193 Figure 2. Test Configuration with n Peers. 195 Interface speeds must be specified as part of the test report. At 196 least 100 Mbps is recommended, so media delays are not a significant 197 component of convergence times. 199 In the absence of other route selection criteria, TR1 shall have an IP 200 address that makes it most preferred. 202 3. Basic eBGP tests 204 All routers in this configuration shall have a policy of ADVERTISE 205 ALL/ACCEPT ALL [RPSL]. Tests with prefix filtering, community-based 206 preferences, authentication, etc., as well as performance under flap are 207 TBD. 209 Not all eBGP applications are alike. While the tests in this section 210 are applicable to a wide range of configurations, testers may select 211 configurations that are most relevant to the intended product use. Such 212 configurations include: 214 1. Interprovider peering, characterized by an exchange of customer 215 routes,which, in the case of major providers, may be in the tens of 216 thousands of routes but smaller than the full default-free table. 218 2. Provider/Subscriber edge peering, where transit service implies 219 the subscriber advertises relatively few routes to the provider but may 220 take, variously, full default-free routes, a limited subset therein, or 221 default only from the provider. 223 3.1 Connection Conditions 225 The DUT should be physically connected to the test routers over a medium 226 sufficiently fast that propagation time is not a significant factor. A 227 medium of at least 100 Mbps is recommended. 229 Multiple peers may be connected to a single physical interface using 230 802.1q VLANs or another appropriate multiplexing scheme. 232 TCP connections shall use slow start. Any nonstandard initial or 233 maximum window sizes shall be indicated in the test report. 235 3.2 Test Streams 237 Packet trains presented to the DUT shall be random with respect to 238 prefix length or order of specificity. 240 The degree of update packing shall be specified. When long packet trains 241 are being sent, the usual case will be that maximum packing up to the 242 MTU size will be used. 244 3.3 Order of Received Updates 246 Within a set of updates, there is a potential for ordering among the 247 prefixes. For the fairest testing of update trains randomize the order 248 of prefixes, so no particular RIB data structure benefits by the 249 ordering. 251 Assume we have a Adj-RIB-out that consists of 253 1.0.0.0/8 254 2.0.0.0/8 255 3.0.0.0/8 256 1.1.0.0/16 257 2.1.0.0/16 258 3.1.0.0/16 259 3.2.0.0/16 260 1.1.1.0/24 261 1.1.2.0/24 262 2.1.2.0/24 264 If it were sent in this order, top to bottom, it would be sorted 265 by prefix size and prefix value within size. A radix tree 266 implementation might like to receive this very much. 268 But if it were sent out in the following order 270 1.0.0.0/8 271 1.1.0.0/16 272 1.1.1.0/24 273 1.1.2.0/24 274 2.0.0.0/8 275 2.1.0.0/16 276 2.1.2.0/24 277 3.0.0.0/8 278 3.1.0.0/16 279 3.2.0.0/16 281 It would make the day for an implementation that orders its routing 282 table as a strict tree, implemented as a linked list. 284 The optimal test train would be 286 1.0.0.0/8 287 2.1.0.0/16 288 1.1.0.0/16 289 3.0.0.0/8 290 1.1.1.0/24 291 2.0.0.0/8 292 1.1.2.0/24 293 3.1.0.0/16 294 2.1.2.0/24 295 3.2.0.0/16 296 which is random, and does not favor any particular implementation. 298 Measurement units: A metric of randomness,TBD 300 3.4 Initial Convergence 302 While this is relatively simple to measure, and often is the basis of 303 product specifications, it is operationally far less significant than 304 reconvergence after changes. A "carrier-grade" router should not 305 initialize often, and the soft reset option reduces the need to rebuild 306 views. The initialization time, therefore, can be amortized over a long 307 period of time and may disappear into the noise when compared to 308 reconvergence. 310 3.4.1 Single Peer Initial Convergence Time 312 This basic reference test uses a representatively sized and populated 313 target RIB and no other variable influences (eg authentication off, 314 filters off, no policy). 316 The test begins with OPEN requests sent from TR1 and TR2 to the DUT. 317 Each Test Router sends a standard routing table of TBD routes. 319 The test ends when the DUT begins to advertise the last route in the 320 routing table to TR3. 322 3.4.2 Multiple Peers 324 TBD 326 3.5 Incremental Re-convergence with a Single Peer 328 For all of these measurements, report any route filters, authentication, 329 and reverse path verification used. It is recommended that these not be 330 used for initial testing. 332 3.5.1 Explicit add of single new route 334 This test measures the time required to add a route newly advertised by 335 a peer. Such a route does not exist in the DUT's RIB, and will not 336 displace a route in the RIB. 338 The DUT has been initialized, with no path to D1. Measurement time 339 begins when TR1 announces D1 to the DUT. 341 Measurement time stops when the DUT advertises D1 to TR3. 343 3.5.2 Sequential withdraw and reannounce 345 The DUT has been initialized and has a path to D1 via TR1, not TR2. 346 Simultaneously, TR1 sends TDown(TR1) and TR2 announces the new route 347 with Tbest(TR2). 349 Measurement begins when Tbest is received at the DUT. Measurement time 350 stops when the DUT advertises D1 to TR3. 352 3.5.3 Time to Change to Alternate Path after Explicit Withdrawal 354 The DUT has been initialized and has paths to D1 via both TR1 and TR2. 355 TR1's path is preferred, but TR1 withdraws it with TDown(TR1). Re- 356 convergence occurs when the TR2 advertised path(s) becomes active. 358 Measurement time stops when the DUT advertises D1 to TR3. 360 3.6 Incremental Re-convergence with Multiple Peers 362 The number of routes per BGP peer is an obvious stressor to the 363 convergence process. The number, and relative proportion, of 364 multiple route instances and distinct routes being added or 365 withdrawn by each peer will affect the convergence process, as will 366 the mix of overlapping route instances, and IGP routes. 368 4. Flaps 369 The following tests evaluate convergence when route flap exists. 371 Let TRF be a router that will generate only flapping routes. 373 TR1==========+---------+==========TR3 374 | | | 375 D1 | | 376 | | DUT | 377 TR2==========| | 378 | | 379 ... 380 TRF==========+---------+ 381 Figure 3. Test Diagram with a Router, TRF, flapping. 383 4.1 Flap Isolation Test 385 TRF will advertise a continuously flapping route. Repeat the eBGP 386 convergence tests. 387 The objective is to determine whether one route flapping affects the 388 operation of the router. 390 4.2 Authentication 391 Repeat all tests above with MD5 authentication. 393 5. Acknowledgements 395 Thanks to Francis Ovenden for review and Abha Ahuja for encouragement. Much 396 appreciation to Jeff Haas, Matt Richardson, and Shane Wright at Nexthop for 397 comments and input. 399 6. References 401 [Ahuja 2000a] "An Experimental Study of Delayed Internet Routing 402 Convergence." Abha Ahuja, Farnam Jahanian, Abhijit Bose, Craig Labovits, 403 RIPE 37 - Routing WG. 404 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 405 Levels." S Bradner, March 1997. 406 [RFC 2539] "BGP Route Flap Damping" C. Villamizar, R. Chandra, R. 407 Govindan. November 1998. 408 [RFC 2544] "Benchmarking Methodology for Network Interconnect 409 Devices." S. Bradner, J. McQuaid. March 1999. 410 [RFC 2622] Routing Policy Specification Language (RPSL)." C. 411 Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, 412 D. Karrenberg, M. Terpstra. June 1999. 413 [RFC 2827] Network Ingress Filtering: Defeating Denial of Service 414 Attacks which employ IP Source Address Spoofing. P. Ferguson, D. 415 Senie. May 2000. 416 [RFC 2928] "Route Refresh Capability for BGP-4". E. Chen. 417 [Trotter] "Terminology for Forwarding Information Based (FIB) based 418 Router Performance Benchmarking", Work in Progress, IETF draft-ietf- 419 bmwg-fib-term-00.txt 421 12. Authors' Addresses 423 Howard Berkowitz 424 Nortel Networks 425 5012 S. 25th St 426 Arlington VA 22206 428 Phone: +1 703 998-5819 (ESN 451-5819) 429 Fax: +1 703 998-5058 430 EMail: hberkowi@nortelnetworks.com 431 hcb@clark.net 433 Alvaro Retana 434 Cisco Systems, Inc. 435 7025 Kit Creek Rd. 436 Research Triangle Park, NC 27709 437 Email: aretana@cisco.com 439 Susan Hares 440 Nexthop Technologies 441 517 W. William 442 Ann Arbor, Mi 48103 443 Phone: 444 Email: skh@nexthop.com 446 Padma Krishnaswamy 447 Nexthop Technologies 448 517 W William 449 Ann Arbor, Mi 48103 450 Phone: 734 936 2656 451 Email: kri@nexthop.com 453 Marianne Lepp 454 Juniper Networks 455 51 Sawyer Road 456 Waltham, MA 02453 457 Phone: 617 645 9019 458 Email: mlepp@juniper.net 460 Appendix A. Representative Scenarios 462 The following describes sample BGP applications positioned at various 463 points in the network. 465 A.1 Default-free interprovider peering 467 The DUT exchanges 0.3 to 0.5 D with a small number of peers. Typically, 468 routers in this application are limited by bandwidth rather than route 469 processing 471 A.2 Interprovider peering with transit 473 The DUT exchanges 1.3 D routes with a small number of peers. 475 A.3 Provider edge router 477 The DUT has a large number (>10) of eBGP peers. 479 To 10% of the peers, the DUT advertises 1.3 D. 480 To 20% of the peers, the DUT advertises 0.3 D. 481 To 70% of the peers, the DUT advertises default. 483 50% of the peers advertise an aggregate and a more-specific route to the 484 DUT. 485 20% of the peers advertise 10 or more routes to the DUT. 487 30% of the peers advertise a single route to the DUT. 488 A.4 Multihomed subscriber edge router 490 The DUT connects to 2 peers. It advertises an aggregate and a more- 491 specific to each. 493 Full Copyright Statement 495 Copyright (C) The Internet Society (2001). All Rights Reserved. 497 This document and translations of it may be copied and furnished to 498 others, and derivative works that comment on or otherwise explain it 499 or assist in its implementation may be prepared, copied, published 500 and distributed, in whole or in part, without restriction of any 501 kind, provided that the above copyright notice and this paragraph are 502 included on all such copies and derivative works. However, this 503 document itself may not be modified in any way, such as by removing 504 the copyright notice or references to the Internet Society or other 505 Internet organizations, except as needed for the purpose of 506 developing Internet standards in which case the procedures for 507 copyrights defined in the Internet Standards process must be 508 followed, or as required to translate it into languages other than 509 English. 511 The limited permissions granted above are perpetual and will not be 512 revoked by the Internet Society or its successors or assigns. 514 This document and the information contained herein is provided on an 515 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 516 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 517 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 518 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 519 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.