idnits 2.17.1 draft-ietf-bmwg-conterm-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 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 784 has weird spacing: '...between the ...' -- 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 30, 2003) is 7606 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) == Unused Reference: '9' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1473, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1505, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2385 (ref. '8') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2547 (ref. '10') (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-06 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-08 == Outdated reference: A later version (-10) exists of draft-ietf-forces-requirements-08 -- Obsolete informational reference (is this intentional?): RFC 2283 (ref. '17') (Obsoleted by RFC 2858) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group H. Berkowitz 3 Internet-Draft Gett Communications 4 Expires: December 29, 2003 E. Davies (ed.) 5 Nortel Networks 6 S. Hares 7 Nexthop Technologies 8 P. Krishnaswamy 9 SAIC 10 M. Lepp 11 Consultant 12 June 30, 2003 14 Terminology for Benchmarking BGP Device Convergence in the Control 15 Plane 16 draft-ietf-bmwg-conterm-05.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 29, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This draft establishes terminology to standardize the description of 47 benchmarking methodology for measuring eBGP convergence in the 48 control plane of a single BGP device. Future documents will address 49 iBGP convergence, the initiation of forwarding based on converged 50 control plane information and multiple interacting BGP devices. This 51 terminology is applicable to both IPv4 and IPv6. Illustrative 52 examples of each version are included where relevant. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Overview and Roadmap . . . . . . . . . . . . . . . . . . . . 4 58 1.2 Definition Format . . . . . . . . . . . . . . . . . . . . . 5 59 2. Components and Characteristics of Routing Information . . . 6 60 2.1 (Network) Prefix . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2 Network Prefix Length . . . . . . . . . . . . . . . . . . . 6 62 2.3 Route . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4 BGP Route . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.5 Network Level Reachability Information (NLRI) . . . . . . . 8 65 2.6 BGP UPDATE Message . . . . . . . . . . . . . . . . . . . . . 8 66 3. Routing Data Structures and Route Categories . . . . . . . . 9 67 3.1 Routing Information Base (RIB) . . . . . . . . . . . . . . . 9 68 3.1.1 Adj-RIB-In and Adj-RIB-Out . . . . . . . . . . . . . . . . . 9 69 3.1.2 Loc-RIB . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2 Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3 Routing Policy Information Base . . . . . . . . . . . . . . 10 72 3.4 Forwarding Information Base (FIB) . . . . . . . . . . . . . 11 73 3.5 BGP Instance . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.6 BGP Device . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.7 BGP Session . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.8 Active BGP Session . . . . . . . . . . . . . . . . . . . . . 13 77 3.9 BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.10 BGP Neighbor . . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.11 MinRouteAdvertisementInterval (MRAI) . . . . . . . . . . . . 14 80 3.12 MinASOriginationInterval (MAOI) . . . . . . . . . . . . . . 15 81 3.13 Active Route . . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.14 Unique Route . . . . . . . . . . . . . . . . . . . . . . . . 16 83 3.15 Non-Unique Route . . . . . . . . . . . . . . . . . . . . . . 16 84 3.16 Route Instance . . . . . . . . . . . . . . . . . . . . . . . 16 85 4. Constituent Elements of a Router or Network of Routers . . . 18 86 4.1 Default Route, Default Free Table, and Full Table . . . . . 18 87 4.1.1 Default Route . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1.2 Default Free Routing Table . . . . . . . . . . . . . . . . . 18 89 4.1.3 Full Default Free Table . . . . . . . . . . . . . . . . . . 19 90 4.1.4 Default-Free Zone . . . . . . . . . . . . . . . . . . . . . 20 91 4.1.5 Full Provider-Internal Table . . . . . . . . . . . . . . . . 20 92 4.2 Classes of BGP-Speaking Routers . . . . . . . . . . . . . . 20 93 4.2.1 Provider Edge Router . . . . . . . . . . . . . . . . . . . . 20 94 4.2.2 Subscriber Edge Router . . . . . . . . . . . . . . . . . . . 21 95 4.2.3 Inter-provider Border Router . . . . . . . . . . . . . . . . 21 96 4.2.4 Core Router . . . . . . . . . . . . . . . . . . . . . . . . 22 97 5. Characterization of Sets of Update Messages . . . . . . . . 23 98 5.1 Route Packing . . . . . . . . . . . . . . . . . . . . . . . 23 99 5.2 Route Mixture . . . . . . . . . . . . . . . . . . . . . . . 23 100 5.3 Update Train . . . . . . . . . . . . . . . . . . . . . . . . 24 101 5.4 Randomness in Update Trains . . . . . . . . . . . . . . . . 25 102 5.5 Route Flap . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 6. Route Changes and Convergence . . . . . . . . . . . . . . . 27 104 6.1 Route Change Events . . . . . . . . . . . . . . . . . . . . 27 105 6.2 Device Convergence in the Control Plane . . . . . . . . . . 28 106 7. BGP Operation Events . . . . . . . . . . . . . . . . . . . . 30 107 7.1 Hard Reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 7.2 Soft Reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 8. Factors that Impact the Performance of the Convergence 110 Process . . . . . . . . . . . . . . . . . . . . . . . . . . 32 111 8.1 General Factors Affecting Device Convergence . . . . . . . . 32 112 8.1.1 Number of Peers . . . . . . . . . . . . . . . . . . . . . . 32 113 8.1.2 Number of Routes per Peer . . . . . . . . . . . . . . . . . 32 114 8.1.3 Policy Processing/Reconfiguration . . . . . . . . . . . . . 32 115 8.1.4 Interactions with Other Protocols . . . . . . . . . . . . . 32 116 8.1.5 Flap Damping . . . . . . . . . . . . . . . . . . . . . . . . 33 117 8.1.6 Churn . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 8.2 Implementation-specific and other Factors Affecting BGP 119 Convergence . . . . . . . . . . . . . . . . . . . . . . . . 34 120 8.2.1 Forwarded Traffic . . . . . . . . . . . . . . . . . . . . . 34 121 8.2.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 122 8.2.3 TCP Parameters Underlying BGP Transport . . . . . . . . . . 34 123 8.2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 124 9. Security Considerations . . . . . . . . . . . . . . . . . . 35 125 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 126 Normative References . . . . . . . . . . . . . . . . . . . . 37 127 Informative References . . . . . . . . . . . . . . . . . . . 38 128 For Internet Draft consistency purposes only . . . . . . . . 39 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 130 Intellectual Property and Copyright Statements . . . . . . . 41 132 1. Introduction 134 This document defines terminology for use in characterizing the 135 convergence performance of BGP processes in routers or other devices 136 that instantiate BGP functionality (see RFC1771 [1]). It is the first 137 part of a two document series, of which the subsequent document will 138 contain the associated tests and methodology. This terminology is 139 applicable to both IPv4 and IPv6. Illustrative examples of each 140 version are included where relevant. Although IPv6 will require the 141 use of MP-BGP, we will not deal with issues related to RFC 2283 [17] 142 in this draft. 144 The following observations underlie the approach adopted in this, and 145 the companion document: 147 o The principal objective is to derive methodologies to standardize 148 conducting and reporting convergence-related measurements for BGP. 150 o It is necessary to remove ambiguity from many frequently used 151 terms that arise in the context of such measurements. 153 o As convergence characterization is a complex process, it is 154 desirable to restrict the initial focus in this set of documents 155 to specifying how to take basic control plane measurements as a 156 first step to characterizing BGP convergence. 158 For path vector protocols, such as BGP, the primary initial focus 159 will therefore be on network and system control-plane activity 160 consisting of the arrival, processing, and propagation of routing 161 information. 163 We note that for testing purposes all optional parameters should be 164 turned off. All variable parameters should be in their default 165 setting unless specified by the test. 167 Subsequent drafts will explore the more intricate aspects of 168 convergence measurement, such as the impacts of the presence of 169 Multiprotocol Extensions for BGP-4, policy processing, simultaneous 170 traffic on the control and data paths within the Cevice Under Test 171 (DUT), and other realistic performance modifiers. Convergence of 172 Interior Gateway Protocols will also be considered in separate 173 drafts. 175 1.1 Overview and Roadmap 177 Characterizations of the BGP convergence performance of a device must 178 take into account all distinct stages and aspects of BGP 179 functionality. This requires that the relevant terms and metrics be 180 as specifically defined as possible. Such definition is the goal of 181 this document. 183 The necessary definitions are classified into separate categories: 185 o Components and characteristics of routing information 187 o Routing data structures and route categories 189 o Descriptions of the constituent elements of a network or a router 190 that is undergoing convergence 192 o Characterization of sets of update messages, types of route change 193 events, as well as some events specific to BGP operation 195 o Descriptions of factors that impact the performance of 196 convergence processes 198 1.2 Definition Format 200 The definition format is equivalent to that defined in [3], and is 201 repeated here for convenience: 203 X.x Term to be defined. (e.g., Latency) 205 Definition: 206 One or more sentences forming the body of the definition. 208 Discussion: 209 A brief discussion of the term, its application and any 210 restrictions that there might be on measurement procedures. 212 Measurement units: 213 The units used to report measurements of this term, if applicable. 215 Issues: 216 List of issues or conditions that could affect this term. 218 See Also: 219 List of related terms that are relevant to the definition or 220 discussion of this term. 222 2. Components and Characteristics of Routing Information 224 2.1 (Network) Prefix 226 Definition: 227 "A network prefix is a contiguous set of bits at the more 228 significant end of the address that collectively designates the 229 set of systems within a network; host numbers select among those 230 systems." (This definition is taken directly from section 2.2.5.2, 231 "Classless Inter Domain Routing (CIDR)", in [3].) 233 Discussion: 234 In the CIDR context, the network prefix is the network component 235 of an IP address. 237 Measurement Units: N.A. 239 Issues: 241 See Also: 243 2.2 Network Prefix Length 245 Definition: 246 The network prefix length is the number of bits out of the total 247 available in the address field, used to define the network prefix. 249 Discussion: 250 A common alternative to using a bit-wise mask to communicate this 251 component is the use of "slash (/) notation." Slash notation binds 252 the notion of network prefix length in bits to an IP address. 253 E.g., 141.184.128.0/17 indicates the network component of this 254 IPv4 address is 17 bits wide. Similar notation is used for IPv6 255 network prefixes e.g. 2001:db8:719f::/48 257 When referring to groups of addresses, the network prefix length 258 is often used as a means of describing groups of addresses as an 259 equivalence class. For example, 'one hundred /16 addresses' 260 refers to 100 addresses whose network prefix length is 16 bits. 262 Measurement units: bits 264 Issues: 266 See Also: network prefix 268 2.3 Route 270 Definition: 271 In general, a 'route' is the n-tuple 272 275 A route is not end-to-end, but is defined with respect to a 276 specific next hop that should take packets on the next step 277 towards their destination as defined by the prefix. In this usage, 278 a route is the basic unit of information about a target 279 destination distilled from routing protocols. 281 Discussion: 282 This term refers to the concept of a route common to all routing 283 protocols. With reference to the definition above, typical 284 non-routing-protocol attributes would be associated with diffserv 285 or traffic engineering. 287 Measurement Units: N.A. 289 Issues: None. 291 See Also: BGP route 293 2.4 BGP Route 295 Definition: 296 A BGP route is an n-tuple 297 . 299 Discussion: 300 BGP Attributes, such as Nexthop or AS path are defined in RFC 301 1771[1], where they are known as Path Attributes, and are the 302 qualifying data that define the route. 304 From RFC 1771: "For purposes of this protocol a route is defined 305 as a unit of information that pairs a destination with the 306 attributes of a path to that destination" 308 Measurement Units: N.A. 310 Issues: 312 See Also: Route, prefix, Adj-RIB-in, NLRI. 314 2.5 Network Level Reachability Information (NLRI) 316 Definition: 317 The NLRI consists of one or more network prefixes with the same 318 set of path attributes. 320 Discussion: 321 Each prefix in the NLRI is combined with the (common) path 322 attributes to form a BGP route. The NLRI encapsulates a set of 323 destinations to which packets can be routed (from this point in 324 the network) along a common route described by the path 325 attributes. 327 Measurement Units: N.A. 329 Issues: 331 See Also: Route Packing, Network Prefix, BGP Route, NLRI 333 2.6 BGP UPDATE Message 335 Definition: 336 An UPDATE message contains an advertisement of a single NLRI 337 field, possibly containing multiple prefixes, and multiple 338 withdrawals of unfeasible routes. See RFC 1771 ([1]) for details. 340 Discussion: 341 From RFC 1771: "A variable length sequence of path attributes is 342 present in every UPDATE. Each path attribute is a triple 343 of variable 344 length." 346 Measurement Units: N.A. 348 See Also 350 3. Routing Data Structures and Route Categories 352 3.1 Routing Information Base (RIB) 354 The RIB collectively consists of a set of logically (not necessarily 355 physically) distinct databases, each of which is enumerated below. 356 The RIB contains all destination prefixes to which the router may 357 forward, and one or more currently reachable next hop addresses for 358 them. 360 Routes included in this set potentially have been selected from 361 several sources of information, including hardware status, interior 362 routing protocols, and exterior routing protocols. RFC 1812 contains 363 a basic set of route selection criteria relevant in an all-source 364 context. Many implementations impose additional criteria. A common 365 implementation-specific criterion is the preference given to 366 different routing information sources. 368 3.1.1 Adj-RIB-In and Adj-RIB-Out 370 Definition: 371 Adj-RIB-In and Adj-RIB-Out are "views" of routing information from 372 the perspective of individual peer routers. 374 The Adj-RIB-In contains information advertised to the DUT by a 375 specific peer. The Adj-RIB-Out contains the information the DUT 376 will advertise to the peer. 378 See RFC 1771[1]. 380 Discussion: 382 Issues: 384 Measurement Units: Number of route instances 386 See Also: 387 Route, BGP Route, Route Instance, Loc-RIB, FIB 389 3.1.2 Loc-RIB 391 Definition: 392 The Loc-RIB contains the set of best routes selected from the 393 various Adj-RIBs, after applying local policies and the BGP route 394 selection algorithm. 396 Discussion: 397 The separation implied between the various RIBs is logical. It 398 does not necessarily follow that these RIBs are distinct and 399 separate entities in any given implementation. 401 Types of routes that need to be considered include internal BGP, 402 external BGP, interface, static and IGP routes. 404 Issues: 406 Measurement Units: Number of routes 408 See Also: 409 Route, BGP Route, Route Instance, Adj-RIB-in, Adj-RIB-out, FIB 411 3.2 Routing Policy 413 Definition: 414 Routing Policy is "the ability to define conditions for accepting, 415 rejecting, and modifying routes received in advertisements"[9]. 417 Discussion: 418 RFC 1771 [1] further constrains policy to be within the hop-by-hop 419 routing paradigm. Policy is implemented using filters and 420 associated policy actions. Many AS's formulate and document their 421 policies using the Routing Policy Specification Language (RPSL) 422 [6] and then automatically generate configurations for the BGP 423 processes in their routers from the RPSL specifications. 425 Measurement Units: Number of policies; length of policies 427 Issues: 429 See Also: Routing Policy Information Base. 431 3.3 Routing Policy Information Base 433 Definition: 434 A routing policy information base is the set of incoming and 435 outgoing policies. 437 Discussion: 438 All references to the phase of the BGP selection process below are 439 made with respect to RFC 1771 [1] definition of these phases. 441 Incoming policies are applied in Phase 1 of the BGP selection 442 process [1] to the Adj-RIB-In routes to set the metric for the 443 Phase 2 decision process. Outgoing Policies are applied in Phase 444 3 of the BGP process to the Adj-RIB-Out routes preceding route 445 (prefix and path attribute tuple) announcements to a specific 446 peer. 448 Policies in the Policy Information Base have matching and action 449 conditions. Common information to match include route prefixes, 450 AS paths, communities, etc. The action on match may be to drop 451 the update and not pass it to the Loc-RIB, or to modify the update 452 in some way, such as changing local preference (on input) or MED 453 (on output), adding or deleting communities, prepending the 454 current AS in the AS path, etc. 456 The amount of policy processing (both in terms of route maps and 457 filter/access lists) will impact the convergence time and 458 properties of the distributed BGP algorithm. The amount of policy 459 processing may vary from a simple policy which accepts all routes 460 and sends all routes to complex policy with a substantial fraction 461 of the prefixes being filtered by filter/access lists. 463 Measurement Units: Number and length of policies 465 Issues: 467 See Also: 469 3.4 Forwarding Information Base (FIB) 471 Definition: 472 As according to the definition in Appendix B of [4]: "The table 473 containing the information necessary to forward IP Datagrams is 474 called the Forwarding Information Base. At minimum, this contains 475 the interface identifier and next hop information for each 476 reachable destination network prefix." 478 Discussion: 479 The forwarding information base describes a database indexing 480 network prefixes versus router port identifiers. 482 The forwarding information base is distinct from the "routing 483 table" (the Routing Information Base or RIB), which holds all 484 routing information received from routing peers. It is a data 485 plane construct and used for the forwarding of each packet. The 486 Forwarding Information Base is generated from the RIB. For the 487 purposes of this document, the FIB is effectively the subset of 488 the RIB used by the forwarding plane to make per-packet forwarding 489 decisions. 491 Most current implementations have full, non-cached FIBs per router 492 interface. All the route computation and convergence occurs before 493 entries are downloaded into a FIB. 495 Measurement units: N.A. 497 Issues: 499 See Also: Route, RIB 501 3.5 BGP Instance 503 Definition: 504 A BGP instance is a process with a single Loc-RIB. 506 Discussion: 507 For example, a BGP instance would run in routers or test 508 equipment. A test generator acting as multiple peers will 509 typically run more than one instance of BGP. A router would 510 typically run a single instance. 512 Measurement units: N/A 514 Issues: 516 See Also: 518 3.6 BGP Device 520 Definition: 521 A BGP device is a system that has one or more BGP instances 522 running on it, each of which is responsible for executing the BGP 523 state machine. 525 Discussion: 526 We have chosen to use "device" as the general case, to deal with 527 the understood [e.g. [9]] and yet-to-be-invented cases where the 528 control processing may be separate from forwarding [12]. A BGP 529 device may be a traditional router, a route server, a BGP-aware 530 traffic steering device or a non forwarding route reflector. BGP 531 instances such as route reflectors or servers, for example, never 532 forwards traffic, so forwarding-based measurements would be 533 meaningless for it. 535 Measurement units: N/A 537 Issues: 539 See Also: 541 3.7 BGP Session 543 Definition: 544 A BGP session is a session between two BGP instances. 546 Discussion: 548 Measurement units: N/A 550 Issues: 552 See Also: 554 3.8 Active BGP Session 556 Definition: 557 An active BGP session is one which is in the established state. 558 (See RFC 1771 [1]). 560 Discussion: 562 Measurement units: N/A 564 Issues: 566 See Also: 568 3.9 BGP Peer 570 Definition: 571 A BGP peer is another BGP instance to which the DUT is in the 572 Established state. (See RFC 1771 [1]). 574 Discussion: 575 In the test scenarios in the methodology discussion that will 576 follow this draft, peers send BGP advertisements to the DUT and 577 receive DUT-originated advertisements. We recommend that the 578 peering relation be established before tests are begun. It might 579 also be interesting to measure the time required to reach the 580 established state. 582 This is a protocol-specific definition, not to be confused with 583 another frequent usage, which refers to the business/economic 584 definition for the exchange of routes without financial 585 compensation. 587 It is worth noting that a BGP peer, by this definition is 588 associated with a BGP peering session, and there may be more than 589 one such active session on a router or on a tester. The peering 590 sessions referred to here may exist between various classes of BGP 591 routers (see Section 4.2). 593 Measurement units: number of BGP peers 595 Issues: 597 See Also: 599 3.10 BGP Neighbor 601 Definition: 602 A BGP neighbor is a device that can be configured as a BGP peer. 604 Discussion: 606 Measurement units: 608 Issues: 610 See Also: 612 3.11 MinRouteAdvertisementInterval (MRAI) 614 Definition: 615 (Paraphrased from 1771[1]) The MRAI timer determines the minimum 616 time between advertisements of routes to a particular destination 617 (prefix) from a single BGP device. The timer is applied on a 618 pre-prefix basis, although the timer is set on a per BGP device 619 basis. 621 Discussion: 622 Given that a BGP instance may manage in excess of 100,000 routes, 623 RFC 1771 allows for a degree of optimization in order to limit the 624 number of timers needed. The MRAI does not apply to routes 625 received from BGP speakers in the same AS or to explicit 626 withdrawals. 628 RFC 1771 also recommends that random jitter is applied to MRAI in 629 an attempt to avoid synchronization effects between the BGP 630 instances in a network. 632 In this document we define routing plane convergence by measuring 633 the time an NLRI is advertised to the DUT to the time it is 634 advertised from the DUT. Clearly any delay inserted by the MRAI 635 will have a significant effect on this measurement. 637 Measurement Units: seconds. 639 Issues: 641 See Also: NLRI, BGP route 643 3.12 MinASOriginationInterval (MAOI) 645 Definition: 646 The MAOI specifies the minimum interval between advertisements of 647 locally originated routes from this BGP instance. 649 Discussion: 650 Random jitter is applied to MAOI in an attempt to avoid 651 synchronization effects between BGP instances in a network. 653 Measurement Units: seconds 655 Issues: 656 It is not known what, if any relationship exists between the 657 settings of MRAI and MAOI. 659 See Also: MRAI, BGP route 661 3.13 Active Route 663 Definition: 664 Route for which there is a FIB entry corresponding to a RIB entry. 666 Discussion: 668 Measurement Units: Number of routes. 670 Issues: 672 See also: RIB. 674 3.14 Unique Route 676 Definition: 677 A unique route is a prefix for which there is just one route 678 instance across all Adj-Ribs-In. 680 Discussion: 682 Measurement Units: N.A. 684 Issues: 686 See Also: route, route instance 688 3.15 Non-Unique Route 690 Definition: 691 A Non-unique route is a prefix for which there is at least one 692 other route in a set including more than one Adj-RIB-in. 694 Discussion: 696 Measurement Units: N.A. 698 Issues: 700 See Also: 701 route, route instance, unique active route. 703 3.16 Route Instance 705 Definition: 706 A route instance is one of several possible occurrences of a route 707 for a particular prefix. 709 Discussion: 710 When a router has multiple peers from which it accepts routes, 711 routes to the same prefix may be received from several peers. This 712 is then an example of multiple route instances. 714 Each route instance is associated with a specific peer. The BGP 715 algorithm that arbitrates between the available candidate route 716 instances may reject a specific route instance due to local 717 policy. 719 Measurement Units: Number of route instances 721 Issues: 722 The number of route instances in the Adj-RIB-in bases will vary 723 based on the function to be performed by a router. An 724 inter-provider border router, located in the default-free zone 725 (see Section 4.1.4) will likely receive more route instances than 726 a provider edge router, located closer to the end-users of the 727 network. 729 See Also: 731 4. Constituent Elements of a Router or Network of Routers 733 Many terms included in this list of definitions were originally 734 described in previous standards or papers. They are included here 735 because of their pertinence to this discussion. Where relevant, 736 reference is made to these sources. An effort has been made to keep 737 this list complete with regard to the necessary concepts without over 738 definition. 740 4.1 Default Route, Default Free Table, and Full Table 742 An individual router's routing table may not necessarily contain a 743 default route. Not having a default route, however, is not 744 synonymous with having a full default-free table(DFT). Also, a 745 router which has a full set of routes as in a DFT but also has a 746 'discard' rule for a default route would not be considered as default 747 free. 749 It should be noted that the references to number of routes in this 750 section document are to routes installed in the loc-RIB and are 751 therefore unique routes, not route instances, and that the total 752 number of route instances may be 4 to 10 times the number of routes. 754 4.1.1 Default Route 756 Definition: 757 A Default Route can match any destination address. If a router 758 does not have a more specific route for a particular packet's 759 destination address, it forwards this packet to the next hop in 760 the default route entry, provided its Forwarding Table (Forwarding 761 Information Base (FIB) contains one). The notation for a default 762 route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or 763 ::/0. 765 Discussion: 767 Measurement units: N.A. 769 Issues: 771 See Also: default free routing table, route, route instance 773 4.1.2 Default Free Routing Table 774 Definition: 775 A default free routing table has no default routes and is 776 typically seen in routers in the core or top tier of routers in 777 the network. 779 Discussion: 780 The term originates from the concept that routers at the core or 781 top tier of the Internet will not be configured with a default 782 route (Notation in IPv4 0.0.0.0/0 and in IPv6 0:0:0:0:0:0:0:0 or 783 ::/0). Thus they will forward every packet to a specific next hop 784 based on the longest match between the destination IP addresse 785 and the routes in the forwarding table. 787 Default free routing table size is commonly used as an indicator 788 of the magnitude of reachable Internet address space. However, 789 default free routing tables may also include routes internal to 790 the router's AS. 792 Measurement Units: The number of routes 794 See Also: Full Default Free, Default Route 796 4.1.3 Full Default Free Table 798 Definition: 799 A full default free table is the union of all sets of default free 800 BGP routes collectively announced by the complete set of 801 autonomous systems making up the public Internet. Due to the 802 dynamic nature of the Internet, the exact size and composition of 803 this table may vary slightly depending where and when it is 804 observed. 806 Discussion: 807 It is generally accepted that a full table, in this usage, does 808 not contain the infrastructure routes or individual sub-aggregates 809 of routes that are otherwise aggregated by the provider before 810 announcement to other autonomous systems. 812 Measurement Units: number of routes 814 Issues: 816 See Also: Routes, Route Instances, Default Route 818 4.1.4 Default-Free Zone 820 Definition: 821 The default-free zone is that part of the Internet backbone that 822 does not have a default route. 824 Discussion: 826 Measurement Units: 828 Issues: 830 See Also: Default Route 832 4.1.5 Full Provider-Internal Table 834 Definition: 835 A full provider-internal table is a superset of the full routing 836 table that contains infrastructure and non- aggregated routes. 838 Discussion: 839 Experience has shown that this table might contain 1.3 to 1.5 840 times the number of routes in the externally visible full table. 841 Tables of this size, therefore, are a real-world requirement for 842 key internal provider routers. 844 Measurement Units: number of routes 846 Issues: 848 See Also: Routes, Route Instances, Default Route 850 4.2 Classes of BGP-Speaking Routers 852 A given router may perform more than one of the following functions, 853 based on its logical location in the network. 855 4.2.1 Provider Edge Router 857 Definition: 858 A provider edge router is a router at the edge of a provider's 859 network that speaks eBGP to a BGP speaker in another AS. 861 Discussion: 862 The traffic that transits this router may be destined to, or 863 originate from non-adjacent autonomous systems. In particular the 864 MED values used in the Provider Edge Router would not be visible 865 in the non-adjacent autonomous systems. 867 Such a router will always speak eBGP and may speak iBGP. 869 Measurement units: 871 Issues: 873 See Also: 875 4.2.2 Subscriber Edge Router 877 Definition: 878 A subscriber edge router is router at the edge of the subscriber's 879 network that speaks eBGP to its provider's AS(s). 881 Discussion: 882 The router belongs to an end user organization that may be multi- 883 homed, and which carries traffic only to and from that end user 884 AS. 886 Such a router will always speak eBGP and may speak iBGP. 888 Measurement units: 890 Issues: 891 This definition of an enterprise border router (which is what most 892 Subscriber Edge Routers are) is practical rather than rigorous. It 893 is meant to draw attention to the reality that many enterprises 894 may need a BGP speaker that advertises their own routes and 895 accepts either default alone or partial routes. In such cases, 896 they may be interested in benchmarks that use a partial routing 897 table, to see if a smaller control plane processor will meet their 898 needs. 900 See Also: 902 4.2.3 Inter-provider Border Router 904 Definition: 905 An inter-provider border router is a BGP speaking router which 906 maintains BGP sessions with other BGP speaking routers in other 907 providers' ASs. 909 Discussion: 910 Traffic transiting this router may be originated in or destined 911 for another AS that has no direct connectivity with this 912 provider's AS. 914 Such a router will always speak eBGP and may speak iBGP. 916 Measurement units: 918 Issues: 920 See Also: 922 4.2.4 Core Router 924 Definition: 925 An core router is a provider router Internal to the provider's 926 net, speaking iBGP to that provider's edge routers, other intra- 927 provider core routers, or the provider's inter-provider border 928 routers. 930 Discussion: 931 Such a router will always speak iBGP and may speak eBGP. 933 Measurement units: 935 Issues: 936 Then by this definition the DUT's which are eBGP routers aren't 937 core routers. 939 See Also: 941 5. Characterization of Sets of Update Messages 943 This section contains a sequence of definitions that build up to the 944 definition of an Update Train. The Packet train concept was 945 originally introduced by Jain and Routhier [11]. It is here adapted 946 to refer to a train of packets of interest in BGP performance 947 testing. 949 This is a formalization of the sort of test stimulus that is expected 950 as input to a DUT running BGP. This data could be a 951 well-characterized, ordered and timed set of hand-crafted BGP UPDATE 952 packets. It could just as well be a set of BGP UPDATE packets that 953 have been captured from a live router. 955 Characterization of route mixtures and Update Trains is an open area 956 of research. The particular question of interest for this work is 957 the identification of suitable Update Trains, modeled or taken from 958 live traces that reflect realistic sequences of UPDATEs and their 959 contents. 961 5.1 Route Packing 963 Definition: 964 Route packing is the number of route prefixes accommodated in a 965 single Routing Protocol UPDATE Message either as updates 966 (additions or modifications) or withdrawals. 968 Discussion: 969 In general, a routing protocol update may contain more than one 970 prefix. In BGP, a single UPDATE may contain two sets of multiple 971 network prefixes: one set of additions and updates with identical 972 attributes (the NLRI) and one set of unfeasible routes to be 973 withdrawn. 975 Measurement Units: 976 Number of prefixes. 978 Issues: 980 See Also: 981 route, BGP route, route instance, update train, NLRI. 983 5.2 Route Mixture 984 Definition: 985 A route mixture is the demographics of a set of routes. 987 Discussion: 988 A route mixture is the input data for the benchmark. The 989 particular route mixture used as input must be selected to suit 990 the question being asked of the benchmark. Data containing simple 991 route mixtures might be suitable to test the performance limits of 992 the BGP device. 994 Using live data, or input that simulates live data, should improve 995 understanding of how the BGP device will operate in a live 996 network. The data for this kind of test must be route mixtures 997 that model the patterns of arriving control traffic in the live 998 Internet. 1000 To accomplish that kind of modeling it is necessary to identify 1001 the key parameters that characterize a live Internet route 1002 mixture. The parameters and how they interact is an open research 1003 problem. However, we identify the following as affecting the 1004 route mixture: 1006 * Path length distribution 1008 * Attribute distribution 1010 * Prefix length distribution 1012 * Packet packing 1014 * Probability density function of inter-arrival times of 1015 UPDATES 1017 Each of the items above is more complex than a single number. For 1018 example, one could consider the distribution of prefixes by AS or 1019 distribution of prefixes by length. 1021 Measurement Units: Probability density functions 1023 Issues: 1025 See Also: NLRI, RIB. 1027 5.3 Update Train 1028 Definition: 1029 An update train is a set of Routing Protocol UPDATE messages sent 1030 by a router to a BGP peer. 1032 Discussion: 1033 The arrival pattern of UPDATEs can be influenced by many things, 1034 including TCP parameters, hold-down timers, upsteam processing, a 1035 peer coming up or multiple peers sending at the same time. 1036 Network conditions such as a local or remote peer flapping a link 1037 can also affect the arrival pattern. 1039 Measurement units: 1040 Probability density function for the inter-arrival times of UPDATE 1041 packets in the train. 1043 Issues: 1044 Characterizing the profiles of real world UPDATE trains is a 1045 matter for future research. In order to generate realistic UPDATE 1046 trains as test stimuli a formal mathematical scheme or a proven 1047 heuristic is needed to drive the selection of prefixes. Whatever 1048 mechanism is selected it must generate Update trains that have 1049 similar characteristics to those measured in live networks. 1051 See Also: Route Mixture, MRAI, MAOI 1053 5.4 Randomness in Update Trains 1055 As we have seen from the previous sections, an update train used as a 1056 test stimulus has a considerable number of parameters that can be 1057 varied, to a greater or lesser extent, randomly and independently. 1059 A random Update Train will contain: 1061 o A route mixture randomized across 1063 * NLRIs 1065 * updates and withdrawals 1067 * prefixes 1069 * inter-arrival times of the UPDATEs 1071 and possibly across other variables. 1073 This is intended to simulate the unpredictable asynchronous nature of 1074 the network, whereby UPDATE packets may have arbitrary contents and 1075 be delivered at random times. 1077 It is important that the data set be randomized sufficiently to avoid 1078 favoring one vendor's implementation over another's. Specifically, 1079 the distribution of prefixes could be structured to favor the 1080 internal organization of the routes in a particular vendor's 1081 databases. This is to be avoided. 1083 5.5 Route Flap 1085 Definition: 1086 A route flap ia a change of state (withdrawal, announcement, 1087 attribute change) for a route. 1089 Discussion: 1090 Route flapping can be considered a special and pathological case 1091 of update trains. A practical interpretation of what may be 1092 considered excessively rapid is the RIPE 229 [7], which contains 1093 current guidelines on flap damping parameters. 1095 Measurement units: Flapping events per unit time. 1097 Issues: 1098 Specific Flap events can be found in Section 6.1. A bench-marker 1099 should use a mixture of different route change events in testing. 1101 See Also: Route change events, flap damping, packet train 1103 6. Route Changes and Convergence 1105 The following two definitions are central to the benchmarking of 1106 external routing convergence, and so are singled out for more 1107 extensive discussion. 1109 6.1 Route Change Events 1111 A taxonomy characterizing routing information changes seen in 1112 operational networks is proposed in [4] as well as Labovitz et al[5]. 1113 These papers describe BGP protocol-centric events, and event 1114 sequences in the course of an analysis of network behavior. The 1115 terminology in the two papers categorizes similar but slightly 1116 different behaviors with some overlap. We would like to apply these 1117 taxonomies to categorize the tests under definition where possible, 1118 because these tests must tie in to phenomena that arise in actual 1119 networks. We avail ourselves of, or may extend, this terminology as 1120 necessary for this purpose. 1122 A route can be changed implicitly by replacing it with another route 1123 or explicitly by withdrawal followed by the introduction of a new 1124 route. In either case the change may be an actual change, no change, 1125 or a duplicate. The notation and definition of individual 1126 categorizable route change events is adopted from [5] and given 1127 below. 1129 1. AADiff: Implicit withdrawal of a route and replacement by a route 1130 different in some path attribute. 1132 2. AADup: Implicit withdrawal of a route and replacement by route 1133 that is identical in all path attributes. 1135 3. WADiff: Explicit withdrawal of a route and replacement by a 1136 different route. 1138 4. WADup: Explicit withdrawal of a route and replacement by a route 1139 that is identical in all path attributes. 1141 To apply this taxonomy in the benchmarking context, we need both 1142 terms to describe the sequence of events from the update train 1143 perspective, as listed above, and event indications in the time 1144 domain so as to be able to measure activity from the perspective of 1145 the DUT. With this in mind, we incorporate and extend the definitions 1146 of [5] to the following: 1148 1. Tup (TDx): Route advertised to the DUT by Test Device x 1150 2. Tdown(TDx): Route being withdrawn by Device x 1151 3. Tupinit(TDx): The initial announcement of a route to a unique 1152 prefix 1154 4. TWF(TDx): Route fail over after an explicit withdrawal. 1156 But we need to take this a step further. Each of these events can 1157 involve a single route, a "short" packet train, or a "full" routing 1158 table. We further extend the notation to indicate how many routes are 1159 conveyed by the events above: 1161 1. Tup(1,TDx) means Device x sends 1 route 1163 2. Tup(S,TDx) means Device x sends a train, S, of routes 1165 3. Tup(DFT,TDx) means Device x sends an approximation of a full 1166 default-free table. 1168 The basic criterion for selecting a "better" route is the final 1169 tiebreaker defined in RFC1771, the router ID. As a consequence, this 1170 memorandum uses the following descriptor events, which are routes 1171 selected by the BGP selection process rather than simple updates: 1173 1. Tbest -- The current best path. 1175 2. Tbetter -- Advertise a path that is better than Tbest. 1177 3. Tworse -- Advertise a path that is worse than Tbest. 1179 6.2 Device Convergence in the Control Plane 1181 Definition: 1182 A routing device is said to have converged at the point in time 1183 when the DUT has performed all actions in the control plane needed 1184 to react to changes in topology in the context of the test 1185 condition. 1187 Discussion: 1188 For example, when considering BGP convergence, the convergence 1189 resulting from a change that alters the best route instance for a 1190 single prefix at a router would be deemed to have occurred when 1191 this route is advertised to its downstream peers. By way of 1192 contrast, OSPF convergence concludes when SPF calculations have 1193 been performed and the required link states advertised onwards. 1195 The convergence process, in general, can be subdivided into three 1196 distinct phases: 1198 * convergence across the entire Internet, 1200 * convergence within an Autonomous System, 1202 * convergence with respect to a single device. 1204 Convergence with respect to a single device can be 1206 * convergence with regard to data forwarding process(es) 1208 * convergence with regard to the routing process(es), the focus 1209 of this document. 1211 It is the latter, convergence with regard to the routing process, 1212 that we describe in this and the methodology documents. 1214 Because we are trying to benchmark the routing protocol 1215 performance which is only a part of the device overall, this 1216 definition is intended (so far as is possible) to exclude any 1217 additional time such as is needed to download and install the 1218 forwarding information base in the data plane. This definition 1219 should be usable for different families of protocols. 1221 It is of key importance to benchmark the performance of each phase 1222 of convergence separately before proceeding to a composite 1223 characterization of routing convergence, where 1224 implementation-specific dependencies are allowed to interact. 1226 Care also needs to be taken to ensure that the convergence time is 1227 not influenced by policy processing on downstream peers. 1229 The time resolution needed to measure the device convergence 1230 depends to some extent on the types of the interfaces on the 1231 router. For modern routers with gigabit or faster interfaces, an 1232 individual UPDATE may be processed and re-advertised in very much 1233 less than a millisecond so that time measurements must be made to 1234 a resolution of hundreds to tens of microseconds or better. 1236 Measurement Units: 1237 Time period. 1239 Issues: 1241 See Also: 1243 7. BGP Operation Events 1245 The BGP process(es) in a device might restart because operator 1246 intervention or a power failure caused a complete shut-down. In this 1247 case a hard reset is needed. A peering session could be lost, for 1248 example, because of action on the part of the peer or a dropped tcp 1249 session. A device can reestablish its peers and re-advertise all 1250 relevant routes in a hard reset. However, if a peer is lost, but 1251 the BGP process has not failed, BGP has mechanisms for a "soft 1252 reset." 1254 7.1 Hard Reset 1256 Definition: 1257 An event which triggers a complete re-initialization of the 1258 routing tables on one or more BGP sessions, resulting in exchange 1259 of a full routing table on one or more links to the router. 1261 Discussion: 1263 Measurement Units: N/A 1265 Issues: 1267 See Also: 1269 7.2 Soft Reset 1271 Definition: 1272 A soft reset is performed on a per-neighbor basis; it does not 1273 clear the BGP session while re-establishing the peering relation 1274 and does not stop the flow of traffic. 1276 Discussion: 1277 There are two methods of performing a soft reset: Graceful restart 1278 [13] where the BGP device that has lost a peer but continues to 1279 forward traffic for a period of time before tearing down the 1280 peer's routes. The alternative method is soft refresh [12], where 1281 a BGP device can request a peer's Adj-RIB-Out. 1283 Measurement Units: N/A 1285 Issues: 1287 See Also: 1289 8. Factors that Impact the Performance of the Convergence Process 1291 While this is not a complete list, all of the items discussed below 1292 have a significant affect on BGP convergence. Not all of them can be 1293 addressed in the baseline measurements described in this document. 1295 8.1 General Factors Affecting Device Convergence 1297 These factors are conditions of testing external to the router Device 1298 Under Test (DUT). 1300 8.1.1 Number of Peers 1302 As the number of peers increases, the BGP route selection algorithm 1303 is increasingly exercised. In addition, the phasing and frequency of 1304 updates from the various peers will have an increasingly marked 1305 effect on the convergence process on a router as the number of peers 1306 grows, depending on the quantity of updates that is generated by each 1307 additional peer. Increasing the number of peers also increases the 1308 processing workload for TCP and BGP keepalives. 1310 8.1.2 Number of Routes per Peer 1312 The number of routes per BGP peer is an obvious stressor to the 1313 convergence process. The number, and relative proportion, of multiple 1314 route instances and distinct routes being added or withdrawn by each 1315 peer will affect the convergence process, as will the mix of 1316 overlapping route instances, and IGP routes. 1318 8.1.3 Policy Processing/Reconfiguration 1320 The number of routes and attributes being filtered, and set, as a 1321 fraction of the target route table size is another parameter that 1322 will affect BGP convergence. 1324 Extreme examples are 1326 o Minimal Policy: receive all, send all, 1328 o Extensive policy: up to 100% of the total routes have applicable 1329 policy. 1331 8.1.4 Interactions with Other Protocols 1333 There are interactions in the form of precedence, synchronization, 1334 duplication and the addition of timers, and route selection criteria. 1335 Ultimately, understanding BGP4 convergence must include understanding 1336 of the interactions with both the IGPs and the protocols associated 1337 with the physical media, such as Ethernet, SONET, DWDM. 1339 8.1.5 Flap Damping 1341 A router can use flap damping to respond to route flapping. Use of 1342 flap damping is not mandatory, so the decision to enable the feature, 1343 and to change parameters associated with it, can be considered a 1344 matter of routing policy. 1346 The timers are defined by RFC 2439 [2] and discussed in RIPE-229 [7]. 1347 If this feature is in effect, it requires that the device keep 1348 additional state to carry out the damping, which can have a direct 1349 impact on the control plane due to increased processing. In 1350 addition, flap damping may delay the arrival of real changes in a 1351 route, and affect convergence times 1353 8.1.6 Churn 1355 In theory, a BGP device could receive a set of updates that 1356 completely defined the Internet, and could remain in a steady state, 1357 only sending appropriate keepalives. In practice, the Internet will 1358 always be changing. 1360 Churn refers to control plane processor activity caused by 1361 announcements received and sent by the router. It does not include 1362 keepalives and TCP processing. 1364 Churn is caused by both normal and pathological events. For example, 1365 if an interface of the local router goes down and the associated 1366 prefix is withdrawn, that withdrawal is a normal activity, although 1367 it contributes to churn. If the local device receives a withdrawal 1368 of a route it already advertises, or an announcement of a route it 1369 did not previously know, and re-advertises this information, again 1370 these are normal constituents of churn. Routine updates can range 1371 from single announcement or withdrawals, to announcements of an 1372 entire default-free table. The latter is completely reasonable as an 1373 initialization condition. 1375 Flapping routes are a pathological contributor to churn, as is MED 1376 oscillation [16]. The goal of flap damping is to reduce the 1377 contribution of flapping to churn. 1379 The effect of churn on overall convergence depends on the processing 1380 power available to the control plane, and whether the same 1381 processor(s) are used for forwarding and for control. 1383 8.2 Implementation-specific and other Factors Affecting BGP Convergence 1385 These factors are conditions of testing internal to the Device Under 1386 Test (DUT), although they may affect its interactions with test 1387 devices. 1389 8.2.1 Forwarded Traffic 1391 The presence of actual traffic in the device may stress the control 1392 path in some fashion if both the offered load due to data and the 1393 control traffic (FIB updates and downloads as a consequence of flaps) 1394 are excessive. The addition of data traffic presents a more accurate 1395 reflection of realistic operating scenarios than if only control 1396 traffic is present. 1398 8.2.2 Timers 1400 Settings of delay and hold-down timers at the link level as well as 1401 for BGP4, can introduce or ameliorate delays. As part of a test 1402 report, all relevant timers should be reported if they use non- 1403 default value. 1405 8.2.3 TCP Parameters Underlying BGP Transport 1407 Since all BGP traffic and interactions occur over TCP, all relevant 1408 parameters characterizing the TCP sessions should be provided: e.g. 1409 Slow start, max window size, maximum segment size, or timers. 1411 8.2.4 Authentication 1413 Authentication in BGP is currently done using the TCP MD5 Signature 1414 Option [8]. The processing of the MD5 hash, particularly in devices 1415 with a large number of BGP peers and a large amount of update traffic 1416 can have an impact on the control plane of the device. 1418 9. Security Considerations 1420 The document explicitly considers authentication as a performance- 1421 affecting feature, but does not consider the overall security of the 1422 routing system. 1424 10. Acknowledgments 1426 Thanks to Francis Ovenden for review and Abha Ahuja for 1427 encouragement. Much appreciation to Jeff Haas, Matt Richardson, and 1428 Shane Wright at Nexthop for comments and input. Debby Stopp and Nick 1429 Ambrose contributed the concept of route packing. 1431 Alvaro Retana was a key member of the team that developed this 1432 document, and made significant technical contributions regarding 1433 route mixes. The team thanks him and regards him as a co-author in 1434 spirit. 1436 Normative References 1438 [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1439 RFC 1771, March 1995. 1441 [2] Villamizar, C., Chandra, R. and R. Govindan , "BGP Route Flap 1442 Damping", RFC 2439, November 1998. 1444 [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1445 June 1995. 1447 [4] Ahuja, A., Jahanian, F., Bose, A. and C. Labovitz, "An 1448 Experimental Study of Delayed Internet Routing Convergence", 1449 RIPE-37 Presentation to Routing WG, November 2000, . 1453 [5] Labovitz, C., Malan, G. and F. Jahanian, "Origins of Internet 1454 Routing Instability", Infocom 99, August 1999. 1456 [6] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1457 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 1458 Policy Specification Language (RPSL)", RFC 2622, June 1999. 1460 [7] Panigl , C., Schmitz , J., Smith , P. and C. Vistoli, "RIPE 1461 Routing-WG Recommendation for coordinated route-flap damping 1462 parameters, version 2", RIPE 229, October 2001. 1464 [8] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1465 Signature Option", RFC 2385, August 1998. 1467 [9] Juniper Networks, "Junos(tm) Internet Software Configuration 1468 Guide Routing and Routing Protocols, Release 4.2", Junos 4.2 1469 and other releases, September 2000, . 1473 [10] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1474 1999. 1476 [11] Jain, R. and S. Routhier, "Packet trains -- measurement and a 1477 new model for computer network traffic", IEEE Journal on 1478 Selected Areas in Communication 4(6), September 1986. 1480 Informative References 1482 [12] Chen, E., "Route Refresh for BGP-4", RFC 2918, September 2000. 1484 [13] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. Chen, 1485 "Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-06 1486 (work in progress), January 2003. 1488 [14] Chen, E. and Y. Rekhter, "Cooperative Route Filtering 1489 Capability for BGP-4", draft-ietf-idr-route-filter-08 (work in 1490 progress), January 2003. 1492 [15] Anderson, T. and H. Khosravi, "Requirements for Separation of 1493 IP Control and Forwarding", draft-ietf-forces-requirements-08 1494 (work in progress), January 2003. 1496 [16] McPherson, D., Gill, V., Walton, D. and A. Retana, "Border 1497 Gateway Protocol (BGP) Persistent Route Oscillation Condition", 1498 RFC 3345, August 2002. 1500 [17] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 1501 "Multiprotocol Extensions for BGP-4", RFC 2283. 1503 For Internet Draft consistency purposes only 1505 [18] Bradner, S., "The Internet Standards Process -- Revision 3", 1506 RFC 2026, BCP 9, October 1996. 1508 Authors' Addresses 1510 Howard Berkowitz 1511 Gett Communications 1512 5012 S. 25th St 1513 Arlington, VA 22206 1514 USA 1516 Phone: +1 703 998-5819 1517 Fax: +1 703 998-5058 1518 EMail: hcb@gettcomm.com 1520 Elwyn B. Davies 1521 Nortel Networks 1522 Harlow Laboratories 1523 London Road 1524 Harlow, Essex CM17 9NA 1525 UK 1527 Phone: +44 1279 405 498 1528 EMail: elwynd@nortelnetworks.com 1530 Susan Hares 1531 Nexthop Technologies 1532 517 W. William 1533 Ann Arbor, MI 48103 1534 USA 1536 EMail: skh@nexthop.com 1538 Padma Krishnaswamy 1539 SAIC 1540 331 Newman Springs Road 1541 Red Bank, New Jersey 07701 1542 USA 1544 EMail: kri1@earthlink.net 1545 Marianne Lepp 1546 Consultant 1548 EMail: mlepp@lepp.com 1550 Intellectual Property Statement 1552 The IETF takes no position regarding the validity or scope of any 1553 intellectual property or other rights that might be claimed to 1554 pertain to the implementation or use of the technology described in 1555 this document or the extent to which any license under such rights 1556 might or might not be available; neither does it represent that it 1557 has made any effort to identify any such rights. Information on the 1558 IETF's procedures with respect to rights in standards-track and 1559 standards-related documentation can be found in BCP-11. Copies of 1560 claims of rights made available for publication and any assurances of 1561 licenses to be made available, or the result of an attempt made to 1562 obtain a general license or permission for the use of such 1563 proprietary rights by implementors or users of this specification can 1564 be obtained from the IETF Secretariat. 1566 The IETF invites any interested party to bring to its attention any 1567 copyrights, patents or patent applications, or other proprietary 1568 rights which may cover technology that may be required to practice 1569 this standard. Please address the information to the IETF Executive 1570 Director. 1572 Full Copyright Statement 1574 Copyright (C) The Internet Society (2003). All Rights Reserved. 1576 This document and translations of it may be copied and furnished to 1577 others, and derivative works that comment on or otherwise explain it 1578 or assist in its implementation may be prepared, copied, published 1579 and distributed, in whole or in part, without restriction of any 1580 kind, provided that the above copyright notice and this paragraph are 1581 included on all such copies and derivative works. However, this 1582 document itself may not be modified in any way, such as by removing 1583 the copyright notice or references to the Internet Society or other 1584 Internet organizations, except as needed for the purpose of 1585 developing Internet standards in which case the procedures for 1586 copyrights defined in the Internet Standards process must be 1587 followed, or as required to translate it into languages other than 1588 English. 1590 The limited permissions granted above are perpetual and will not be 1591 revoked by the Internet Society or its successors or assignees. 1593 This document and the information contained herein is provided on an 1594 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1595 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1596 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1597 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1598 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1600 Acknowledgement 1602 Funding for the RFC Editor function is currently provided by the 1603 Internet Society.