idnits 2.17.1 draft-ietf-idr-bgp-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC1264], [RFC1774]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 2003) is 7713 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1774' is mentioned on line 45, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'KUZINGER' ** Obsolete normative reference: RFC 1105 (Obsoleted by RFC 1163) -- Duplicate reference: RFC1105, mentioned in 'RFC1163', was also mentioned in 'RFC1105'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC1163') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1264 (Obsoleted by RFC 4794) -- Duplicate reference: RFC1105, mentioned in 'RFC1267', was also mentioned in 'RFC1163'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC1267') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ROUTEVIEWS' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT David Meyer 2 draft-ietf-idr-bgp-analysis-00.txt Keyur Patel 3 Category Informational 4 Expires: September 2003 March 2003 6 BGP-4 Protocol Analysis 7 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of an individual. Comments are solicited 31 and should be addressed to the author(s). 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The purpose of this report is to document how the requirements for 40 advancing a routing protocol from Draft Standard to full Standard 41 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 43 This report satisfies the requirement for "the second report", as 44 described in Section 6.0 of RFC 1264 [RFC1264]. In order to fulfill 45 the requirement, this report augments RFC 1774 [RFC1774] and 46 summarizes the key features of BGP protocol, and analyzes the 47 protocol with respect to scaling and performance. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Key Features and algorithms of the BGP-4 53 protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Key Features. . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. BGP Algorithms. . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3. BGP Finite State Machine (FSM). . . . . . . . . . . . . . . 6 57 3. BGP Performance characteristics and Scalability. . . . . . . . 6 58 3.1. Link bandwidth and CPU utilization. . . . . . . . . . . . . 7 59 3.1.1. CPU utilization. . . . . . . . . . . . . . . . . . . . . 8 60 3.1.2. Memory requirements. . . . . . . . . . . . . . . . . . . 9 61 4. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 12 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 65 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 BGP-4 is an inter-autonomous system routing protocol designed for 70 TCP/IP internets. Version 1 of the BGP protocol was published in RFC 71 1105 [RFC1105]. Since then BGP versions 2, 3, and 4 have been 72 developed. Version 2 was documented in RFC 1163 [RFC1163]. Version 3 73 is documented in RFC 1267 [RFC1267]. Version 4 is documented in the 74 [BGP4]. The changes between versions are explained in Appendix A of 75 [BGP4]. Possible applications of BGP in the Internet are documented 76 in [RFC1772]. 78 2. Key Features and algorithms of the BGP-4 protocol 80 This section summarizes the key features and algorithms of the BGP 81 protocol. BGP is an inter-autonomous system routing protocol; it is 82 designed to be used between multiple autonomous systems. BGP assumes 83 that routing within an autonomous system is done by an intra- 84 autonomous system routing protocol. BGP does not make any assumptions 85 about intra-autonomous system routing protocols deployed within the 86 various autonomous systems. Specifically, BGP does not require all 87 autonomous systems to run the same intra-autonomous system routing 88 protocol (i.e., interior gateway protocol or IGP). 90 Finally, note that BGP is a real inter-autonomous system routing 91 protocol, and as such it imposes no constraints on the underlying 92 Internet topology. The information exchanged via BGP is sufficient to 93 construct a graph of autonomous systems connectivity from which 94 routing loops may be pruned and many routing policy decisions at the 95 autonomous system level may be enforced. 97 2.1. Key Features 99 The key features of the protocol are the notion of path attributes 100 and aggregation of network layer reachability information (NLRI). 101 Path attributes provide BGP with flexibility and expandability. Path 102 attributes are partitioned into well-known and optional. The 103 provision for optional attributes allows experimentation that may 104 involve a group of BGP routers without affecting the rest of the 105 Internet. New optional attributes can be added to the protocol in 106 much the same way that new options are added to, say, the Telnet 107 protocol [RFC854]. 109 One of the most important path attributes is the AS-PATH. As 110 reachability information traverses the Internet, this information is 111 augmented by the list of autonomous systems that have been traversed 112 thus far, forming the AS-PATH. The AS-PATH allows straightforward 113 suppression of the looping of routing information. In addition, the 114 AS-PATH serves as a powerful and versatile mechanism for policy-based 115 routing. 117 BGP-4 enhances the AS-PATH attribute to include sets of autonomous 118 systems as well as lists. This extended format allows generated 119 aggregate routes to carry path information from the more specific 120 routes used to generate the aggregate. It should be noted however, 121 that as of this writing, AS-SETs are in rarely used in the Internet 122 [ROUTEVIEWS]. 124 2.2. BGP Algorithms 126 BGP uses an algorithm that cannot be classified as either a pure 127 distance vector, or a pure link state. Carrying a complete AS path in 128 the AS-PATH attribute allows to reconstruct large portions of the 129 overall topology. That makes it similar to the link state algorithms. 130 Exchanging only the currently used routes between the peers makes it 131 similar to the distance vector algorithms. 133 BGP-4 uses an incremental update strategy in order To conserve 134 bandwidth and processing power. That is, after initial exchange of 135 complete routing information, a pair of BGP routers exchanges only 136 changes (deltas) to that information. Such an incremental update 137 design requires reliable transport between a pair of BGP routers to 138 function correctly. BGP uses TCP as its reliable transport. 140 In addition to incremental updates, BGP-4 has added the concept of 141 route aggregation so that information about groups of networks may be 142 aggregated and sent as a single Network Layer Reachability (NLRI) 143 Attribute. 145 Finally, note that BGP is a self-contained protocol. That is, it 146 specifies how routing information is exchanged both between BGP 147 speakers in different autonomous systems, and between BGP speakers 148 within a single autonomous system. 150 2.3. BGP Finite State Machine (FSM) 152 The BGP FSM is a set of rules that are applied to a BGP speaker's set 153 of configured peers for the BGP operation. A BGP implementation 154 requires that a BGP speaker must connect and listen to tcp port 179 155 for accepting any new BGP connections from it's peers. The BGP FSM 156 must be initiated and maintained for each new incoming and outgoing 157 peer connections. However, in steady state operation, there will be 158 only one BGP FSM per connection per peer. 160 There may exist a temporary period where in a BGP peer may have 161 separate incoming and outgoing connections resulting into two 162 different BGP FSMs for a peer (instead of one). This can be resolved 163 following BGP connection collision rules defined in the [BGP4]. 165 Following are different states of BGP FSM for its peers: 167 IDLE: State when BGP peer refuses any incoming 168 connections. 170 CONNECT: State in which BGP peer is waiting for 171 its TCP connection to be completed. 173 ACTIVE: State in which BGP peer is trying to acquire a 174 peer by listening and accepting TCP connection. 176 OPENSENT: BGP peer is waiting for OPEN message from its 177 peer. 179 OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION 180 message from its peer. 182 ESTABLISHED: BGP peer connection is established and exchanges 183 UPDATE, NOTIFICATION, and KEEPALIVE messages with 184 its peer. 186 3. BGP Performance characteristics and Scalability 188 In this section, we provide "order of magnitude" answers to the 189 questions of how much link bandwidth, router memory and router CPU 190 cycles the BGP protocol will consume under normal conditions. In 191 particular, we will address the scalability of BGP and its 192 limitations. 194 It is important to note that BGP does not require all the routers 195 within an autonomous system to participate in the BGP protocol. In 196 particular, only the border routers that provide connectivity between 197 the local autonomous system and their adjacent autonomous systems 198 need participate in BGP. Constraining this set of participants is 199 just one way of addressing the scaling issue. 201 3.1. Link bandwidth and CPU utilization 203 Immediately after the initial BGP connection setup, the peers 204 exchange complete set of routing information. If we denote the total 205 number of routes in the Internet by N, the mean AS distance of the 206 Internet by M (distance at the level of an autonomous system, 207 expressed in terms of the number of autonomous systems), the total 208 number of autonomous systems in the Internet by A, and assume that 209 the networks are uniformly distributed among the autonomous systems, 210 then the worst case amount of bandwidth consumed during the initial 211 exchange between a pair of BGP speakers is 213 MR = O(N + M * A) 215 The following table illustrates the typical amount of bandwidth 216 consumed during the initial exchange between a pair of BGP speakers 217 based on the above assumptions (ignoring bandwidth consumed by the 218 BGP Header). For purposes of the estimates here, we will calculate MR 219 = 4 * (N + (M * A)). 221 # NLRI Mean AS Distance # AS's Bandwidth (MR) 222 ---------- ---------------- ------ ---------------- 223 40,000 15 400 184,000 bytes 224 100,000 10 10,000 800,000 bytes 225 120,000 10 15,000 1,080,000 bytes 226 140,000 15 20,000 1,760,000 bytes 228 [note that most of this bandwidth is consumed by the NLRI exchange] 230 BGP-4 was created specifically to reduce the size of the set of NLRI 231 entires carried and exchanged by border routers. The aggregation 232 scheme, defined in RFC 1519 [RFC1519], describes the provider-based 233 aggregation scheme in use in today's Internet. 235 Due to the advantages of advertising a few large aggregate blocks 236 instead of many smaller class-based individual networks, it is 237 difficult to estimate the actual reduction in bandwidth and 238 processing that BGP-4 has provided over BGP-3. If we simply 239 enumerate all aggregate blocks into their individual class-based 240 networks, we would not take into account "dead" space that has been 241 reserved for future expansion. The best metric for determining the 242 success of BGP-4's aggregation is to sample the number NLRI entries 243 in the globally connected Internet today and compare it to projected 244 growth rates before BGP-4 was deployed. 246 At the time of this writing, the full set of exterior routes carried 247 by BGP is approximately 120,000 network entries [ROUTEVIEWS]. 249 3.1.1. CPU utilization 251 An important (and fundamental) feature of BGP is that BGP's CPU 252 utilization depends only on the stability of the Internet. If the 253 Internet is stable, then the only link bandwidth and router CPU 254 cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE 255 messages. The KEEPALIVE messages are exchanged only between peers. 256 The suggested frequency of the exchange is 30 seconds. The KEEPALIVE 257 messages are quite short (19 octets), and require virtually no 258 processing. Therefore, the bandwidth consumed by the KEEPALIVE 259 messages is about 5 bits/sec. Operational experience confirms that 260 the overhead (in terms of bandwidth and CPU) associated with the 261 KEEPALIVE messages should be viewed as negligible. 263 During periods of Internet instability, changes to the reachability 264 information are passed between routers in UPDATE messages. If we 265 denote the number of routing changes per second by C, then in the 266 worst case the amount of bandwidth consumed by the BGP can be 267 expressed as O(C * M). The greatest overhead per UPDATE message 268 occurs when each UPDATE message contains only a single network. It 269 should be pointed out that in practice routing changes exhibit strong 270 locality with respect to the AS path. That is routes that change are 271 likely to have common AS path. In this case multiple networks can be 272 grouped into a single UPDATE message, thus significantly reducing the 273 amount of bandwidth required (see also Appendix F.1 of [BGP4]). 275 Since in the steady state the link bandwidth and router CPU cycles 276 consumed by the BGP protocol are dependent only on the stability of 277 the Internet, it follows that BGP should have no scaling problems in 278 the areas of link bandwidth and router CPU utilization. This assumes 279 that as the Internet grows, the overall stability of the inter-AS 280 connectivity of the Internet can be controlled. In particular, while 281 the size of the IPv4 Internet routing table is bounded by O(2^32 * 282 M), (where M is a slow-moving function describing the AS 283 interconnectivity of the network), no such bound can be formulated 284 for the dynamic properties (i.e., stability) of BGP. Finally, since 285 the dynamic properties of the network cannot be quantitatively 286 bounded, stability must be addressed via heuristics such as BGP 287 Route Flap Dampening [RFC2439]. Due to the nature of BGP, such 288 dampening should be viewed as a local to an autonomous system matter 289 (see also Appendix F.2 of [BGP4]). 291 Growth of the Internet has made the stability issue one of the most 292 crucial issues for Internet operations. BGP by itself does not 293 introduce any instabilities into the Internet. Rather, instabilities 294 are largely due to the the dynamic nature of the edges of the 295 network, coupled with less than optimal aggregation. As a result, 296 stability should be addressed through improved aggregation and 297 isolating the core of the network from the dynamic nature of the edge 298 networks. 300 It may also be instructive to compare bandwidth and CPU requirements 301 of BGP with EGP. While with BGP the complete information is exchanged 302 only at the connection establishment time, with EGP the complete 303 information is exchanged periodically (usually every 3 minutes). Note 304 that both for BGP and for EGP the amount of information exchanged is 305 roughly on the order of the networks reachable via a peer that sends 306 the information. Therefore, even if one assumes extreme instabilities 307 of BGP, its worst case behavior will be the same as the steady state 308 behavior of it's predecessor, EGP. 310 Operational experience with BGP showed that the incremental update 311 approach employed by BGP presents an enormous improvement both in the 312 area of bandwidth and in the CPU utilization, as compared with 313 complete periodic updates used by EGP (see also presentation by 314 Dennis Ferguson at the Twentieth IETF, March 11-15, 1991, St.Louis). 316 3.1.2. Memory requirements 318 To quantify the worst case memory requirements for BGP, denote the 319 total number of networks in the Internet by N, the mean AS distance 320 of the Internet by M (distance at the level of an autonomous system, 321 expressed in terms of the number of autonomous systems), the total 322 number of autonomous systems in the Internet by A, and the total 323 number of BGP speakers that a system is peering with by K (note that 324 K will usually be dominated by the total number of the BGP speakers 325 within a single autonomous system). Then the worst case memory 326 requirements (MR) can be expressed as 327 MR = O((N + M * A) * K) 329 It is interesting to note that prior to the introduction of BGP in 330 the NSFNET Backbone, memory requirements on the NSFNET Backbone 331 routers running EGP were on the order of O(N *K). Therefore, the 332 extra overhead in memory incurred by the modern routers running BGP 333 is less than 7 percent. 335 Since a mean AS distance M is a slow moving function of the 336 interconnectivity ("meshiness") of the Internet, for all practical 337 purposes the worst case router memory requirements are on the order 338 of the total number of networks in the Internet times the number of 339 peers the local system is peering with. We expect that the total 340 number of networks in the Internet will grow much faster than the 341 average number of peers per router. As a result, scaling with 342 respect to the memory requirements is going to be heavily dominated 343 by the factor that is linearly proportional to the total number of 344 networks in the Internet. 346 The following table illustrates typical memory requirements of a 347 router running BGP. It is assumed that each network is encoded as 348 four bytes, each AS is encoded as two bytes, and each networks is 349 reachable via some fraction of all of the peers (# BGP peers/per 350 net). For purposes of estimates here, we will calculate MR = ((N*4) + 351 (M*A)*2) * K. 353 # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) 354 ---------- ---------------- ------ ------------------- -------------- 355 100,000 20 3,000 20 1,040,000 356 100,000 20 15,000 20 1,040,000 357 120,000 10 15,000 100 75,000,000 358 140,000 15 20,000 100 116,000,000 360 In analyzing BGP's memory requirements, we focus on the size of the 361 forwarding table (ignoring implementation details). In particular, we 362 derive upper bounds for the size of the forwarding table. For 363 example, at the time of this writing, the forwarding tables of a 364 typical backbone router carries on the order of 120,000 entries. 365 Given this number, one might ask whether it would be possible to have 366 a functional router with a table that will have 1,000,000 entries. 367 Clearly the answer to this question is independent of BGP. On the 368 other hand the answer to the original questions (that was asked with 369 respect to BGP) is directly related to the latter question. Very 370 interesting comments were given by Paul Tsuchiya in his review of BGP 371 in March of 1990 (as part of the BGP review committee appointed by 372 Bob Hinden). In the review he said that, "BGP does not scale well. 373 This is not really the fault of BGP. It is the fault of the flat IP 374 address space. Given the flat IP address space, any routing protocol 375 must carry network numbers in its updates." With the introduction of 376 CIDR [RFC1519] and BGP-4 [BGP4], we have attempted to reduce this 377 limitation. Unfortunately, we cannot erase history nor can BGP-4 378 solve the problems inherent with inefficient assignment of future 379 address blocks. 381 To reiterate, BGP limits with respect to the memory requirements are 382 directly related to the underlying Internet Protocol (IP), and 383 specifically the addressing scheme employed by IP. BGP would provide 384 much better scaling in environments with more flexible addressing 385 schemes. It should be pointed out that with only very minor additions 386 BGP was extended to support hierarchies of autonomous system 387 [KUZINGER]. Such hierarchies, combined with an addressing scheme that 388 would allow more flexible address aggregation capabilities, can be 389 utilized by BGP-like protocols, thus providing practically unlimited 390 scaling capabilities. 392 4. Applicability 394 In this section we answer the question of which environments is BGP 395 well suited, and for which environments it is not suitable. 396 Partially this question is answered in the Section 2 of [RFC1771], 397 where the document states the following: 399 "To characterize the set of policy decisions that can be enforced 400 using BGP, one must focus on the rule that an AS advertises to its 401 neighbor ASs only those routes that it itself uses. This rule 402 reflects the "hop-by-hop" routing paradigm generally used 403 throughout the current Internet. Note that some policies cannot 404 be supported by the "hop-by-hop" routing paradigm and thus require 405 techniques such as source routing to enforce. For example, BGP 406 does not enable one AS to send traffic to a neighbor AS intending 407 that the traffic take a different route from that taken by traffic 408 originating in the neighbor AS. On the other hand, BGP can 409 support any policy conforming to the "hop-by-hop" routing 410 paradigm. Since the current Internet uses only the "hop-by-hop" 411 routing paradigm and since BGP can support any policy that 412 conforms to that paradigm, BGP is highly applicable as an inter-AS 413 routing protocol for the current Internet." 415 Importantly, the BGP protocol contains only the functionality that is 416 essential, while at the same time provides flexible mechanisms within 417 the protocol itself that allow to expand its functionality. For 418 example, BGP capabilities provide an easy and flexible way to 419 introduce new features within the protocol. Finally, since BGP was 420 designed with flexibility and expandability in mind, new or evolving 421 requirements can be addressed via existing mechanisms. The existence 422 proof of this statement may be found in the way how new features 423 (like repairing a partitioned autonomous system with BGP) are already 424 introduced in the protocol. 426 To summarize, BGP is well suitable as an inter-autonomous system 427 routing protocol for the IPv4 Internet that is based on IP [RFC791] 428 as the Internet Protocol and "hop-by-hop" routing paradigm. Finally, 429 there is no reason to believe that BGP should not be equally 430 applicable to IPv6 [RFC2460]. 432 5. Acknowledgments 434 We would like to thank Paul Traina for authoring previous versions of 435 this document. 437 6. References 439 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A 440 Border Gateway Protocol 4 (BGP-4)", 441 draft-ietf-idr-bgp4-19.txt. Work in progress. 443 [KUZINGER] ISO/IEC 10747, Kunzinger, C., Editor, 444 "Inter-Domain Routing Protocol", October 1993. 446 [RFC791] "INTERNET PROTOCOL", DARPA INTERNET PROGRAM 447 PROTOCOL SPECIFICATION, RFC 791, September, 448 1981. 450 [RFC854] Postel, J. and Reynolds, J., "TELNET PROTOCOL 451 SPECIFICATION", RFC 854, May, 1983. 453 [RFC1105] Lougheed, K., and Rekhter, Y, "Border Gateway 454 Protocol BGP", RFC 1105, June 1989. 456 [RFC1163] Lougheed, K., and Rekhter, Y, "Border Gateway 457 Protocol BGP", RFC 1105, June 1990. 459 [RFC1264] Hinden, R., "Internet Routing Protocol 460 Standardization Criteria", RFC 1264, October 1991. 462 [RFC1267] Lougheed, K., and Rekhter, Y, "Border Gateway 463 Protocol 3 (BGP-3)", RFC 1105, October 1991. 465 [RFC1519] Fuller, V., Li. T., Yu J., and K. Varadhan, 466 "Classless Inter-Domain Routing (CIDR): an 467 Address Assignment and Aggregation Strategy", RFC 468 1519, September 1993. 470 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 471 Protocol 4 (BGP-4)", RFC 1771, March 1995. 473 [RFC1772] Rekhter, Y., and P. Gross, Editors, "Application 474 of the Border Gateway Protocol in the Internet", 475 RFC 1772, March 1995. 477 [RFC2439] Villamizar, C., Chandra, R., and Govindan, R., 478 "BGP Route Flap Damping", RFC 2439, November 479 1998. 481 [RFC2460] Deering, S, and R. Hinden, "Internet Protocol, 482 Version 6 (IPv6) Specification", RFC 2460, 483 December, 1998. 485 [ROUTEVIEWS] Meyer, David, "The Route Views Project", 486 http://www.routeviews.org 488 7. Author's Address 490 David Meyer 491 Email: dmm@maoz.com 493 Keyur Patel 494 Cisco Systems 495 Email: keyupate@cisco.com 497 8. Full Copyright Statement 499 Copyright (C) The Internet Society (2003). All Rights Reserved. 501 This document and translations of it may be copied and furnished to 502 others, and derivative works that comment on or otherwise explain it 503 or assist in its implementation may be prepared, copied, published 504 and distributed, in whole or in part, without restriction of any 505 kind, provided that the above copyright notice and this paragraph are 506 included on all such copies and derivative works. However, this 507 document itself may not be modified in any way, such as by removing 508 the copyright notice or references to the Internet Society or other 509 Internet organizations, except as needed for the purpose of 510 developing Internet standards in which case the procedures for 511 copyrights defined in the Internet Standards process must be 512 followed, or as required to translate it into languages other than 513 English. 515 The limited permissions granted above are perpetual and will not be 516 revoked by the Internet Society or its successors or assigns. 518 This document and the information contained herein is provided on an 519 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 520 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 521 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 522 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 523 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.