idnits 2.17.1 draft-ietf-bmwg-conterm-04.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 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 782 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 (March 3, 2003) is 7718 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 1444, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1450, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1465, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1482, 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 (~~), 13 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: September 1, 2003 E. Davies (ed.) 5 Nortel Networks 6 S. Hares 7 Nexthop Technologies 8 P. Krishnaswamy 9 SAIC 10 M. Lepp 11 Consultant 12 A. Retano 13 Cisco Systems, Inc. 14 March 3, 2003 16 Terminology for Benchmarking BGP Device Convergence in the Control 17 Plane 18 draft-ietf-bmwg-conterm-04.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 1, 2003. 42 Copyright Notice 44 Copyright (C) The Internet Society (2003). All Rights Reserved. 46 Abstract 48 This draft establishes terminology to standardize the description of 49 benchmarking methodology for measuring eBGP convergence in the 50 control plane of a single BGP device. Future documents will address 51 iBGP convergence, the initiation of forwarding based on converged 52 control plane information and multiple interacting BGP devices. This 53 terminology is applicable to both IPv4 and IPv6. Illustrative 54 examples of each version are included where relevant. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Overview and Roadmap . . . . . . . . . . . . . . . . . . . . 4 60 1.2 Definition Format . . . . . . . . . . . . . . . . . . . . . 5 61 2. Components and characteristics of Routing information . . . 6 62 2.1 (Network) Prefix . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2 Network Prefix Length . . . . . . . . . . . . . . . . . . . 6 64 2.3 Route . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.4 BGP Route . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.5 Network Level Reachability Information (NLRI) . . . . . . . 8 67 2.6 BGP UPDATE message . . . . . . . . . . . . . . . . . . . . . 8 68 3. Routing Data Structures and Route Categories . . . . . . . . 9 69 3.1 Routing Information Base (RIB) . . . . . . . . . . . . . . . 9 70 3.1.1 Adj-RIB-In and Adj-RIB-Out . . . . . . . . . . . . . . . . . 9 71 3.1.2 Loc-RIB . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2 Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.3 Routing Policy Information Base . . . . . . . . . . . . . . 10 74 3.4 Forwarding Information Base (FIB) . . . . . . . . . . . . . 11 75 3.5 BGP Instance . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.6 BGP Device . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.7 BGP Session . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.8 Active BGP Session . . . . . . . . . . . . . . . . . . . . . 13 79 3.9 BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.10 BGP Neighbor . . . . . . . . . . . . . . . . . . . . . . . . 14 81 3.11 MinRouteAdvertisementInterval (MRAI) . . . . . . . . . . . . 14 82 3.12 MinASOriginationInterval (MAOI) . . . . . . . . . . . . . . 15 83 3.13 Active Route . . . . . . . . . . . . . . . . . . . . . . . . 15 84 3.14 Unique Route . . . . . . . . . . . . . . . . . . . . . . . . 16 85 3.15 Non-Unique Route . . . . . . . . . . . . . . . . . . . . . . 16 86 3.16 Route Instance . . . . . . . . . . . . . . . . . . . . . . . 16 87 4. Constituent elements of a router or network of routers. . . 18 88 4.1 Default Route, Default Free Table, and Full Table . . . . . 18 89 4.1.1 Default Route . . . . . . . . . . . . . . . . . . . . . . . 18 90 4.1.2 Default Free Routing Table . . . . . . . . . . . . . . . . . 18 91 4.1.3 Full Default Free Table . . . . . . . . . . . . . . . . . . 19 92 4.1.4 Default-Free Zone . . . . . . . . . . . . . . . . . . . . . 19 93 4.1.5 Full Provider-Internal Table . . . . . . . . . . . . . . . . 20 94 4.2 Classes of BGP-Speaking Routers . . . . . . . . . . . . . . 20 95 4.2.1 Provider Edge Router . . . . . . . . . . . . . . . . . . . . 20 96 4.2.2 Subscriber Edge Router . . . . . . . . . . . . . . . . . . . 21 97 4.2.3 Inter-provider Border Router . . . . . . . . . . . . . . . . 21 98 4.2.4 Core Router . . . . . . . . . . . . . . . . . . . . . . . . 22 99 5. Characterization of sets of update messages . . . . . . . . 23 100 5.1 Route Packing . . . . . . . . . . . . . . . . . . . . . . . 23 101 5.2 Route Mixture . . . . . . . . . . . . . . . . . . . . . . . 23 102 5.3 Update Train . . . . . . . . . . . . . . . . . . . . . . . . 24 103 5.4 Randomness in Update Trains . . . . . . . . . . . . . . . . 25 104 5.5 Route Flap . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 6. Route Changes and Convergence . . . . . . . . . . . . . . . 27 106 6.1 Route Change Events . . . . . . . . . . . . . . . . . . . . 27 107 6.2 Device Convergence in the Control Plane . . . . . . . . . . 28 108 7. BGP Operation Events . . . . . . . . . . . . . . . . . . . . 30 109 7.1 Hard reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 110 7.2 Soft reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 8. Factors that impact the performance of the convergence 112 process . . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 8.1 General factors affecting device convergence . . . . . . . . 32 114 8.1.1 Number of peers . . . . . . . . . . . . . . . . . . . . . . 32 115 8.1.2 Number of routes per peer . . . . . . . . . . . . . . . . . 32 116 8.1.3 Policy processing/reconfiguration . . . . . . . . . . . . . 32 117 8.1.4 Interactions with other protocols . . . . . . . . . . . . . 32 118 8.1.5 Flap Damping . . . . . . . . . . . . . . . . . . . . . . . . 33 119 8.1.6 Churn . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 8.2 Implementation-specific and other factors affecting BGP 121 convergence . . . . . . . . . . . . . . . . . . . . . . . . 33 122 8.2.1 Forwarded traffic . . . . . . . . . . . . . . . . . . . . . 34 123 8.2.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 124 8.2.3 TCP parameters underlying BGP transport . . . . . . . . . . 34 125 8.2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 126 9. Security Considerations . . . . . . . . . . . . . . . . . . 35 127 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 128 Normative References . . . . . . . . . . . . . . . . . . . . 37 129 Informative References . . . . . . . . . . . . . . . . . . . 38 130 For Internet Draft consistency purposes only . . . . . . . . 39 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 132 Intellectual Property and Copyright Statements . . . . . . . 41 134 1. Introduction 136 This document defines terminology for use in characterizing the 137 convergence performance of BGP processes in routers or other devices 138 that instantiate BGP functionality (see RFC1771 [1]). It is the first 139 part of a two document series, of which the subsequent document will 140 contain the associated tests and methodology. This terminology is 141 applicable to both IPv4 and IPv6. Illustrative examples of each 142 version are included where relevant. Although IPv6 will require the 143 use of MP-BGP, we will not deal with issues related to RFC 2283 [17] 144 in this draft. 146 The following observations underlie the approach adopted in this, and 147 the companion document: 149 o The principal objective is to derive methodologies to standardize 150 conducting and reporting convergence-related measurements for BGP. 152 o It is necessary to remove ambiguity from many frequently used 153 terms that arise in the context of such measurements. 155 o As convergence characterization is a complex process, it is 156 desirable to restrict the initial focus in this set of documents 157 to specifying how to take basic control plane measurements as a 158 first step to characterizing BGP convergence. 160 For path vector protocols, such as BGP, the primary initial focus 161 will therefore be on network and system control-plane activity 162 consisting of the arrival, processing, and propagation of routing 163 information. 165 We note that for testing purposes all optional parameters should be 166 turned off. All variable parameters should be in their default 167 setting unless specified by the test. 169 Subsequent drafts will explore the more intricate aspects of 170 convergence measurement, such as the impacts of the presence of 171 Multiprotocol Extensions for BGP-4, policy processing, simultaneous 172 traffic on the control and data paths within the DUT, and other 173 realistic performance modifiers. Convergence of Interior Gateway 174 Protocols will also be considered in separate drafts. 176 1.1 Overview and Roadmap 178 Characterizations of the BGP convergence performance of a device must 179 take into account all distinct stages and aspects of BGP 180 functionality. This requires that the relevant terms and metrics be 181 as specifically defined as possible. Such definition is the goal of 182 this document. 184 The necessary definitions are classified into separate categories: 186 o Components and characteristics of routing information 188 o Routing data structures and route categories 190 o Descriptions of the constituent elements of a network or a router 191 that is undergoing convergence 193 o Characterization of sets of update messages, types of route change 194 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 [3], and is 202 repeated here for convenience: 204 X.x Term to be defined. (e.g., Latency) 206 Definition: 207 One or more sentences forming the body of the definition. 209 Discussion: 210 A brief discussion of the term, its application and any 211 restrictions that there might be on measurement procedures. 213 Measurement units: 214 The units used to report measurements of this term, if applicable. 216 Issues: 217 List of issues or conditions that could affect this term. 219 See Also: 220 List of related terms that are relevant to the definition or 221 discussion of this term. 223 2. Components and characteristics of Routing information 225 2.1 (Network) Prefix 227 Definition: 228 "A network prefix is a contiguous set of bits at the more 229 significant end of the address that collectively designates the 230 set of systems within a network; host numbers select among those 231 systems." (This definition is taken directly from section 2.2.5.2, 232 "Classless Inter Domain Routing (CIDR)", in [3].) 234 Discussion: 235 In the CIDR context, the network prefix is the network component 236 of an IP address. 238 Measurement Units: N.A. 240 Issues: 242 See Also: 244 2.2 Network Prefix Length 246 Definition: 247 The network prefix length is the number of bits out of the total 248 available in the address field, used to define the network prefix. 250 Discussion: 251 A common alternative to using a bit-wise mask to communicate this 252 component is the use of "slash (/) notation." Slash notation binds 253 the notion of network prefix length in bits to an IP address. 254 E.g., 141.184.128.0/17 indicates the network component of this 255 IPv4 address is 17 bits wide. Similar notation is used for IPv6 256 network prefixes e.g. :FF02:20::/24 258 When referring to groups of addresses, the network prefix length 259 is often used as a means of describing groups of addresses as an 260 equivalence class. For example, 'one hundred /16 addresses' 261 refers to 100 addresses whose network prefix length is 16 bits. 263 Measurement units: bits 265 Issues: 267 See Also: network prefix 269 2.3 Route 271 Definition: 272 In general, a 'route' is the n-tuple 273 276 A route is not end-to-end, but is defined with respect to a 277 specific next hop that will move traffic closer to the destination 278 defined by the prefix. In this usage, a route is the basic unit of 279 information about a target destination distilled from routing 280 protocols. 282 Discussion: 283 This term refers to the concept of a route common to all routing 284 protocols. With reference to the definition above, typical 285 non-routing-protocol attributes would be associated with diffserv 286 or traffic engineering. 288 Measurement Units: N.A. 290 Issues: None. 292 See Also: BGP route 294 2.4 BGP Route 296 Definition: 297 A BGP route is an n-tuple 298 . 300 Discussion: 301 BGP Attributes, such as Nexthop or AS path are defined in RFC 302 1771[1], where they are known as Path Attributes, and are the 303 qualifying data that define the route. 305 From RFC 1771: "For purposes of this protocol a route is defined 306 as a unit of information that pairs a destination with the 307 attributes of a path to that destination" 309 Measurement Units: N.A. 311 Issues: 313 See Also: Route, prefix, Adj-RIB-in, NLRI. 315 2.5 Network Level Reachability Information (NLRI) 317 Definition: 318 The NRLI consists of one or more network prefixes with the same 319 set of path attributes. 321 Discussion: 322 Each prefix in the NLRI is combined with the (common) path 323 attributes to form a BGP route. The NLRI encapsulates a set of 324 destinations to which packets can be routed (from this point in 325 the network) along a common route described by the path 326 attributes. 328 Measurement Units: N.A. 330 Issues: 332 See Also: Route Packing, Network Prefix, BGP Route, NLRI 334 2.6 BGP UPDATE message 336 Definition: 337 An UPDATE message contains an advertisement of a single NLRI 338 field, possibly containing multiple prefixes, and multiple 339 withdrawals of unfeasible routes. See RFC 1771 ([1]) for details. 341 Discussion: 342 From RFC 1771: "A variable length sequence of path attributes is 343 present in every UPDATE. Each path attribute is a triple 344 of variable 345 length." 347 Measurement Units: N.A. 349 See Also 351 3. Routing Data Structures and Route Categories 353 3.1 Routing Information Base (RIB) 355 The RIB collectively consists of a set of logically (not necessarily 356 physically) distinct databases, each of which is enumerated below. 357 The RIB contains all destination prefixes to which the router may 358 forward, and one or more currently reachable next hop addresses for 359 them. 361 Routes included in this set potentially have been selected from 362 several sources of information, including hardware status, interior 363 routing protocols, and exterior routing protocols. RFC 1812 contains 364 a basic set of route selection criteria relevant in an all-source 365 context. Many implementations impose additional criteria. A common 366 implementation-specific criterion is the preference given to 367 different routing information sources. 369 3.1.1 Adj-RIB-In and Adj-RIB-Out 371 Definition: 372 Adj-RIB-In and Adj-RIB-Out are "views" of routing information from 373 the perspective of individual peer routers. 375 The Adj-RIB-In contains information advertised to the DUT by a 376 specific peer. The Adj-RIB-Out contains the information the DUT 377 will advertise to the peer. 379 See RFC 1771[1]. 381 Discussion: 383 Issues: 385 Measurement Units: Number of route instances 387 See Also: 388 Route, BGP Route, Route Instance, Loc-RIB, FIB 390 3.1.2 Loc-RIB 392 Definition: 393 The Loc-RIB contains the set of best routes selected from the 394 various Adj-RIBs, after applying local policies and the BGP route 395 selection algorithm. 397 Discussion: 398 The separation implied between the various RIBs is logical. It 399 does not necessarily follow that these RIBs are distinct and 400 separate entities in any given implementation. 402 Types of routes can include internal BGP, external BGP, interface, 403 static and IGP routes. 405 Issues: 407 Measurement Units: Number of routes 409 See Also: 410 Route, BGP Route, Route Instance, Adj-RIB-in, Adj-RIB-out,FIB 412 3.2 Routing Policy 414 Definition: 415 Routing Policy is "the ability to define conditions for accepting, 416 rejecting, and modifying routes received in advertisements"[9]. 418 Discussion: 419 RFC 1771 [1] further constrains policy to be within the hop-by-hop 420 routing paradigm. Policy is implemented using filters and 421 associated policy actions. Many AS's formulate and document their 422 policies using the Routing Policy Specification Language (RPSL) 423 [6] and then automatically generate configurations for the BGP 424 processes in their routers from the RPSL specifications. 426 Measurement Units: Number of policies; length of policies 428 Issues: 430 See Also: Routing Policy Information Base. 432 3.3 Routing Policy Information Base 434 Definition: 435 A routing policy information base is the set of incoming and 436 outgoing policies. 438 Discussion: 439 All references to the phase of the BGP selection process below are 440 made with respect to RFC 1771 [1] definition of these phases. 442 Incoming policies are applied in Phase 1 of the BGP selection 443 process [1] to the Adj-RIB-In routes to set the metric for the 444 Phase 2 decision process. Outgoing Policies are applied in Phase 445 3 of the BGP process to the Adj-RIB-Out routes preceding route 446 (prefix and path attribute tuple) announcements to a specific 447 peer. 449 Policies in the Policy Information Base have matching and action 450 conditions. Common information to match include route prefixes, 451 AS paths, communities, etc. The action on match may be to drop 452 the update and not pass it to the Loc-RIB, or to modify the update 453 in some way, such as changing local preference (on input) or MED 454 (on output), adding or deleting communities, prepending the 455 current AS in the AS path, etc. 457 The amount of policy processing (both in terms of route maps and 458 filter/access lists) will impact the convergence time and 459 properties of the distributed BGP algorithm. The amount of policy 460 processing may vary from a simple policy which accepts all routes 461 and sends all routes to complex policy with a substantial fraction 462 of the prefixes being filtered by filter/access lists. 464 Measurement Units: Number and length of policies 466 Issues: 468 See Also: 470 3.4 Forwarding Information Base (FIB) 472 Definition: 473 As according to the definition in Appendix B of [4]: "The table 474 containing the information necessary to forward IP Datagrams is 475 called the Forwarding Information Base. At minimum, this contains 476 the interface identifier and next hop information for each 477 reachable destination network prefix." 479 Discussion: 480 The forwarding information base describes a database indexing 481 network prefixes versus router port identifiers. 483 The forwarding information base is distinct from the "routing 484 table" (the Routing Information Base or RIB), which holds all 485 routing information received from routing peers. It is a data 486 plane construct and used for the forwarding of each packet. The 487 Forwarding Information Base is generated from the RIB. For the 488 purposes of this document, the FIB is effectively the subset of 489 the RIB used by the forwarding plane to make per-packet forwarding 490 decisions. 492 Most current implementations have full, non-cached FIBs per router 493 interface. All the route computation and convergence occurs before 494 entries are downloaded into a FIB. 496 Measurement units: N.A. 498 Issues: 500 See Also: Route, RIB 502 3.5 BGP Instance 504 Definition: 505 A BGP instance is a process with a single Loc-RIB. 507 Discussion: 508 For example, a BGP instance would run in routers or test 509 equipment. A test generator acting as multiple peers will 510 typically run more than one instance of BGP. A router would 511 typically run a single instance. 513 Measurement units: N/A 515 Issues: 517 See Also: 519 3.6 BGP Device 521 Definition: 522 A BGP device is a system that has one or more BGP instances 523 running on it, each of which is responsible for executing the BGP 524 state machine. 526 Discussion: 527 We have chosen to use "device" as the general case, to deal with 528 the understood [e.g. [9]] and yet-to-be-invented cases where the 529 control processing may be separate from forwarding [12]. A BGP 530 device may be a traditional router, a route server, a BGP-aware 531 traffic steering device or a non forwarding route reflector. BGP 532 instances such as route reflectors or servers, for example, never 533 forwards traffic, so forwarding-based measurements would be 534 meaningless for it. 536 Measurement units: N/A 538 Issues: 540 See Also: 542 3.7 BGP Session 544 Definition: 545 A BGP session is a session between two BGP instances. 547 Discussion: 549 Measurement units: N/A 551 Issues: 553 See Also: 555 3.8 Active BGP Session 557 Definition: 558 An active BGP session is one which is in the established state. 559 (See RFC 1771 [1]). 561 Discussion: 563 Measurement units: N/A 565 Issues: 567 See Also: 569 3.9 BGP Peer 571 Definition: 572 A BGP peer is another BGP instance to which the Device Under Test 573 (DUT) is in the Established state. (See RFC 1771 [1]). 575 Discussion: 576 In the test scenarios in the methodology discussion that will 577 follow this draft, peers send BGP advertisements to the DUT and 578 receive DUT-originated advertisements. We recommend that the 579 peering relation be established before tests are begun. It might 580 also be interesting to measure the time required to reach the 581 established state. 583 This is a protocol-specific definition, not to be confused with 584 another frequent usage, which refers to the business/economic 585 definition for the exchange of routes without financial 586 compensation. 588 It is worth noting that a BGP peer, by this definition is 589 associated with a BGP peering session, and there may be more than 590 one such active session on a router or on a tester. The peering 591 sessions referred to here may exist between various classes of BGP 592 routers (see Section 4.2). 594 Measurement units: number of BGP peers 596 Issues: 598 See Also: 600 3.10 BGP Neighbor 602 Definition: 603 A BGP neighbor is a device that can be configured as a BGP peer. 605 Discussion: 607 Measurement units: 609 Issues: 611 See Also: 613 3.11 MinRouteAdvertisementInterval (MRAI) 615 Definition: 616 (Paraphrased from 1771[1]) The MRAI timer determines the minimum 617 time between advertisements of routes to a particular destination 618 (prefix) from a single BGP device. The timer is applied on a 619 pre-prefix basis, although the timer is set on a per BGP device 620 basis. 622 Discussion: 623 Given that a BGP instance may manage in excess of 100,000 routes, 624 RFC 1771 allows for a degree of optimization in order to limit the 625 number of timers needed. The MRAI does not apply to routes 626 received from BGP speakers in the same AS or to explicit 627 withdrawals. 629 RFC 1771 also recommends that random jitter is applied to MRAI in 630 an attempt to avoid synchronization effects between the BGP 631 instances in a network. 633 In this document we define routing plane convergence by measuring 634 the time an NLRI is advertised to the DUT to the time it is 635 advertised from the DUT. Clearly any delay inserted by the MRAI 636 will have a significant effect on this measurement. 638 Measurement Units: seconds. 640 Issues: 642 See Also: NLRI, BGP route 644 3.12 MinASOriginationInterval (MAOI) 646 Definition: 647 The MAOI specifies the minimum interval between advertisements of 648 locally originated routes from this BGP instance. 650 Discussion: 651 Random jitter is applied to MAOI in an attempt to avoid 652 synchronization effects between BGP instances in a network. 654 Measurement Units: seconds 656 Issues: 657 It is not known what, if any relationship exists between the 658 settings of MRAI and MAOI. 660 See Also: MRAI, BGP route 662 3.13 Active Route 664 Definition: 665 Route for which there is a FIB entry corresponding to a RIB entry. 667 Discussion: 669 Measurement Units: Number of routes. 671 Issues: 673 See also: RIB. 675 3.14 Unique Route 677 Definition: 678 A unique route is a prefix for which there is just one route 679 instance across all Adj-Ribs-In. 681 Discussion: 683 Measurement Units: N.A. 685 Issues: 687 See Also: route, route instance 689 3.15 Non-Unique Route 691 Definition: 692 A Non-unique route is a prefix for which there is at least one 693 other route in a set including more than one Adj-RIB-in. 695 Discussion: 697 Measurement Units: N.A. 699 Issues: 701 See Also: 702 route, route instance, unique active route. 704 3.16 Route Instance 706 Definition: 707 A route instance is one of several possible occurrences of a route 708 for a particular prefix. 710 Discussion: 711 When a router has multiple peers from which it accepts routes, 712 routes to the same prefix may be received from several peers. This 713 is then an example of multiple route instances. 715 Each route instance is associated with a specific peer. The BGP 716 selection algorithm may reject a specific route instance due to 717 local 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 (not defined) will likely receive more route instances than a 726 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). 746 It should be noted that the references to number of routes in this 747 section document are to routes installed in the loc-RIB and are 748 therefore unique routes, not route instances, and that the total 749 number of route instances may be 4 to 10 times the number of routes. 751 4.1.1 Default Route 753 Definition: 754 A Default Route can match any destination address. If a router 755 does not have a more specific route for a particular packet's 756 destination address, it forwards this packet to the next hop in 757 the default route entry, provided its Forwarding Table (Forwarding 758 Information Base (FIB) contains one. The notation for a default 759 route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or 760 ::/0. 762 Discussion: 764 Measurement units: N.A. 766 Issues: 768 See Also: default free routing table, route, route instance 770 4.1.2 Default Free Routing Table 772 Definition: 773 A default free routing table has no default routes and is 774 typically seen in routers in the core or top tier of routers in 775 the network. 777 Discussion: 778 The term originates from the concept that routers at the core or 779 top tier of the Internet will not be configured with a default 780 route (Notation in IPv4 0.0.0.0/0 and in IPv6 0:0:0:0:0:0:0:0 or 781 ::/0). Thus they will forward every packet to a specific next hop 782 based on the longest match between the destination IP addresse 783 and the routes in the forwarding table. 785 Default free routing table size is commonly used as an indicator 786 of the magnitude of reachable Internet address space. However, 787 default free routing tables may also include routes internal to 788 the router's AS. 790 Measurement Units: The number of routes 792 See Also: Full Default Free, Default Route 794 4.1.3 Full Default Free Table 796 Definition: 797 A full default free table is the union of all sets of default free 798 BGP routes collectively announced by the complete set of 799 autonomous systems making up the public Internet. Due to the 800 dynamic nature of the Internet, the exact size and composition of 801 this table may vary slightly depending where and when it is 802 observed. 804 Discussion: 805 It is generally accepted that a full table, in this usage, does 806 not contain the infrastructure routes or individual sub-aggregates 807 of routes that are otherwise aggregated by the provider before 808 announcement to other autonomous systems. 810 Measurement Units: number of routes 812 Issues: 814 See Also: Routes, Route Instances, Default Route 816 4.1.4 Default-Free Zone 818 Definition: 819 The default-free zone is that part of the Internet backbone that 820 does not have a default route. 822 Discussion: 824 Measurement Units: 826 Issues: 828 See Also: Default Route 830 4.1.5 Full Provider-Internal Table 832 Definition: 833 A full provider-internal table is a superset of the full routing 834 table that contains infrastructure and non- aggregated routes. 836 Discussion: 837 Experience has shown that this table can contain 1.3 to 1.5 times 838 the number of routes in the externally visible full table. Tables 839 of this size, therefore, are a real-world requirement for key 840 internal provider routers. 842 Measurement Units: number of routes 844 Issues: 846 See Also: Routes, Route Instances, Default Route 848 4.2 Classes of BGP-Speaking Routers 850 A given router may perform more than one of the following functions, 851 based on its logical location in the network. 853 4.2.1 Provider Edge Router 855 Definition: 856 A provider edge router is a router at the edge of a provider's 857 network that speaks eBGP to a BGP speaker in another AS. 859 Discussion: 860 The traffic that transits this router may be destined to, or 861 originate from non-contiguous autonomous systems. 863 Such a router will always speak eBGP and may speak iBGP. 865 Measurement units: 867 Issues: 869 See Also: 871 4.2.2 Subscriber Edge Router 873 Definition: 874 A subscriber edge router is router at the edge of the subscriber's 875 network that speaks eBGP to its provider's AS(s). 877 Discussion: 878 The router belongs to an end user organization that may be multi- 879 homed, and which carries traffic only to and from that end user 880 AS. 882 Such a router will always speak eBGP and may speak iBGP. 884 Measurement units: 886 Issues: 888 See Also: 890 4.2.3 Inter-provider Border Router 892 Definition: 893 An inter-provider border router is a BGP speaking router which 894 maintains BGP sessions with otherBGP speaking routers in other 895 providers' ASs. 897 Discussion: 898 Traffic transiting this router may be originated in or destined 899 for another AS that has no direct connectivity with this 900 provider's AS. 902 Such a router will always speak eBGP and may speak iBGP. 904 Measurement units: 906 Issues: 908 See Also: 910 4.2.4 Core Router 912 Definition: 913 An core router is a provider router Internal to the provider's 914 net, speaking iBGP to that provider's edge routers, other intra- 915 provider core routers, or the provider's inter-provider border 916 routers. 918 Discussion: 919 Such a router will always speak iBGP and may speak eBGP. 921 Measurement units: 923 Issues: 924 Then by this definition they aren't core routers. 926 See Also: 928 5. Characterization of sets of update messages 930 This section contains a sequence of definitions that build up to the 931 definition of an Update Train. The Packet train concept was 932 originally introduced by Jain and Routhier [11]. It is here adapted 933 to refer to a train of packets of interest in BGP performance 934 testing. 936 This is a formalization of the sort of test stimulus that is expected 937 as input to a DUT running BGP. This data could be a 938 well-characterized, ordered and timed set of hand-crafted BGP UPDATE 939 packets. It could just as well be a set of BGP UPDATE packets that 940 have been captured from a live router. 942 Characterization of route mixtures and Update Trains is an open area 943 of research. The particular question of interest for this work is 944 the identification of suitable Update Trains, modeled or taken from 945 live traces that reflect realistic sequences of UPDATEs and their 946 contents. 948 5.1 Route Packing 950 Definition: 951 Route packing is the number of route prefixes accommodated in a 952 single Routing Protocol UPDATE Message either as updates 953 (additions or modifications) or withdrawals. 955 Discussion: 956 In general, a routing protocol update may contain more than one 957 prefix. In BGP, a single UPDATE may contain two sets of multiple 958 network prefixes: one set of additions and updates with identical 959 attributes (the NLRI) and one set of unfeasible routes to be 960 withdrawn. 962 Measurement Units: 963 Number of prefixes. 965 Issues: 967 See Also: 968 route, BGP route, route instance, update train, NLRI. 970 5.2 Route Mixture 971 Definition: 972 A route mixture is the demographics of a set of routes. 974 Discussion: 975 A route mixture is the input data for the benchmark. The 976 particular route mixture used as input must be selected to suit 977 the question being asked of the benchmark. Data containing simple 978 route mixtures might be suitable to test the performance limits of 979 the BGP device. 981 Using live data, or input that simulates live data, should improve 982 understanding of how the BGP device will operate in a live 983 network. The data for this kind of test must be route mixtures 984 that model the patterns of arriving control traffic in the live 985 Internet. 987 To accomplish that kind of modeling it is necessary to identify 988 the key parameters that characterize a live Internet route 989 mixture. The parameters and how they interact is an open research 990 problem. However, we identify the following as affecting the 991 route mixture: 993 * Path length distribution 995 * Attribute distribution 997 * Prefix length distribution 999 * Packet packing 1001 * Probability density function of inter-arrival times of 1002 UPDATES 1004 Each of the items above is more complex than a single number. For 1005 example, one could consider the distribution of prefixes by AS or 1006 distribution of prefixes by length. 1008 Measurement Units: Probability density functions 1010 Issues: 1012 See Also: NLRI, RIB. 1014 5.3 Update Train 1015 Definition: 1016 An update train is a set of Routing Protocol UPDATE messages sent 1017 by a router to a BGP peer. 1019 Discussion: 1020 The arrival pattern of UPDATEs can be influenced by many things, 1021 including TCP parameters, hold-down timers, upsteam processing, a 1022 peer coming up or multiple peers sending at the same time. 1023 Network conditions such as a local or remote peer flapping a link 1024 can also affect the arrival pattern. 1026 Measurement units: 1027 Probability density function for the inter-arrival times of UPDATE 1028 packets in the train. 1030 Issues: 1031 Characterizing the profiles of real world UPDATE trains is a 1032 matter for future research. In order to generate realistic UPDATE 1033 trains as test stimuli a formal mathematical scheme or a proven 1034 heuristic is needed to drive the selection of prefixes. Whatever 1035 mechanism is selected it must generate Update trains that have 1036 similar characteristics to those measured in live networks. 1038 See Also: Route Mixture, MRAI, MAOI 1040 5.4 Randomness in Update Trains 1042 As we have seen from the previous sections, an update train used as a 1043 test stimulus has a considerable number of parameters that can be 1044 varied, to a greater or lesser extent, randomly and independently. 1046 A random Update Train will contain: 1048 o A route mixture randomized across 1050 * NLRIs 1052 * updates and withdrawals 1054 * prefixes 1056 * inter-arrival times of the UPDATEs 1058 and possibly across other variables. 1060 This is intended to simulate the unpredictable asynchronous nature of 1061 the network, whereby UPDATE packets may have arbitrary contents and 1062 be delivered at random times. 1064 It is important that the data set be randomized sufficiently to avoid 1065 favoring one vendor's implementation over another's. Specifically, 1066 the distribution of prefixes could be structured to favor the 1067 internal organization of the routes in a particular vendor's 1068 databases. This is to be avoided. 1070 5.5 Route Flap 1072 Definition: 1073 A route flap ia a change of state (withdrawal, announcement, 1074 attribute change) for a route. 1076 Discussion: 1077 Route flapping can be considered a special and pathological case 1078 of update trains. A practical interpretation of what may be 1079 considered excessively rapid is the RIPE 229 [7], which contains 1080 current guidelines on flap damping parameters. 1082 Measurement units: Flapping events per unit time. 1084 Issues: 1085 Specific Flap events can be found in Section 6.1. A bench-marker 1086 should use a mixture of different route change events in testing. 1088 See Also: Route change events, flap damping, packet train 1090 6. Route Changes and Convergence 1092 The following two definitions are central to the benchmarking of 1093 external routing convergence, and so are singled out for more 1094 extensive discussion. 1096 6.1 Route Change Events 1098 A taxonomy characterizing routing information changes seen in 1099 operational networks is proposed in [4] as well as Labovitz et al[5]. 1100 These papers describe BGP protocol-centric events, and event 1101 sequences in the course of an analysis of network behavior. The 1102 terminology in the two papers categorizes similar but slightly 1103 different behaviors with some overlap. We would like to apply these 1104 taxonomies to categorize the tests under definition where possible, 1105 because these tests must tie in to phenomena that arise in actual 1106 networks. We avail ourselves of, or may extend, this terminology as 1107 necessary for this purpose. 1109 A route can be changed implicitly by replacing it with another route 1110 or explicitly by withdrawal followed by the introduction of a new 1111 route. In either case the change may be an actual change, no change, 1112 or a duplicate. The notation and definition of individual 1113 categorizable route change events is adopted from [5] and given 1114 below. 1116 1. AADiff: Implicit withdrawal of a route and replacement by a route 1117 different in some path attribute. 1119 2. AADup: Implicit withdrawal of a route and replacement by route 1120 that is identical in all path attributes. 1122 3. WADiff: Explicit withdrawal of a route and replacement by a 1123 different route. 1125 4. WADup: Explicit withdrawal of a route and replacement by a route 1126 that is identical in all path attributes. 1128 To apply this taxonomy in the benchmarking context, we need both 1129 terms to describe the sequence of events from the update train 1130 perspective, as listed above, and event indications in the time 1131 domain so as to be able to measure activity from the perspective of 1132 the DUT. With this in mind, we incorporate and extend the definitions 1133 of [5] to the following: 1135 1. Tup (TDx): Route advertised to the DUT by Test Device x 1137 2. Tdown(TDx): Route being withdrawn by Device x 1138 3. Tupinit(TDx): The initial announcement of a route to a unique 1139 prefix 1141 4. TWF(TDx): Route fail over after an explicit withdrawal. 1143 But we need to take this a step further. Each of these events can 1144 involve a single route, a "short" packet train, or a "full" routing 1145 table. We further extend the notation to indicate how many routes are 1146 conveyed by the events above: 1148 1. Tup(1,TDx) means Device x sends 1 route 1150 2. Tup(S,TDx) means Device x sends a train, S, of routes 1152 3. Tup(DFT,TDx) means Device x sends an approximation of a full 1153 default-free table. 1155 The basic criterion for selecting a "better" route is the final 1156 tiebreaker defined in RFC1771, the router ID. As a consequence, this 1157 memorandum uses the following descriptor events, which are routes 1158 selected by the BGP selection process rather than simple updates: 1160 1. Tbest -- The current best path. 1162 2. Tbetter -- Advertise a path that is better than Tbest. 1164 3. Tworse -- Advertise a path that is worse than Tbest. 1166 6.2 Device Convergence in the Control Plane 1168 Definition: 1169 A routing device is said to have converged at the point in time 1170 when the DUT has performed all actions in the control plane needed 1171 to react to changes in topology in the context of the test 1172 condition. 1174 Discussion: 1175 For example, when considering BGP convergence, the convergence 1176 resulting from a change that alters the best route instance for a 1177 single prefix at a router would be deemed to have occurred when 1178 this route is advertised to its downstream peers. By way of 1179 contrast, OSPF convergence concludes when SPF calculations have 1180 been performed and the required link states advertised onwards. 1182 The convergence process, in general, can be subdivided into three 1183 distinct phases: 1185 * convergence across the entire Internet, 1187 * convergence within an Autonomous System, 1189 * convergence with respect to a single device. 1191 Convergence with respect to a single device can be 1193 * convergence with regard to data forwarding process(es) 1195 * convergence with regard to the routing process(es), the focus 1196 of this document. 1198 It is the latter, convergence with regard to the routing process, 1199 that we describe in this and the methodology documents. 1201 Because we are trying to benchmark the routing protocol 1202 performance which is only a part of the device overall, this 1203 definition is intended (so far as is possible) to exclude any 1204 additional time such as is needed to download and install the 1205 forwarding information base in the data plane. This definition 1206 should be usable for different families of protocols. 1208 It is of key importance to benchmark the performance of each phase 1209 of convergence separately before proceeding to a composite 1210 characterization of routing convergence, where 1211 implementation-specific dependencies are allowed to interact. 1213 The time resolution needed to measure the device convergence 1214 depends to some extent on the types of the interfaces on the 1215 router. For modern routers with gigabit or faster interfaces, an 1216 individual UPDATE may be processed and re-advertised in very much 1217 less than a millisecond so that time measurements must be made to 1218 a resolution of hundreds to tens of microseconds or better. 1220 Measurement Units: 1221 Time period. 1223 Issues: 1225 See Also: 1227 7. BGP Operation Events 1229 The BGP process(es) in a device might restart because operator 1230 intervention or a power failure caused a complete shut-down. In this 1231 case a hard reset is needed. A peering session could be lost, for 1232 example, because of action on the part of the peer or a dropped tcp 1233 session. A device can reestablish its peers and re-advertise all 1234 relevant routes in a hard reset. However, if a peer is lost, but 1235 the BGP process has not failed, BGP has mechanisms for a "soft 1236 reset." 1238 7.1 Hard reset 1240 Definition: 1241 An event which triggers a complete re-initialization of the 1242 routing tables on one or more BGP sessions, resulting in exchange 1243 of a full routing table on one or more links to the router. 1245 Discussion: 1247 Measurement Units: N/A 1249 Issues: 1251 See Also: 1253 7.2 Soft reset 1255 Definition: 1256 A soft reset is performed on a per-neighbor basis; it does not 1257 clear the BGP session while re-establishing the peering relation 1258 and does not stop the flow of traffic. 1260 Discussion: 1261 There are two methods of performing a soft reset: Graceful restart 1262 [13] where the BGP device that has lost a peer but continues to 1263 forward traffic for a period of time before tearing down the 1264 peer's routes. The alternative method is soft refresh [12], where 1265 a BGP device can request a peer's Adj-RIB-Out. 1267 Measurement Units: N/A 1269 Issues: 1271 See Also: 1273 8. Factors that impact the performance of the convergence process 1275 While this is not a complete list, all of the items discussed below 1276 have a significant affect on BGP convergence. Not all of them can be 1277 addressed in the baseline measurements described in this document. 1279 8.1 General factors affecting device convergence 1281 These factors are conditions of testing external to the router Device 1282 Under Test (DUT). 1284 8.1.1 Number of peers 1286 As the number of peers increases, the BGP route selection algorithm 1287 is increasingly exercised. In addition, the phasing and frequency of 1288 updates from the various peers will have an increasingly marked 1289 effect on the convergence process on a router as the number of peers 1290 grows. Increasing the number of peers also increases the processing 1291 workload for TCP and BGP keepalives. 1293 8.1.2 Number of routes per peer 1295 The number of routes per BGP peer is an obvious stressor to the 1296 convergence process. The number, and relative proportion, of multiple 1297 route instances and distinct routes being added or withdrawn by each 1298 peer will affect the convergence process, as will the mix of 1299 overlapping route instances, and IGP routes. 1301 8.1.3 Policy processing/reconfiguration 1303 The number of routes and attributes being filtered, and set, as a 1304 fraction of the target route table size is another parameter that 1305 will affect BGP convergence. 1307 Extreme examples are 1309 o Minimal Policy: receive all, send all, 1311 o Extensive policy: up to 100% of the total routes have applicable 1312 policy. 1314 8.1.4 Interactions with other protocols 1316 There are interactions in the form of precedence, synchronization, 1317 duplication and the addition of timers, and route selection criteria. 1318 Ultimately, understanding BGP4 convergence must include understanding 1319 of the interactions with both the IGPs and the protocols associated 1320 with the physical media, such as Ethernet, SONET, DWDM. 1322 8.1.5 Flap Damping 1324 A router can use flap damping to respond to route flapping. Use of 1325 flap damping is not mandatory, so the decision to enable the feature, 1326 and to change parameters associated with it, can be considered a 1327 matter of routing policy. 1329 The timers are defined by RFC 2439 [2] and discussed in RIPE-229 [7]. 1330 If this feature is in effect, it requires that the device keep 1331 additional state to carry out the damping, which can have a direct 1332 impact on the control plane due to increased processing. In 1333 addition, flap damping may delay the arrival of real changes in a 1334 route, and affect convergence times 1336 8.1.6 Churn 1338 In theory, a BGP device could receive a set of updates that 1339 completely defined the Internet, and could remain in a steady state, 1340 only sending appropriate keepalives. In practice, the Internet will 1341 always be changing. 1343 Churn refers to control plane processor activity caused by 1344 announcements received and sent by the router. It does not include 1345 keepalives and TCP processing. 1347 Churn is caused by both normal and pathological events. For example, 1348 if an interface of the local router goes down and the associated 1349 prefix is withdrawn, that withdrawal is a normal activity, although 1350 it contributes to churn. If the local device receives a withdrawal 1351 of a route it already advertises, or an announcement of a route it 1352 did not previously know, and re-advertises this information, again 1353 these are normal constituents of churn. Routine updates can range 1354 from single announcement or withdrawals, to announcements of an 1355 entire default-free table. The latter is completely reasonable as an 1356 initialization condition. 1358 Flapping routes are a pathological contributor to churn, as is MED 1359 oscillation [16]. The goal of flap damping is to reduce the 1360 contribution of flapping to churn. 1362 The effect of churn on overall convergence depends on the processing 1363 power available to the control plane, and whether the same 1364 processor(s) are used for forwarding and for control. 1366 8.2 Implementation-specific and other factors affecting BGP convergence 1367 These factors are conditions of testing internal to the Device Under 1368 Test (DUT), although they may affect its interactions with test 1369 devices. 1371 8.2.1 Forwarded traffic 1373 The presence of actual traffic in the device may stress the control 1374 path in some fashion if both the offered load due to data and the 1375 control traffic (FIB updates and downloads as a consequence of 1376 flaps)are excessive. The addition of data traffic presents a more 1377 accurate reflection of realistic operating scenarios than if only 1378 control traffic is present. 1380 8.2.2 Timers 1382 Settings of delay and hold-down timers at the link level as well as 1383 for BGP4, can introduce or ameliorate delays. As part of a test 1384 report, all relevant timers should be reported if they use non- 1385 default value. 1387 8.2.3 TCP parameters underlying BGP transport 1389 Since all BGP traffic and interactions occur over TCP, all relevant 1390 parameters characterizing the TCP sessions should be provided: e.g. 1391 Slow start, max window size, maximum segment size, or timers. 1393 8.2.4 Authentication 1395 Authentication in BGP is currently done using the TCP MD5 Signature 1396 Option [8]. The processing of the MD5 hash, particularly in devices 1397 with a large number of BGP peers and a large amount of update traffic 1398 can have an impact on the control plane of the device. 1400 9. Security Considerations 1402 The document explicitly considers authentication as a performance- 1403 affecting feature, but does not consider the overall security of the 1404 routing system. 1406 10. Acknowledgments 1408 Thanks to Francis Ovenden for review and Abha Ahuja for 1409 encouragement. Much appreciation to Jeff Haas, Matt Richardson, and 1410 Shane Wright at Nexthop for comments and input. Debby Stopp and Nick 1411 Ambrose contributed the concept of route packing. 1413 Normative References 1415 [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 1416 RFC 1771, March 1995. 1418 [2] Villamizar, C., Chandra, R. and R. Govindan , "BGP Route Flap 1419 Damping", RFC 2439, November 1998. 1421 [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 1422 June 1995. 1424 [4] Ahuja, A., Jahanian, F., Bose, A. and C. Labovitz, "An 1425 Experimental Study of Delayed Internet Routing Convergence", 1426 RIPE-37 Presentation to Routing WG, June 2000, . 1430 [5] Labovitz, C., Malan, G. and F. Jahanian, "Origins of Internet 1431 Routing Instability", Infocom 99, August 1999. 1433 [6] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 1434 Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing 1435 Policy Specification Language (RPSL)", RFC 2622, June 1999. 1437 [7] Panigl , C., Schmitz , J., Smith , P. and C. Vistoli, "RIPE 1438 Routing-WG Recommendation for coordinated route-flap damping 1439 parameters, version 2", RIPE 229, October 2001. 1441 [8] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1442 Signature Option", RFC 2385, August 1998. 1444 [9] Juniper Networks, "Junos(tm) Internet Software Configuration 1445 Guide Routing and Routing Protocols, Release 4.2", Junos 4.2 1446 and other releases, September 2000, . 1450 [10] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1451 1999. 1453 [11] Jain, R. and S. Routhier, "Packet trains -- measurement and a 1454 new model for computer network traffic", IEEE Journal on 1455 Selected Areas in Communication 4(6), September 1986. 1457 Informative References 1459 [12] Chen, E., "Route Refresh for BGP-4", RFC 2918, September 2000. 1461 [13] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and E. Chen, 1462 "Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-06 1463 (work in progress), January 2003. 1465 [14] Chen, E. and Y. Rekhter, "Cooperative Route Filtering 1466 Capability for BGP-4", draft-ietf-idr-route-filter-08 (work in 1467 progress), January 2003. 1469 [15] Anderson, T. and H. Khosravi, "Requirements for Separation of 1470 IP Control and Forwarding", draft-ietf-forces-requirements-08 1471 (work in progress), January 2003. 1473 [16] McPherson, D., Gill, V., Walton, D. and A. Retana, "Border 1474 Gateway Protocol (BGP) Persistent Route Oscillation Condition", 1475 RFC 3345, August 2002. 1477 [17] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 1478 "Multiprotocol Extensions for BGP-4", RFC 2283. 1480 For Internet Draft consistency purposes only 1482 [18] Bradner, S., "The Internet Standards Process -- Revision 3", 1483 RFC 2026, BCP 9, October 1996. 1485 Authors' Addresses 1487 Howard Berkowitz 1488 Gett Communications 1489 5012 S. 25th St 1490 Arlington, VA 22206 1491 USA 1493 Phone: +1 703 998-5819 1494 Fax: +1 703 998-5058 1495 EMail: hcb@gettcomm.com 1497 Elwyn B. Davies 1498 Nortel Networks 1499 Harlow Laboratories 1500 London Road 1501 Harlow, Essex CM17 9NA 1502 UK 1504 Phone: +44 1279 405 498 1505 EMail: elwynd@nortelnetworks.com 1507 Susan Hares 1508 Nexthop Technologies 1509 517 W. William 1510 Ann Arbor, MI 48103 1511 USA 1513 EMail: skh@nexthop.com 1515 Padma Krishnaswamy 1516 SAIC 1517 331 Newman Springs Road 1518 Red Bank, New Jersey 07701 1519 USA 1521 EMail: kri1@earthlink.net 1522 Marianne Lepp 1523 Consultant 1525 EMail: mlepp@lepp.com 1527 Alvaro Retana 1528 Cisco Systems, Inc. 1529 7025 Kit Creek Rd. 1530 Research Triangle Park, NC 27709 1531 USA 1533 EMail: aretana@cisco.com 1535 Intellectual Property Statement 1537 The IETF takes no position regarding the validity or scope of any 1538 intellectual property or other rights that might be claimed to 1539 pertain to the implementation or use of the technology described in 1540 this document or the extent to which any license under such rights 1541 might or might not be available; neither does it represent that it 1542 has made any effort to identify any such rights. Information on the 1543 IETF's procedures with respect to rights in standards-track and 1544 standards-related documentation can be found in BCP-11. Copies of 1545 claims of rights made available for publication and any assurances of 1546 licenses to be made available, or the result of an attempt made to 1547 obtain a general license or permission for the use of such 1548 proprietary rights by implementors or users of this specification can 1549 be obtained from the IETF Secretariat. 1551 The IETF invites any interested party to bring to its attention any 1552 copyrights, patents or patent applications, or other proprietary 1553 rights which may cover technology that may be required to practice 1554 this standard. Please address the information to the IETF Executive 1555 Director. 1557 Full Copyright Statement 1559 Copyright (C) The Internet Society (2003). All Rights Reserved. 1561 This document and translations of it may be copied and furnished to 1562 others, and derivative works that comment on or otherwise explain it 1563 or assist in its implementation may be prepared, copied, published 1564 and distributed, in whole or in part, without restriction of any 1565 kind, provided that the above copyright notice and this paragraph are 1566 included on all such copies and derivative works. However, this 1567 document itself may not be modified in any way, such as by removing 1568 the copyright notice or references to the Internet Society or other 1569 Internet organizations, except as needed for the purpose of 1570 developing Internet standards in which case the procedures for 1571 copyrights defined in the Internet Standards process must be 1572 followed, or as required to translate it into languages other than 1573 English. 1575 The limited permissions granted above are perpetual and will not be 1576 revoked by the Internet Society or its successors or assignees. 1578 This document and the information contained herein is provided on an 1579 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1580 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1581 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1582 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1583 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1585 Acknowledgement 1587 Funding for the RFC Editor function is currently provided by the 1588 Internet Society.