idnits 2.17.1 draft-ietf-bmwg-conterm-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1403. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1419), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 45. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 2 instances of too long lines in the document, the longest one being 28 characters in excess of 72. == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 169: '...oses all optional parameters SHOULD be...' RFC 2119 keyword, line 170: '...iable parameters SHOULD be at their de...' RFC 2119 keyword, line 959: '... SHOULD use a mixture of differen...' RFC 2119 keyword, line 1225: '... relevant timers MUST be reported if t...' RFC 2119 keyword, line 1231: '...the TCP sessions MUST be provided: e.g...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 19, 2004) is 7221 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: 'RFC1771' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1269, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-route-filter' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 1325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPE37' -- Possible downref: Non-RFC (?) normative reference: ref. 'INSTBLTY' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIPE229' ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. 'GLSSRY' ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKTTRAIN' == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-10 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-10 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 13 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: January 17, 2005 E. Davies (ed.) 5 Nortel Networks 6 S. Hares 7 Nexthop Technologies 8 P. Krishnaswamy 9 SAIC 10 M. Lepp 11 Consultant 12 July 19, 2004 14 Terminology for Benchmarking BGP Device Convergence in the Control 15 Plane 16 draft-ietf-bmwg-conterm-06.txt 18 Status of this Memo 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 17, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). All Rights Reserved. 47 Abstract 49 This document establishes terminology to standardize the description 50 of benchmarking methodology for measuring eBGP convergence in the 51 control plane of a single BGP device. Future documents will address 52 iBGP convergence, the initiation of forwarding based on converged 53 control plane information and multiple interacting BGP devices. This 54 terminology is applicable to both IPv4 and IPv6. Illustrative 55 examples of each version are included where relevant. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Overview and Roadmap . . . . . . . . . . . . . . . . . . . 4 61 1.2 Definition Format . . . . . . . . . . . . . . . . . . . . 5 62 2. Components and Characteristics of Routing Information . . . . 6 63 2.1 (Network) Prefix . . . . . . . . . . . . . . . . . . . . . 6 64 2.2 Network Prefix Length . . . . . . . . . . . . . . . . . . 6 65 2.3 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4 BGP Route . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.5 Network Level Reachability Information (NLRI) . . . . . . 7 68 2.6 BGP UPDATE Message . . . . . . . . . . . . . . . . . . . . 8 69 3. Routing Data Structures and Route Categories . . . . . . . . . 9 70 3.1 Routing Information Base (RIB) . . . . . . . . . . . . . . 9 71 3.1.1 Adj-RIB-In and Adj-RIB-Out . . . . . . . . . . . . . . 9 72 3.1.2 Loc-RIB . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2 Prefix Filtering . . . . . . . . . . . . . . . . . . . . . 10 74 3.3 Routing Policy . . . . . . . . . . . . . . . . . . . . . . 10 75 3.4 Routing Policy Information Base . . . . . . . . . . . . . 10 76 3.5 Forwarding Information Base (FIB) . . . . . . . . . . . . 11 77 3.6 BGP Instance . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.7 BGP Device . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.8 BGP Session . . . . . . . . . . . . . . . . . . . . . . . 12 80 3.9 Active BGP Session . . . . . . . . . . . . . . . . . . . . 12 81 3.10 BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.11 BGP Neighbor . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.12 MinRouteAdvertisementInterval (MRAI) . . . . . . . . . . . 13 84 3.13 MinASOriginationInterval (MAOI) . . . . . . . . . . . . . 14 85 3.14 Active Route . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.15 Unique Route . . . . . . . . . . . . . . . . . . . . . . . 14 87 3.16 Non-Unique Route . . . . . . . . . . . . . . . . . . . . . 15 88 3.17 Route Instance . . . . . . . . . . . . . . . . . . . . . . 15 89 4. Constituent Elements of a Router or Network of Routers . . . . 16 90 4.1 Default Route, Default Free Table, and Full Table . . . . 16 91 4.1.1 Default Route . . . . . . . . . . . . . . . . . . . . 16 92 4.1.2 Default Free Routing Table . . . . . . . . . . . . . . 16 93 4.1.3 Full Default Free Table . . . . . . . . . . . . . . . 17 94 4.1.4 Default-Free Zone . . . . . . . . . . . . . . . . . . 17 95 4.1.5 Full Provider-Internal Table . . . . . . . . . . . . . 17 96 4.2 Classes of BGP-Speaking Routers . . . . . . . . . . . . . 18 97 4.2.1 Provider Edge Router . . . . . . . . . . . . . . . . . 18 98 4.2.2 Subscriber Edge Router . . . . . . . . . . . . . . . . 18 99 4.2.3 Inter-provider Border Router . . . . . . . . . . . . . 19 100 4.2.4 Core Router . . . . . . . . . . . . . . . . . . . . . 19 101 5. Characterization of Sets of Update Messages . . . . . . . . . 20 102 5.1 Route Packing . . . . . . . . . . . . . . . . . . . . . . 20 103 5.2 Route Mixture . . . . . . . . . . . . . . . . . . . . . . 20 104 5.3 Update Train . . . . . . . . . . . . . . . . . . . . . . . 21 105 5.4 Randomness in Update Trains . . . . . . . . . . . . . . . 22 106 5.5 Route Flap . . . . . . . . . . . . . . . . . . . . . . . . 22 107 6. Route Changes and Convergence . . . . . . . . . . . . . . . . 23 108 6.1 Route Change Events . . . . . . . . . . . . . . . . . . . 23 109 6.2 Device Convergence in the Control Plane . . . . . . . . . 24 110 7. BGP Operation Events . . . . . . . . . . . . . . . . . . . . . 26 111 7.1 Hard Reset . . . . . . . . . . . . . . . . . . . . . . . . 26 112 7.2 Soft Reset . . . . . . . . . . . . . . . . . . . . . . . . 26 113 8. Factors that Impact the Performance of the Convergence 114 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 115 8.1 General Factors Affecting Device Convergence . . . . . . . 27 116 8.1.1 Number of Peers . . . . . . . . . . . . . . . . . . . 27 117 8.1.2 Number of Routes per Peer . . . . . . . . . . . . . . 27 118 8.1.3 Policy Processing/Reconfiguration . . . . . . . . . . 27 119 8.1.4 Interactions with Other Protocols . . . . . . . . . . 27 120 8.1.5 Flap Damping . . . . . . . . . . . . . . . . . . . . . 28 121 8.1.6 Churn . . . . . . . . . . . . . . . . . . . . . . . . 28 122 8.2 Implementation-specific and other Factors Affecting 123 BGP Convergence . . . . . . . . . . . . . . . . . . . . . 28 124 8.2.1 Forwarded Traffic . . . . . . . . . . . . . . . . . . 29 125 8.2.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . 29 126 8.2.3 TCP Parameters Underlying BGP Transport . . . . . . . 29 127 8.2.4 Authentication . . . . . . . . . . . . . . . . . . . . 29 128 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 129 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 130 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 131 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 32 132 11.2 Informative References . . . . . . . . . . . . . . . . . . . 33 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 134 Intellectual Property and Copyright Statements . . . . . . . . 35 136 1. Introduction 138 This document defines terminology for use in characterizing the 139 convergence performance of BGP processes in routers or other devices 140 that instantiate BGP functionality (see 'A Border Gateway Protocol 4 141 (BGP-4)'[RFC1771] referred to as RFC 1771 in the remainder of the 142 document). It is the first part of a two document series, of which 143 the subsequent document will contain the associated tests and 144 methodology. This terminology is applicable to both IPv4 and IPv6. 145 Illustrative examples of each version are included where relevant. 146 However this document is primarily targeted for BGP-4 in IPv4 147 networks. IPv6 will require the use of MP-BGP[RFC2858] as described 148 in RFC 2545[RFC2545] but this document will not address terminology 149 or issues specific to these extensions of BGP-4. Also terminology 150 and issues specific to the extensions of BGP which support VPNs as 151 described in RFC 2547[RFC2547] are out of scope for this document. 153 The following observations underlie the approach adopted in this, and 154 the companion document: 155 o The principal objective is to derive methodologies to standardize 156 conducting and reporting convergence-related measurements for BGP. 157 o It is necessary to remove ambiguity from many frequently used 158 terms that arise in the context of such measurements. 159 o As convergence characterization is a complex process, it is 160 desirable to restrict the initial focus in this set of documents 161 to specifying how to take basic control plane measurements as a 162 first step to characterizing BGP convergence. 164 For path vector protocols, such as BGP, the primary initial focus 165 will therefore be on network and system control-plane activity 166 consisting of the arrival, processing, and propagation of routing 167 information. 169 We note that for testing purposes all optional parameters SHOULD be 170 turned off. All variable parameters SHOULD be at their default 171 setting unless specified by the test. 173 Subsequent drafts will explore the more intricate aspects of 174 convergence measurement, such as the impacts of the presence of 175 Multiprotocol Extensions for BGP-4, policy processing, simultaneous 176 traffic on the control and data paths within the Device Under Test 177 (DUT), and other realistic performance modifiers. Convergence of 178 Interior Gateway Protocols will also be considered in separate 179 drafts. 181 1.1 Overview and Roadmap 183 Characterizations of the BGP convergence performance of a device must 184 take into account all distinct stages and aspects of BGP 185 functionality. This requires that the relevant terms and metrics be 186 as specifically defined as possible. Such definition is the goal of 187 this document. 189 The necessary definitions are classified into separate categories: 190 o Components and characteristics of routing information 191 o Routing data structures and route categories 192 o Descriptions of the constituent elements of a network or a router 193 that is undergoing convergence 194 o Characterization of sets of update messages, types of route change 195 events, as well as some events specific to BGP operation 196 o Descriptions of factors that impact the performance of 197 convergence processes 199 1.2 Definition Format 201 The definition format is equivalent to that defined in 'Requirements 202 for IP Version 4 Routers'[RFC1812], and is repeated here for 203 convenience: 205 X.x Term to be defined. (e.g., Latency) 206 Definition: 207 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. 211 Measurement units: 212 The units used to report measurements of this term. 213 This item may not be applicable (N.A.). 214 Issues: 215 List of issues or conditions that could affect this term. 216 See Also: 217 List of related terms that are relevant to the definition or 218 discussion of this term. 220 2. Components and Characteristics of Routing Information 222 2.1 (Network) Prefix 224 Definition: 225 "A network prefix is a contiguous set of bits at the more 226 significant end of the address that collectively designates the 227 set of systems within a network; host numbers select among those 228 systems." (This definition is taken directly from section 2.2.5.2, 229 "Classless Inter Domain Routing (CIDR)", in RFC 1812.) 230 Discussion: 231 In the CIDR context, the network prefix is the network component 232 of an IP address. 233 In IPv4 systems the network component of a complete address is 234 known as the 'network part' and the remaining part of the address 235 is known as the 'host part'. 236 In IPv6 systems, the network component of a complete address is 237 known as the 'subnet prefix' and the remaining part is known as 238 the 'interface identifier'. 239 Measurement Units: N.A. 240 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 constituting the address field, that defines the network prefix 248 portion of the address. 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 256 When referring to groups of addresses, the network prefix length 257 is often used as a means of describing groups of addresses as an 258 equivalence class. For example, 'one hundred /16 addresses' 259 refers to 100 addresses whose network prefix length is 16 bits. 260 Measurement units: bits 261 Issues: 262 See Also: Network Prefix 264 2.3 Route 265 Definition: 266 In general, a 'route' is the n-tuple 267 269 A route is not end-to-end, but is defined with respect to a 270 specific next hop that should take packets on the next step 271 towards their destination as defined by the prefix. In this 272 usage, a route is the basic unit of information about a target 273 destination distilled from routing protocols. 274 Discussion: 275 This term refers to the concept of a route common to all routing 276 protocols. With reference to the definition above, typical 277 non-routing-protocol attributes would be associated with diffserv 278 or traffic engineering. 279 Measurement Units: N.A. 280 Issues: None. 281 See Also: BGP route 283 2.4 BGP Route 285 Definition: 286 A BGP route is an n-tuple 287 . 288 Discussion: 289 BGP Attributes, such as Nexthop or AS path are defined in RFC 290 1771, where they are known as Path Attributes, and are the 291 qualifying data that define the route. 292 From RFC 1771: "For purposes of this protocol a route is defined 293 as a unit of information that pairs a destination with the 294 attributes of a path to that destination" 295 Measurement Units: N.A. 296 Issues: 297 See Also: Route, prefix, Adj-RIB-in, NLRI. 299 2.5 Network Level Reachability Information (NLRI) 301 Definition: 302 The NLRI consists of one or more network prefixes with the same 303 set of path attributes. 304 Discussion: 305 Each prefix in the NLRI is combined with the (common) path 306 attributes to form a BGP route. The NLRI encapsulates a set of 307 destinations to which packets can be routed (from this point in 308 the network) along a common route described by the path 309 attributes. 311 Measurement Units: N.A. 312 Issues: 313 See Also: Route Packing, Network Prefix, BGP Route, NLRI 315 2.6 BGP UPDATE Message 317 Definition: 318 An UPDATE message contains an advertisement of a single NLRI 319 field, possibly containing multiple prefixes, and multiple 320 withdrawals of unfeasible routes. See RFC 1771 for details. 321 Discussion: 322 From RFC 1771: "A variable length sequence of path attributes is 323 present in every UPDATE. Each path attribute is a triple 324 of variable 325 length." 326 Measurement Units: N.A. 327 See Also 329 3. Routing Data Structures and Route Categories 331 3.1 Routing Information Base (RIB) 333 The RIB collectively consists of a set of logically (not necessarily 334 physically) distinct databases, each of which is enumerated below. 335 The RIB contains all destination prefixes to which the router may 336 forward, and one or more currently reachable next hop addresses for 337 them. 339 Routes included in this set potentially have been selected from 340 several sources of information, including hardware status, interior 341 routing protocols, and exterior routing protocols. RFC 1812 contains 342 a basic set of route selection criteria relevant in an all-source 343 context. Many implementations impose additional criteria. A common 344 implementation-specific criterion is the preference given to 345 different routing information sources. 347 3.1.1 Adj-RIB-In and Adj-RIB-Out 349 Definition: 350 Adj-RIB-In and Adj-RIB-Out are "views" of routing information from 351 the perspective of individual peer routers. 352 The Adj-RIB-In contains information advertised to the DUT by a 353 specific peer. The Adj-RIB-Out contains the information the DUT 354 will advertise to the peer. 355 See RFC 1771. 356 Discussion: 357 Issues: 358 Measurement Units: Number of route instances 359 See Also: 360 Route, BGP Route, Route Instance, Loc-RIB, FIB 362 3.1.2 Loc-RIB 364 Definition: 365 The Loc-RIB contains the set of best routes selected from the 366 various Adj-RIBs, after applying local policies and the BGP route 367 selection algorithm. 368 Discussion: 369 The separation implied between the various RIBs is logical. It 370 does not necessarily follow that these RIBs are distinct and 371 separate entities in any given implementation. 372 Types of routes that need to be considered include internal BGP, 373 external BGP, interface, static and IGP routes. 375 Issues: 376 Measurement Units: Number of routes 377 See Also: 378 Route, BGP Route, Route Instance, Adj-RIB-in, Adj-RIB-out, FIB 380 3.2 Prefix Filtering 382 Definition: 383 Prefix Filtering is a technique for eliminating routes from 384 consideration as candidates for entry into a RIB by matching the 385 network prefix in a BGP Route against a list of network prefixes. 386 Discussion: 387 A BGP Route is eliminated if, for any filter prefix from the list, 388 the Route prefix length is equal to or longer than the filter 389 prefix length and the most significant bits of the two prefixes 390 match over the length of the filter prefix. See 'Cooperative 391 Route Filtering Capability for BGP-4'[I-D.ietf-idr-route-filter] 392 for examples of usage. 393 Measurement Units: Number of filter prefixes; lengths of prefixes 394 Issues: 395 See Also: BGP Route, Network Prefix, Network Prefix Length, Routing 396 Policy, Routing Policy Information Base. 398 3.3 Routing Policy 400 Definition: 401 Routing Policy is "the ability to define conditions for accepting, 402 rejecting, and modifying routes received in 403 advertisements"[GLSSRY]. 404 Discussion: 405 RFC 1771 further constrains policy to be within the hop-by-hop 406 routing paradigm. Policy is implemented using filters and 407 associated policy actions such as Prefix Filtering. Many AS's 408 formulate and document their policies using the Routing Policy 409 Specification Language (RPSL)[RFC2622] and then automatically 410 generate configurations for the BGP processes in their routers 411 from the RPSL specifications. 412 Measurement Units: Number of policies; length of policies 413 Issues: 414 See Also: Routing Policy Information Base, Prefix Filtering. 416 3.4 Routing Policy Information Base 418 Definition: 419 A routing policy information base is the set of incoming and 420 outgoing policies. 422 Discussion: 423 All references to the phase of the BGP selection process below are 424 made with respect to RFC 1771 definition of these phases. 425 Incoming policies are applied in Phase 1 of the BGP selection 426 process to the Adj-RIB-In routes to set the metric for the Phase 2 427 decision process. Outgoing Policies are applied in Phase 3 of the 428 BGP process to the Adj-RIB-Out routes preceding route (prefix and 429 path attribute tuple) announcements to a specific peer. 430 Policies in the Policy Information Base have matching and action 431 conditions. Common information to match include route prefixes, 432 AS paths, communities, etc. The action on match may be to drop 433 the update and not pass it to the Loc-RIB, or to modify the update 434 in some way, such as changing local preference (on input) or MED 435 (on output), adding or deleting communities, prepending the 436 current AS in the AS path, etc. 437 The amount of policy processing (both in terms of route maps and 438 filter/access lists) will impact the convergence time and 439 properties of the distributed BGP algorithm. The amount of policy 440 processing may vary from a simple policy which accepts all routes 441 and sends all routes to complex policy with a substantial fraction 442 of the prefixes being filtered by filter/access lists. 443 Measurement Units: Number and length of policies 444 Issues: 445 See Also: 447 3.5 Forwarding Information Base (FIB) 449 Definition: 450 As according to the definition in Appendix B of RIPE-37[RIPE37]: 451 "The table containing the information necessary to forward IP 452 Datagrams is called the Forwarding Information Base. At minimum, 453 this contains the interface identifier and next hop information 454 for each reachable destination network prefix." 455 Discussion: 456 The forwarding information base describes a database indexing 457 network prefixes versus router port identifiers. 458 The forwarding information base is distinct from the "routing 459 table" (the Routing Information Base or RIB), which holds all 460 routing information received from routing peers. It is a data 461 plane construct and used for the forwarding of each packet. The 462 Forwarding Information Base is generated from the RIB. For the 463 purposes of this document, the FIB is effectively the subset of 464 the RIB used by the forwarding plane to make per-packet forwarding 465 decisions. 466 Most current implementations have full, non-cached FIBs per router 467 interface. All the route computation and convergence occurs 468 before entries are downloaded into a FIB. 470 Measurement units: N.A. 471 Issues: 472 See Also: Route, RIB 474 3.6 BGP Instance 476 Definition: 477 A BGP instance is a process with a single Loc-RIB. 478 Discussion: 479 For example, a BGP instance would run in routers or test 480 equipment. A test generator acting as multiple peers will 481 typically run more than one instance of BGP. A router would 482 typically run a single instance. 483 Measurement units: N/A 484 Issues: 485 See Also: 487 3.7 BGP Device 489 Definition: 490 A BGP device is a system that has one or more BGP instances 491 running on it, each of which is responsible for executing the BGP 492 state machine. 493 Discussion: 494 We have chosen to use "device" as the general case, to deal with 495 the understood (e.g. [GLSSRY]) and yet-to-be-invented cases where 496 the control processing may be separate from forwarding [RFC2918]. 497 A BGP device may be a traditional router, a route server, a 498 BGP-aware traffic steering device or a non forwarding route 499 reflector. BGP instances such as route reflectors or servers, for 500 example, never forwards traffic, so forwarding-based measurements 501 would be meaningless for it. 502 Measurement units: N/A 503 Issues: 504 See Also: 506 3.8 BGP Session 508 Definition: 509 A BGP session is a session between two BGP instances. 510 Discussion: 511 Measurement units: N/A 512 Issues: 513 See Also: 515 3.9 Active BGP Session 516 Definition: 517 An active BGP session is one which is in the established state. 518 (See RFC 1771). 519 Discussion: 520 Measurement units: N/A 521 Issues: 522 See Also: 524 3.10 BGP Peer 526 Definition: 527 A BGP peer is another BGP instance to which the DUT is in the 528 Established state. (See RFC 1771). 529 Discussion: 530 In the test scenarios in the methodology discussion that will 531 follow this document, peers send BGP advertisements to the DUT and 532 receive DUT-originated advertisements. We recommend that the 533 peering relation be established before tests are begun. It might 534 also be interesting to measure the time required to reach the 535 established state. 536 This is a protocol-specific definition, not to be confused with 537 another frequent usage, which refers to the business/economic 538 definition for the exchange of routes without financial 539 compensation. 540 It is worth noting that a BGP peer, by this definition is 541 associated with a BGP peering session, and there may be more than 542 one such active session on a router or on a tester. The peering 543 sessions referred to here may exist between various classes of BGP 544 routers (see Section 4.2). 545 Measurement units: number of BGP peers 546 Issues: 547 See Also: 549 3.11 BGP Neighbor 551 Definition: 552 A BGP neighbor is a device that can be configured as a BGP peer. 553 Discussion: 554 Measurement units: 555 Issues: 556 See Also: 558 3.12 MinRouteAdvertisementInterval (MRAI) 560 Definition: 561 (Paraphrased from RFC 1771) The MRAI timer determines the minimum 562 time between advertisements of routes to a particular destination 563 (prefix) from a single BGP device. The timer is applied on a 564 pre-prefix basis, although the timer is set on a per BGP device 565 basis. 566 Discussion: 567 Given that a BGP instance may manage in excess of 100,000 routes, 568 RFC 1771 allows for a degree of optimization in order to limit the 569 number of timers needed. The MRAI does not apply to routes 570 received from BGP speakers in the same AS or to explicit 571 withdrawals. 572 RFC 1771 also recommends that random jitter is applied to MRAI in 573 an attempt to avoid synchronization effects between the BGP 574 instances in a network. 575 In this document we define routing plane convergence by measuring 576 the time an NLRI is advertised to the DUT to the time it is 577 advertised from the DUT. Clearly any delay inserted by the MRAI 578 will have a significant effect on this measurement. 579 Measurement Units: seconds. 580 Issues: 581 See Also: NLRI, BGP route 583 3.13 MinASOriginationInterval (MAOI) 585 Definition: 586 The MAOI specifies the minimum interval between advertisements of 587 locally originated routes from this BGP instance. 588 Discussion: 589 Random jitter is applied to MAOI in an attempt to avoid 590 synchronization effects between BGP instances in a network. 591 Measurement Units: seconds 592 Issues: 593 It is not known what, if any relationship exists between the 594 settings of MRAI and MAOI. 595 See Also: MRAI, BGP route 597 3.14 Active Route 599 Definition: 600 Route for which there is a FIB entry corresponding to a RIB entry. 601 Discussion: 602 Measurement Units: Number of routes. 603 Issues: 604 See also: RIB. 606 3.15 Unique Route 608 Definition: 609 A unique route is a prefix for which there is just one route 610 instance across all Adj-Ribs-In. 612 Discussion: 613 Measurement Units: N.A. 614 Issues: 615 See Also: route, route instance 617 3.16 Non-Unique Route 619 Definition: 620 A Non-unique route is a prefix for which there is at least one 621 other route in a set including more than one Adj-RIB-in. 622 Discussion: 623 Measurement Units: N.A. 624 Issues: 625 See Also: 626 route, route instance, unique active route. 628 3.17 Route Instance 630 Definition: 631 A route instance is one of several possible occurrences of a route 632 for a particular prefix. 633 Discussion: 634 When a router has multiple peers from which it accepts routes, 635 routes to the same prefix may be received from several peers. 636 This is then an example of multiple route instances. 637 Each route instance is associated with a specific peer. The BGP 638 algorithm that arbitrates between the available candidate route 639 instances may reject a specific route instance due to local 640 policy. 641 Measurement Units: Number of route instances 642 Issues: 643 The number of route instances in the Adj-RIB-in bases will vary 644 based on the function to be performed by a router. An 645 inter-provider border router, located in the default-free zone 646 (see Section 4.1.4) will likely receive more route instances than 647 a provider edge router, located closer to the end-users of the 648 network. 649 See Also: 651 4. Constituent Elements of a Router or Network of Routers 653 Many terms included in this list of definitions were originally 654 described in previous standards or papers. They are included here 655 because of their pertinence to this discussion. Where relevant, 656 reference is made to these sources. An effort has been made to keep 657 this list complete with regard to the necessary concepts without over 658 definition. 660 4.1 Default Route, Default Free Table, and Full Table 662 An individual router's routing table may not necessarily contain a 663 default route. Not having a default route, however, is not 664 synonymous with having a full default-free table(DFT). Also, a 665 router which has a full set of routes as in a DFT but also has a 666 'discard' rule for a default route would not be considered as default 667 free. 669 Note that the references to number of routes in this section document 670 are to routes installed in the loc-RIB and are therefore unique 671 routes, not route instances, and that the total number of route 672 instances may be 4 to 10 times the number of routes. 674 4.1.1 Default Route 676 Definition: 677 A Default Route can match any destination address. If a router 678 does not have a more specific route for a particular packet's 679 destination address, it forwards this packet to the next hop in 680 the default route entry, provided its Forwarding Table (Forwarding 681 Information Base (FIB) contains one). The notation for a default 682 route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or 683 ::/0. 684 Discussion: 685 Measurement units: N.A. 686 Issues: 687 See Also: default free routing table, route, route instance 689 4.1.2 Default Free Routing Table 691 Definition: 692 A default free routing table has no default routes and is 693 typically seen in routers in the core or top tier of routers in 694 the network. 695 Discussion: 696 The term originates from the concept that routers at the core or 697 top tier of the Internet will not be configured with a default 698 route (Notation in IPv4 0.0.0.0/0 and in IPv6 0:0:0:0:0:0:0:0 or 699 ::/0). Thus they will forward every packet to a specific next hop 700 based on the longest match between the destination IP address and 701 the routes in the forwarding table. 702 Default free routing table size is commonly used as an indicator 703 of the magnitude of reachable Internet address space. However, 704 default free routing tables may also include routes internal to 705 the router's AS. 706 Measurement Units: The number of routes 707 See Also: Full Default Free Table, Default Route 709 4.1.3 Full Default Free Table 711 Definition: 712 A full default free table is the union of all sets of BGP routes 713 taken from all the default free BGP routing tables collectively 714 announced by the complete set of autonomous systems making up the 715 public Internet. Due to the dynamic nature of the Internet, the 716 exact size and composition of this table may vary slightly 717 depending where and when it is observed. 718 Discussion: 719 It is generally accepted that a full table, in this usage, does 720 not contain the infrastructure routes or individual sub-aggregates 721 of routes that are otherwise aggregated by the provider before 722 announcement to other autonomous systems. 723 Measurement Units: number of routes 724 Issues: 725 Note: The full default-free routing table is not the same as as 726 the union of all reachable unicast addressesses. The table simply 727 does not contain the default prefix (0/0) and does contain the 728 union of all sets of BGP routes from default free BGP routing 729 tables. 730 See Also: Routes, Route Instances, Default Route 732 4.1.4 Default-Free Zone 734 Definition: 735 The default-free zone is that part of the Internet backbone that 736 does not have a default route. 737 Discussion: 738 Measurement Units: 739 Issues: 740 See Also: Default Route 742 4.1.5 Full Provider-Internal Table 743 Definition: 744 A full provider-internal table is a superset of the full routing 745 table that contains infrastructure and non- aggregated routes. 746 Discussion: 747 Experience has shown that this table might contain 1.3 to 1.5 748 times the number of routes in the externally visible full table. 749 Tables of this size, therefore, are a real-world requirement for 750 key internal provider routers. 751 Measurement Units: number of routes 752 Issues: 753 See Also: Routes, Route Instances, Default Route 755 4.2 Classes of BGP-Speaking Routers 757 A given router may perform more than one of the following functions, 758 based on its logical location in the network. 760 4.2.1 Provider Edge Router 762 Definition: 763 A provider edge router is a router at the edge of a provider's 764 network that speaks eBGP to a BGP speaker in another AS. 765 Discussion: 766 The traffic that transits this router may be destined to, or 767 originate from non-adjacent autonomous systems. In particular the 768 MED values used in the Provider Edge Router would not be visible 769 in the non-adjacent autonomous systems. 770 Such a router will always speak eBGP and may speak iBGP. 771 Measurement units: 772 Issues: 773 See Also: 775 4.2.2 Subscriber Edge Router 777 Definition: 778 A subscriber edge router is router at the edge of the subscriber's 779 network that speaks eBGP to its provider's AS(s). 780 Discussion: 781 The router belongs to an end user organization that may be multi- 782 homed, and which carries traffic only to and from that end user 783 AS. 784 Such a router will always speak eBGP and may speak iBGP. 785 Measurement units: 786 Issues: 787 This definition of an enterprise border router (which is what most 788 Subscriber Edge Routers are) is practical rather than rigorous. 789 It is meant to draw attention to the reality that many enterprises 790 may need a BGP speaker that advertises their own routes and 791 accepts either default alone or partial routes. In such cases, 792 they may be interested in benchmarks that use a partial routing 793 table, to see if a smaller control plane processor will meet their 794 needs. 795 See Also: 797 4.2.3 Inter-provider Border Router 799 Definition: 800 An inter-provider border router is a BGP speaking router which 801 maintains BGP sessions with other BGP speaking routers in other 802 providers' ASs. 803 Discussion: 804 Traffic transiting this router may be originated in or destined 805 for another AS that has no direct connectivity with this 806 provider's AS. 807 Such a router will always speak eBGP and may speak iBGP. 808 Measurement units: 809 Issues: 810 See Also: 812 4.2.4 Core Router 814 Definition: 815 An core router is a provider router Internal to the provider's 816 net, speaking iBGP to that provider's edge routers, other intra- 817 provider core routers, or the provider's inter-provider border 818 routers. 819 Discussion: 820 Such a router will always speak iBGP and may speak eBGP. 821 Measurement units: 822 Issues: 823 Then by this definition the DUT's which are eBGP routers aren't 824 core routers. 825 See Also: 827 5. Characterization of Sets of Update Messages 829 This section contains a sequence of definitions that build up to the 830 definition of an Update Train. The Packet train concept was 831 originally introduced by Jain and Routhier[PKTTRAIN]. It is here 832 adapted to refer to a train of packets of interest in BGP performance 833 testing. 835 This is a formalization of the sort of test stimulus that is expected 836 as input to a DUT running BGP. This data could be a 837 well-characterized, ordered and timed set of hand-crafted BGP UPDATE 838 packets. It could just as well be a set of BGP UPDATE packets that 839 have been captured from a live router. 841 Characterization of route mixtures and Update Trains is an open area 842 of research. The particular question of interest for this work is 843 the identification of suitable Update Trains, modeled or taken from 844 live traces that reflect realistic sequences of UPDATEs and their 845 contents. 847 5.1 Route Packing 849 Definition: 850 Route packing is the number of route prefixes accommodated in a 851 single Routing Protocol UPDATE Message either as updates 852 (additions or modifications) or withdrawals. 853 Discussion: 854 In general, a routing protocol update may contain more than one 855 prefix. In BGP, a single UPDATE may contain two sets of multiple 856 network prefixes: one set of additions and updates with identical 857 attributes (the NLRI) and one set of unfeasible routes to be 858 withdrawn. 859 Measurement Units: 860 Number of prefixes. 861 Issues: 862 See Also: 863 route, BGP route, route instance, update train, NLRI. 865 5.2 Route Mixture 867 Definition: 868 A route mixture is the demographics of a set of routes. 869 Discussion: 870 A route mixture is the input data for the benchmark. The 871 particular route mixture used as input must be selected to suit 872 the question being asked of the benchmark. Data containing simple 873 route mixtures might be suitable to test the performance limits of 874 the BGP device. 876 Using live data, or input that simulates live data, will improve 877 understanding of how the BGP device will operate in a live 878 network. The data for this kind of test must be route mixtures 879 that model the patterns of arriving control traffic in the live 880 Internet. 881 To accomplish that kind of modeling it is necessary to identify 882 the key parameters that characterize a live Internet route 883 mixture. The parameters and how they interact is an open research 884 problem. However, we identify the following as affecting the 885 route mixture: 886 * Path length distribution 887 * Attribute distribution 888 * Prefix length distribution 889 * Packet packing 890 * Probability density function of inter-arrival times of 891 UPDATES 892 Each of the items above is more complex than a single number. For 893 example, one could consider the distribution of prefixes by AS or 894 distribution of prefixes by length. 895 Measurement Units: Probability density functions 896 Issues: 897 See Also: NLRI, RIB. 899 5.3 Update Train 901 Definition: 902 An update train is a set of Routing Protocol UPDATE messages sent 903 by a router to a BGP peer. 904 Discussion: 905 The arrival pattern of UPDATEs can be influenced by many things, 906 including TCP parameters, hold-down timers, upsteam processing, a 907 peer coming up or multiple peers sending at the same time. 908 Network conditions such as a local or remote peer flapping a link 909 can also affect the arrival pattern. 910 Measurement units: 911 Probability density function for the inter-arrival times of UPDATE 912 packets in the train. 913 Issues: 914 Characterizing the profiles of real world UPDATE trains is a 915 matter for future research. In order to generate realistic UPDATE 916 trains as test stimuli a formal mathematical scheme or a proven 917 heuristic is needed to drive the selection of prefixes. Whatever 918 mechanism is selected it must generate Update trains that have 919 similar characteristics to those measured in live networks. 920 See Also: Route Mixture, MRAI, MAOI 922 5.4 Randomness in Update Trains 924 As we have seen from the previous sections, an update train used as a 925 test stimulus has a considerable number of parameters that can be 926 varied, to a greater or lesser extent, randomly and independently. 928 A random Update Train will contain: 929 o A route mixture randomized across 930 * NLRIs 931 * updates and withdrawals 932 * prefixes 933 * inter-arrival times of the UPDATEs 934 and possibly across other variables. 936 This is intended to simulate the unpredictable asynchronous nature of 937 the network, whereby UPDATE packets may have arbitrary contents and 938 be delivered at random times. 940 It is important that the data set be randomized sufficiently to avoid 941 favoring one vendor's implementation over another's. Specifically, 942 the distribution of prefixes could be structured to favor the 943 internal organization of the routes in a particular vendor's 944 databases. This is to be avoided. 946 5.5 Route Flap 948 Definition: 949 A route flap ia a change of state (withdrawal, announcement, 950 attribute change) for a route. 951 Discussion: 952 Route flapping can be considered a special and pathological case 953 of update trains. A practical interpretation of what may be 954 considered excessively rapid is the RIPE 229[RIPE229], which 955 contains current guidelines on flap damping parameters. 956 Measurement units: Flapping events per unit time. 957 Issues: 958 Specific Flap events can be found in Section 6.1. A bench-marker 959 SHOULD use a mixture of different route change events in testing. 960 See Also: Route change events, flap damping, packet train 962 6. Route Changes and Convergence 964 The following two definitions are central to the benchmarking of 965 external routing convergence, and so are singled out for more 966 extensive discussion. 968 6.1 Route Change Events 970 A taxonomy characterizing routing information changes seen in 971 operational networks is proposed in RIPE-37[RIPE37] as well as 972 Labovitz et al[INSTBLTY]. These papers describe BGP protocol-centric 973 events, and event sequences in the course of an analysis of network 974 behavior. The terminology in the two papers categorizes similar but 975 slightly different behaviors with some overlap. We would like to 976 apply these taxonomies to categorize the tests under definition where 977 possible, because these tests must tie in to phenomena that arise in 978 actual networks. We avail ourselves of, or may extend, this 979 terminology as necessary for this purpose. 981 A route can be changed implicitly by replacing it with another route 982 or explicitly by withdrawal followed by the introduction of a new 983 route. In either case the change may be an actual change, no change, 984 or a duplicate. The notation and definition of individual 985 categorizable route change events is adopted from [INSTBLTY] and 986 given below. 987 1. AADiff: Implicit withdrawal of a route and replacement by a route 988 different in some path attribute. 989 2. AADup: Implicit withdrawal of a route and replacement by route 990 that is identical in all path attributes. 991 3. WADiff: Explicit withdrawal of a route and replacement by a 992 different route. 993 4. WADup: Explicit withdrawal of a route and replacement by a route 994 that is identical in all path attributes. 996 To apply this taxonomy in the benchmarking context, we need both 997 terms to describe the sequence of events from the update train 998 perspective, as listed above, and event indications in the time 999 domain so as to be able to measure activity from the perspective of 1000 the DUT. With this in mind, we incorporate and extend the 1001 definitions of [INSTBLTY] to the following: 1002 1. Tup (TDx): Route advertised to the DUT by Test Device x 1003 2. Tdown(TDx): Route being withdrawn by Device x 1004 3. Tupinit(TDx): The initial announcement of a route to a unique 1005 prefix 1006 4. TWF(TDx): Route fail over after an explicit withdrawal. 1008 But we need to take this a step further. Each of these events can 1009 involve a single route, a "short" packet train, or a "full" routing 1010 table. We further extend the notation to indicate how many routes 1011 are conveyed by the events above: 1012 1. Tup(1,TDx) means Device x sends 1 route 1013 2. Tup(S,TDx) means Device x sends a train, S, of routes 1014 3. Tup(DFT,TDx) means Device x sends an approximation of a full 1015 default-free table. 1017 The basic criterion for selecting a "better" route is the final 1018 tiebreaker defined in RFC 1771, the router ID. As a consequence, 1019 this memorandum uses the following descriptor events, which are 1020 routes selected by the BGP selection process rather than simple 1021 updates: 1022 1. Tbest -- The current best path. 1023 2. Tbetter -- Advertise a path that is better than Tbest. 1024 3. Tworse -- Advertise a path that is worse than Tbest. 1026 6.2 Device Convergence in the Control Plane 1028 Definition: 1029 A routing device is said to have converged at the point in time 1030 when the DUT has performed all actions in the control plane needed 1031 to react to changes in topology in the context of the test 1032 condition. 1033 Discussion: 1034 For example, when considering BGP convergence, the convergence 1035 resulting from a change that alters the best route instance for a 1036 single prefix at a router would be deemed to have occurred when 1037 this route is advertised to its downstream peers. By way of 1038 contrast, OSPF convergence concludes when SPF calculations have 1039 been performed and the required link states advertised onwards. 1040 The convergence process, in general, can be subdivided into three 1041 distinct phases: 1042 * convergence across the entire Internet, 1043 * convergence within an Autonomous System, 1044 * convergence with respect to a single device. 1045 Convergence with respect to a single device can be 1046 * convergence with regard to data forwarding process(es) 1047 * convergence with regard to the routing process(es), the focus 1048 of this document. 1049 It is the latter, convergence with regard to the routing process, 1050 that we describe in this and the methodology documents. 1051 Because we are trying to benchmark the routing protocol 1052 performance which is only a part of the device overall, this 1053 definition is intended (so far as is possible) to exclude any 1054 additional time such as is needed to download and install the 1055 forwarding information base in the data plane. This definition is 1056 usable for different families of protocols. 1058 It is of key importance to benchmark the performance of each phase 1059 of convergence separately before proceeding to a composite 1060 characterization of routing convergence, where 1061 implementation-specific dependencies are allowed to interact. 1062 Care also needs to be taken to ensure that the convergence time is 1063 not influenced by policy processing on downstream peers. 1064 The time resolution needed to measure the device convergence 1065 depends to some extent on the types of the interfaces on the 1066 router. For modern routers with gigabit or faster interfaces, an 1067 individual UPDATE may be processed and re-advertised in very much 1068 less than a millisecond so that time measurements must be made to 1069 a resolution of hundreds to tens of microseconds or better. 1070 Measurement Units: 1071 Time period. 1072 Issues: 1073 See Also: 1075 7. BGP Operation Events 1077 The BGP process(es) in a device might restart because operator 1078 intervention or a power failure caused a complete shut-down. In this 1079 case a hard reset is needed. A peering session could be lost, for 1080 example, because of action on the part of the peer or a dropped tcp 1081 session. A device can reestablish its peers and re-advertise all 1082 relevant routes in a hard reset. However, if a peer is lost, but 1083 the BGP process has not failed, BGP has mechanisms for a "soft 1084 reset." 1086 7.1 Hard Reset 1088 Definition: 1089 An event which triggers a complete re-initialization of the 1090 routing tables on one or more BGP sessions, resulting in exchange 1091 of a full routing table on one or more links to the router. 1092 Discussion: 1093 Measurement Units: N/A 1094 Issues: 1095 See Also: 1097 7.2 Soft Reset 1099 Definition: 1100 A soft reset is performed on a per-neighbor basis; it does not 1101 clear the BGP session while re-establishing the peering relation 1102 and does not stop the flow of traffic. 1103 Discussion: 1104 There are two methods of performing a soft reset: Graceful 1105 restart[I-D.ietf-idr-restart] where the BGP device that has lost a 1106 peer but continues to forward traffic for a period of time before 1107 tearing down the peer's routes. The alternative method is soft 1108 refresh[RFC2918], where a BGP device can request a peer's 1109 Adj-RIB-Out. 1110 Measurement Units: N/A 1111 Issues: 1112 See Also: 1114 8. Factors that Impact the Performance of the Convergence Process 1116 While this is not a complete list, all of the items discussed below 1117 have a significant affect on BGP convergence. Not all of them can be 1118 addressed in the baseline measurements described in this document. 1120 8.1 General Factors Affecting Device Convergence 1122 These factors are conditions of testing external to the router Device 1123 Under Test (DUT). 1125 8.1.1 Number of Peers 1127 As the number of peers increases, the BGP route selection algorithm 1128 is increasingly exercised. In addition, the phasing and frequency of 1129 updates from the various peers will have an increasingly marked 1130 effect on the convergence process on a router as the number of peers 1131 grows, depending on the quantity of updates that is generated by each 1132 additional peer. Increasing the number of peers also increases the 1133 processing workload for TCP and BGP keepalives. 1135 8.1.2 Number of Routes per Peer 1137 The number of routes per BGP peer is an obvious stressor to the 1138 convergence process. The number, and relative proportion, of 1139 multiple route instances and distinct routes being added or withdrawn 1140 by each peer will affect the convergence process, as will the mix of 1141 overlapping route instances, and IGP routes. 1143 8.1.3 Policy Processing/Reconfiguration 1145 The number of routes and attributes being filtered, and set, as a 1146 fraction of the target route table size is another parameter that 1147 will affect BGP convergence. 1149 Extreme examples are 1150 o Minimal Policy: receive all, send all, 1151 o Extensive policy: up to 100% of the total routes have applicable 1152 policy. 1154 8.1.4 Interactions with Other Protocols 1156 There are interactions in the form of precedence, synchronization, 1157 duplication and the addition of timers, and route selection criteria. 1158 Ultimately, understanding BGP4 convergence must include understanding 1159 of the interactions with both the IGPs and the protocols associated 1160 with the physical media, such as Ethernet, SONET, DWDM. 1162 8.1.5 Flap Damping 1164 A router can use flap damping to respond to route flapping. Use of 1165 flap damping is not mandatory, so the decision to enable the feature, 1166 and to change parameters associated with it, can be considered a 1167 matter of routing policy. 1169 The timers are defined by RFC 2439[RFC2439] and discussed in 1170 RIPE-229[RIPE229]. If this feature is in effect, it requires that 1171 the device keep additional state to carry out the damping, which can 1172 have a direct impact on the control plane due to increased 1173 processing. In addition, flap damping may delay the arrival of real 1174 changes in a route, and affect convergence times 1176 8.1.6 Churn 1178 In theory, a BGP device could receive a set of updates that 1179 completely defined the Internet, and could remain in a steady state, 1180 only sending appropriate keepalives. In practice, the Internet will 1181 always be changing. 1183 Churn refers to control plane processor activity caused by 1184 announcements received and sent by the router. It does not include 1185 keepalives and TCP processing. 1187 Churn is caused by both normal and pathological events. For example, 1188 if an interface of the local router goes down and the associated 1189 prefix is withdrawn, that withdrawal is a normal activity, although 1190 it contributes to churn. If the local device receives a withdrawal 1191 of a route it already advertises, or an announcement of a route it 1192 did not previously know, and re-advertises this information, again 1193 these are normal constituents of churn. Routine updates can range 1194 from single announcement or withdrawals, to announcements of an 1195 entire default-free table. The latter is completely reasonable as an 1196 initialization condition. 1198 Flapping routes are a pathological contributor to churn, as is MED 1199 oscillation [RFC3345]. The goal of flap damping is to reduce the 1200 contribution of flapping to churn. 1202 The effect of churn on overall convergence depends on the processing 1203 power available to the control plane, and whether the same 1204 processor(s) are used for forwarding and for control. 1206 8.2 Implementation-specific and other Factors Affecting BGP Convergence 1208 These factors are conditions of testing internal to the Device Under 1209 Test (DUT), although they may affect its interactions with test 1210 devices. 1212 8.2.1 Forwarded Traffic 1214 The presence of actual traffic in the device may stress the control 1215 path in some fashion if both the offered load due to data and the 1216 control traffic (FIB updates and downloads as a consequence of flaps) 1217 are excessive. The addition of data traffic presents a more accurate 1218 reflection of realistic operating scenarios than if only control 1219 traffic is present. 1221 8.2.2 Timers 1223 Settings of delay and hold-down timers at the link level as well as 1224 for BGP4, can introduce or ameliorate delays. As part of a test 1225 report, all relevant timers MUST be reported if they use non- default 1226 value. 1228 8.2.3 TCP Parameters Underlying BGP Transport 1230 Since all BGP traffic and interactions occur over TCP, all relevant 1231 parameters characterizing the TCP sessions MUST be provided: e.g. 1232 Slow start, max window size, maximum segment size, or timers. 1234 8.2.4 Authentication 1236 Authentication in BGP is currently done using the TCP MD5 Signature 1237 Option [RFC2385]. The processing of the MD5 hash, particularly in 1238 devices with a large number of BGP peers and a large amount of update 1239 traffic can have an impact on the control plane of the device. 1241 9. Security Considerations 1243 The document explicitly considers authentication as a performance- 1244 affecting feature, but does not consider the overall security of the 1245 routing system. 1247 10. Acknowledgments 1249 Thanks to Francis Ovenden for review and Abha Ahuja for 1250 encouragement. Much appreciation to Jeff Haas, Matt Richardson, and 1251 Shane Wright at Nexthop for comments and input. Debby Stopp and Nick 1252 Ambrose contributed the concept of route packing. 1254 Alvaro Retana was a key member of the team that developed this 1255 document, and made significant technical contributions regarding 1256 route mixes. The team thanks him and regards him as a co-author in 1257 spirit. 1259 11. References 1261 11.1 Normative References 1263 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 1264 (BGP-4)", RFC 1771, March 1995. 1266 [RFC2439] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route 1267 Flap Damping", RFC 2439, November 1998. 1269 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1270 1812, June 1995. 1272 [RIPE37] Ahuja, A., Jahanian, F., Bose, A. and C. Labovitz, "An 1273 Experimental Study of Delayed Internet Routing 1274 Convergence", RIPE-37 Presentation to Routing WG, November 1275 2000, 1276 1277 . 1279 [INSTBLTY] 1280 Labovitz, C., Malan, G. and F. Jahanian, "Origins of 1281 Internet Routing Instability", Infocom 99, August 1999. 1283 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1284 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, 1285 "Routing Policy Specification Language (RPSL)", RFC 2622, 1286 June 1999. 1288 [RIPE229] Panigl , C., Schmitz , J., Smith , P. and C. Vistoli, 1289 "RIPE Routing-WG Recommendation for coordinated route-flap 1290 damping parameters, version 2", RIPE 229, October 2001. 1292 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1293 Signature Option", RFC 2385, August 1998. 1295 [GLSSRY] Juniper Networks, "Junos(tm) Internet Software 1296 Configuration Guide Routing and Routing Protocols, Release 1297 4.2", Junos 4.2 and other releases, September 2000, 1298 1299 . 1301 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1302 1999. 1304 [PKTTRAIN] 1305 Jain, R. and S. Routhier, "Packet trains -- measurement 1306 and a new model for computer network traffic", IEEE 1307 Journal on Selected Areas in Communication 4(6), September 1308 1986. 1310 11.2 Informative References 1312 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 1313 September 2000. 1315 [I-D.ietf-idr-restart] 1316 Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. 1317 Chen, "Graceful Restart Mechanism for BGP", 1318 draft-ietf-idr-restart-10 (work in progress), June 2004. 1320 [I-D.ietf-idr-route-filter] 1321 Chen, E. and Y. Rekhter, "Cooperative Route Filtering 1322 Capability for BGP-4", draft-ietf-idr-route-filter-10 1323 (work in progress), March 2004. 1325 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1326 of IP Control and Forwarding", RFC 3654, November 2003. 1328 [RFC3345] McPherson, D., Gill, V., Walton, D. and A. Retana, "Border 1329 Gateway Protocol (BGP) Persistent Route Oscillation 1330 Condition", RFC 3345, August 2002. 1332 [RFC2858] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 1333 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1335 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1336 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1337 1999. 1339 Authors' Addresses 1341 Howard Berkowitz 1342 Gett Communications 1343 5012 S. 25th St 1344 Arlington, VA 22206 1345 USA 1347 Phone: +1 703 998-5819 1348 Fax: +1 703 998-5058 1349 EMail: hcb@gettcomm.com 1350 Elwyn B. Davies 1351 Nortel Networks 1352 Harlow Laboratories 1353 London Road 1354 Harlow, Essex CM17 9NA 1355 UK 1357 Phone: +44 1279 405 498 1358 EMail: elwynd@nortelnetworks.com 1360 Susan Hares 1361 Nexthop Technologies 1362 825 Victors Way 1363 Ann Arbor, MI 48108 1364 USA 1366 EMail: skh@nexthop.com 1368 Padma Krishnaswamy 1369 SAIC 1370 331 Newman Springs Road 1371 Red Bank, New Jersey 07701 1372 USA 1374 EMail: kri1@earthlink.net 1376 Marianne Lepp 1377 Consultant 1379 EMail: mlepp@lepp.com 1381 Intellectual Property Statement 1383 The IETF takes no position regarding the validity or scope of any 1384 Intellectual Property Rights or other rights that might be claimed to 1385 pertain to the implementation or use of the technology described in 1386 this document or the extent to which any license under such rights 1387 might or might not be available; nor does it represent that it has 1388 made any independent effort to identify any such rights. Information 1389 on the procedures with respect to rights in RFC documents can be 1390 found in BCP 78 and BCP 79. 1392 Copies of IPR disclosures made to the IETF Secretariat and any 1393 assurances of licenses to be made available, or the result of an 1394 attempt made to obtain a general license or permission for the use of 1395 such proprietary rights by implementers or users of this 1396 specification can be obtained from the IETF on-line IPR repository at 1397 http://www.ietf.org/ipr. 1399 The IETF invites any interested party to bring to its attention any 1400 copyrights, patents or patent applications, or other proprietary 1401 rights that may cover technology that may be required to implement 1402 this standard. Please address the information to the IETF at 1403 ietf-ipr@ietf.org. 1405 Disclaimer of Validity 1407 This document and the information contained herein are provided on an 1408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1415 Copyright Statement 1417 Copyright (C) The Internet Society (2004). This document is subject 1418 to the rights, licenses and restrictions contained in BCP 78, and 1419 except as set forth therein, the authors retain all their rights. 1421 Acknowledgment 1423 Funding for the RFC Editor function is currently provided by the 1424 Internet Society.