idnits 2.17.1 draft-ietf-idr-bgp4-experience-protocol-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-idr-bgp4-experience-00', but the file name used is 'draft-ietf-idr-bgp4-experience-protocol-00' == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 226: '...cates the use of OPTIONAL PARAMETER Ty...' RFC 2119 keyword, line 353: '...by a BGP speaker MUST NOT be sent to o...' RFC 2119 keyword, line 358: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 387: '... The LOCAL_PREF MUST be sent to IBGP ...' RFC 2119 keyword, line 388: '... MUST NOT be sent to EBGP Peers. Al...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 462 has weird spacing: '...sistent peer ...' -- 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 (August 2003) is 7561 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) == Missing Reference: 'RFC 2119' is mentioned on line 35, but not defined == Missing Reference: 'RFC 1518' is mentioned on line 171, but not defined -- Looks like a reference, but probably isn't: '9' on line 172 == Missing Reference: 'BGP-MIB' is mentioned on line 248, but not defined == Missing Reference: 'RFC 1269' is mentioned on line 250, but not defined ** Obsolete undefined reference: RFC 1269 (Obsoleted by RFC 4273) == Missing Reference: 'BGP-IMPL' is mentioned on line 272, but not defined == Missing Reference: 'RFC 1966' is mentioned on line 294, but not defined ** Obsolete undefined reference: RFC 1966 (Obsoleted by RFC 4456) == Missing Reference: 'RFC 1965' is mentioned on line 296, but not defined ** Obsolete undefined reference: RFC 1965 (Obsoleted by RFC 3065) == Missing Reference: 'SBGP' is mentioned on line 603, but not defined == Unused Reference: 'RFC 1264' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC 1772' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC 1773' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC 3065' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC 3345' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'BGP4-IMPL' is defined on line 698, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1105 (Obsoleted by RFC 1163) -- Duplicate reference: RFC1105, mentioned in 'RFC 1163', was also mentioned in 'RFC 1105'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC 1163') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1264 (Obsoleted by RFC 4794) -- Duplicate reference: RFC1105, mentioned in 'RFC 1267', was also mentioned in 'RFC 1163'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC 1267') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1656 (Obsoleted by RFC 1773) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1773 ** Obsolete normative reference: RFC 2796 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 3065 (Obsoleted by RFC 5065) ** Downref: Normative reference to an Informational RFC: RFC 3345 -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4-ANALYSIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4-IMPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4' Summary: 18 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 draft-ietf-idr-bgp4-experience-00.txt Arbor Networks 3 Keyur Patel 4 Cisco Systems 5 Category Informational 6 Expires: February 2004 August 2003 8 Experience with the BGP-4 Protocol 9 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC 2119]. 36 This document is a product of an individual. Comments are solicited 37 and should be addressed to the author(s). 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 The purpose of this memo is to document how the requirements for 46 advancing a routing protocol from Draft Standard to full Standard 47 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 49 This report satisfies the requirement for "the second report", as 50 described in Section 6.0 of RFC 1264. In order to fulfill the 51 requirement, this report augments RFC 1773 and describes additional 52 knowledge and understanding gained in the time between when the 53 protocol was made a Draft Standard and when it was submitted for 54 Standard. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 61 2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Management Information Base (MIB). . . . . . . . . . . . . . . 7 65 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8 67 6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9 69 6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10 70 6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10 71 6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10 72 7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11 74 9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12 75 10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 76 11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13 77 12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 78 13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 79 14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14 80 15. Control over Version Negotiation. . . . . . . . . . . . . . . 14 81 16. Reciept of Non-Transitive Attributes from eBGP 82 Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 85 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15 86 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 87 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 16 88 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17 89 17.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 90 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 92 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The purpose of this memo is to document how the requirements for 97 advancing a routing protocol from Draft Standard to full Standard 98 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 100 This report satisfies the requirement for "the second report", as 101 described in Section 6.0 of RFC 1264. In order to fulfill the 102 requirement, this report augments RFC 1773 and describes additional 103 knowledge and understanding gained in the time between when the 104 protocol was made a Draft Standard and when it was submitted for 105 Standard. 107 2. BGP-4 Overview 109 BGP is an inter-autonomous system routing protocol designed for 110 TCP/IP internets. The primary function of BGP is to exchange network 111 reachability information with other BGP systems. This information is 112 sufficient to construct a graph of loop-free AS connectivity and 113 policy decisions at the AS level may be enforced. 115 The initial version of the BGP protocol was published in RFC 1105. 116 Since then BGP Versions 2, 3, and 4 have been developed and are 117 specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. 118 Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in 119 Appendix N of [BGP4]. 121 2.1. A Border Gateway Protocol 123 The Initial Version of BGP [RFC 1105] 125 Appendix D of [BGP4]; Comparison with 1105: 127 o Changes to FSM to accommdate BSD 4.3 TCP UI. 128 o Notion of Up/Down/Horizontal relations have been removed. 129 o Message format changes: 130 - Hold Timer removed from BGP Header and added to OPEN Message 131 - Version field removed from BGP Header and added to OPEN Message 132 - Link Type field removed from OPEN Message 133 - OPEN CONFIRM message deprecated and replaced with implicit 134 confirmation provided by KEEPALIVE message. 136 - UPDATE Message format changed. New fields were added to 137 support multiple path attributes. 138 - The Marker field was expanded and its role broadened to 139 support authentication 141 2.2. BGP version 2 143 The Second Version of BGPv2 [RFC 1163] 145 Appendix C of [BGP4] Comparison with RFC 1163 147 o BGP Identifier introduced to deal with collision detection. 148 o Removed restriction that border router of NEXT_HOP path attribute 149 had to be part of same AS. 150 o Optimized and simplified exchange of information about reachable 151 routes. 153 BGP version 2 removed from the protocol the concept of "up", "down", 154 and "horizontal" relations between autonomous systems that were 155 present in version 1. BGP version 2 introduced the concept of path 156 attributes. In addition, BGP version 2 clarified parts of the 157 protocol that were "under-specified". 159 2.3. BGP version 3 161 BGPv3 [RFC 1267] 163 Appendix B of [BGP4] Comparison with RFC 1267: 165 o Set of destination via single IP prefix. Concept of 166 network classes, or subnetting is foreign to BGP-4. 167 To accommodate these capabilities BGP-4 changes the 168 semantics and encoding associated with the AS_PATH attribute. 169 New text has been added to define semantics associated with 170 IP Prefixes. These abilities allow BGP to support the 171 proposed supernetting scheme [RFC 1518] (BGP4 Draft reference 172 to [9] needs to be fixed). 173 o LOCAL_PREF intrduced to facilitate route selection procedures. 174 o INTER_AS_METRIC renamed to MULTI_EXIT_DISC 175 o ATOMIC_AGGREGATE introduced to ensure that certain aggregates 176 are not deaggregated. 177 o Introduced AGGREGATOR. 179 o Holdtimer neogtiation per-connection for symmetry. Lower value 180 used. Hold Times of zero now supported. 182 BGP version 3 lifted some of the restrictions on the use of the 183 NEXT_HOP path attribute, and added the BGP Identifier field to the 184 BGP OPEN message. It also clarifies the procedure for distributing 185 BGP routes between the BGP speakers within an autonomous system. 187 2.4. BGP version 4 189 BGP v4 [RFC 1771] [BGP4] 191 Appendix A of [BGP4] Comparison with RFC 1771: 193 o Changes to reflect use of the TCP MD5 Signature Option, 194 Route Reflectors, AS Confederations for BGP and BGP Route 195 Refresh. 196 o Clarified use of BGP Identifier in AGGREGATOR Attribute 197 o Procedures for imposing upper bound of prefixes a speaker will 198 accept from a peer. 199 o Ability to include more than one instance of it's own AS in the 200 AS_PATH attribute for the purpose of inter-AS traffic engineering. 201 o Clarified various types of NEXT_HOPS 202 o Claried use of ATOMIC_AGGREGATE attribute 203 o Discussed relationship be BGP NEXT_HOP attribute and immediate 204 next hop. 205 o Clarified tie-breaking procedures 206 o Clarified route advertisement frequency text. 207 o Deprecated Optional Parameter Type 1 (Authentication Information) 208 o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated. 209 o Use of Marker field for authentication has been deprecated. 211 BGP version 4 redefines the (previously defined class-based) network 212 layer reachability portion of the updates to specify prefixes of 213 arbitrary length in order to represent multiple classful networks in 214 a single entry as discussed in [RFC 1519]. BGP version 4 has also 215 modified the AS_PATH attribute so that sets of autonomous systems, as 216 well as individual ASs may be described. BGP version 4 has 217 redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and 218 added new LOCAL_PREF and AGGREGATOR attributes. 220 BGP version 4 defines procedures for imposing an upper bound on the 221 number of prefixes that a BGP speaker may accept from its peer. BGP 222 version 4 has modifed the AS_PATH attribute to have an ability to 223 include more than one instance of its own AS for the purpose of 224 inter-AS traffic engineering. 226 BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1 227 (Authentication Information). BGP version 4 also deprecates the use 228 of UPDATE MESSAGE Error subcode 7 (AS Routing Loop). 230 BGP version 4 provides clarifications on use of BGP Identifier in the 231 AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP 232 version 4 also provides clarifications on various types of NEXT_HOPs, 233 BGP tie-breaking procedures and frequency of route announcements in 234 BGP. 236 Possible applications of BGP in the Internet are documented in [RFC 237 1772]. 239 The BGP protocol was developed by the IDR Working Group of the 240 Internet Engineering Task Force. This Working Group had a mailing 241 list, idr@merit.edu, where discussions of protocol features and 242 operation are held. The IDR Working Group meets regularly during the 243 Internet Engineering Task Force meetings. Reports of these meetings 244 are published in the IETF's Proceedings. 246 3. Management Information Base (MIB) 248 The BGP-4 Management Information Base (MIB) has been published [BGP- 249 MIB]. The MIB was updated from previous versions documented in [RFC 250 1657] and [RFC 1269], respectively. 252 Apart from a few system variables, the BGP MIB is broken into two 253 tables: the BGP Peer Table and the BGP Received Path Attribute Table. 255 The Peer Table reflects information about BGP peer connections, such 256 as their state and current activity. The Received Path Attribute 257 Table contains all attributes received from all peers before local 258 routing policy has been applied. The actual attributes used in 259 determining a route are a subset of the received attribute table. 261 4. Implementations 263 There are numerous independent interoperable implementations of BGP 264 currently available. Although the previous version of this report 265 provided an overview of the implementations currently used in the 266 operational Internet, at this time it has been suggested that a 267 separate BGP Implementation Report [BGP-IMPL] be generated. 269 It should be noted that implementation experience with Cisco's BGP-4 270 implementation was documented as part of [RFC 1656]. 272 For all additional implementation information please reference [BGP- 273 IMPL]. 275 5. Operational Experience 277 This section discusses operational experience with BGP and BGP-4. 279 BGP has been used in the production environment since 1989, BGP-4 280 since 1993. Production use of BGP includes utilization of all 281 significant features of the protocol. The present production 282 environment, where BGP is used as the inter-autonomous system routing 283 protocol, is highly heterogeneous. In terms of the link bandwidth it 284 varies from 56 Kbps to 10 Gbps. In terms of the actual routers that 285 run BGP it ranges from a relatively slow performance PC/RT to a very 286 high performance RISC-based CPUs, and includes both the special 287 purpose routers and the general purpose workstations running various 288 UNIX derivatives and other operating systems. 290 In terms of the actual topologies it varies from very sparse to quite 291 dense. The requirement for full-mesh IBGP topologies has been 292 largely remedied by BGP Route Reflection, Autonomous System 293 Confederations for BGP, and perhaps some mix of the two.. BGP Route 294 Reflection was initially defined in [RFC 1966] and subsequently 295 updated in [RFC 2796]. Autonomous System Confederations for BGP were 296 initially defined in [RFC 1965] and subsequently updated in [RFC 297 3065]. 299 At the time of this writing BGP-4 is used as an inter-autonomous 300 system routing protocol between ALL Internet-attached autonomous 301 systems, with nearly 15k active autonomous systems in the global 302 Internet routing table. 304 BGP is used both for the exchange of routing information between a 305 transit and a stub autonomous system, and for the exchange of routing 306 information between multiple transit autonomous systems. There is no 307 protocol distinction between sites historically considered 308 "backbones" versus "regional" or "edge" networks. 310 The full set of exterior routes that is carried by BGP is well over 311 120,000 aggregate entries, representing several times that number of 312 connected networks. The number of active paths in some service 313 provider core routers exceeds 2.5 million. Native AS_PATH lengths 314 are as long as 10 for some routes, and "padded" path lengths of 25 or 315 more ASs exist. 317 6. Metrics 319 This section discusses different metrics used within the BGP 320 protocol. BGP has a seperate metric parameter for IBGP and EBGP. This 321 allows policy based metrics to overwrite the distance based metrics; 322 allowing each autonomous systems to define their independent policies 323 in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) 324 is used as a metric by EBGP peers while BGP Local Preference is used 325 by IBGP peers. 327 6.1. MULTI_EXIT_DISC (MED) 329 BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ 330 DISC (MED). This value may be used in the tie-breaking process when 331 selecting a preferred path to a given address space, and provides BGP 332 speakers with the capability to convey to a peer AS the optimal entry 333 point into the local AS. 335 Although the MED was meant to only be used when comparing paths 336 received from different external peers in the same AS, many 337 implementations provide the capability to compare MEDs between 338 different ASs as well. 340 The MED was purposely designed to be a "weak" metric that would only 341 be used late in the best-path decision process. The BGP working 342 group was concerned that any metric specified by a remote operator 343 would only affect routing in a local AS if no other preference was 344 specified. A paramount goal of the design of the MED was ensure that 345 peers could not "shed" or "absorb" traffic for networks that they 346 advertise. 348 6.1.1. Sending MEDs to BGP Peers 350 [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to 351 be passed to its IBGP peers. Although advertising MEDs to IBGP peers 352 is not a required behavior, it is a common default. MEDs received 353 from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP 354 peers. 356 6.1.2. MED of Zero Versus No MED 358 An implementation MUST provide a mechanism that allows for MED to be 359 removed. Previously, implementations did not consider a missing MED 360 value to be the same as a MED of zero. No MED value should now be 361 equal to a value of zero. 363 6.1.3. MEDs and Temporal Route Selection 365 Some implementations have hooks to apply temporal behavior in MED- 366 based best path selection. That is, all other things being equal up 367 to MED consideration, preference would be applied to the "oldest" 368 path, without preferring the lower MED value. The reasoning for this 369 is that "older" paths are presumably more stable, and thus more 370 preferable. However, temporal behavior in route slection results in 371 non-deterministic behavior, and as such, is often undesirable. 373 7. LOCAL_PREF 375 The LOCAL_PREF attribute was added so a network operator could easily 376 configure a policy that overrode the standard best path determination 377 mechanism without independently configuring local preference policy 378 on each router. 380 One shortcoming in the BGP-4 specification was a suggestion for a 381 default value of LOCAL-PREF to be assumed if none was provided. 382 Defaults of 0 or the maximum value each have range limitations, so a 383 common default would aid in the interoperation of multi-vendor 384 routers in the same AS (since LOCAL_PREF is a local administration 385 knob, there is no interoperability drawback across AS boundaries). 387 The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute 388 MUST NOT be sent to EBGP Peers. Although no default value for 389 LOCAL_PREF is defined, the common default value is 100. 391 Another area where more exploration is required is a method whereby 392 an originating AS may influence the best path selection process. For 393 example, a dual-connected site may select one AS as a primary transit 394 service provider and have one as a backup. 396 /---- transit B ----\ 397 end-customer transit A---- 398 /---- transit C ----\ 400 In a topology where the two transit service providers connect to a 401 third provider, the real decision is performed by the third provider 402 and there is no mechanism for indicating a preference should the 403 third provider wish to respect that preference. 405 A general purpose suggestion that has been brought up is the 406 possibility of carrying an optional vector corresponding to the AS- 407 PATH where each transit AS may indicate a preference value for a 408 given route. Cooperating ASs may then chose traffic based upon 409 comparison of "interesting" portions of this vector according to 410 routing policy. 412 While protecting a given ASs routing policy is of paramount concern, 413 avoiding extensive hand configuration of routing policies needs to be 414 examined more carefully in future BGP-like protocols. 416 8. Internal BGP In Large Autonomous Systems 418 While not strictly a protocol issue, one other concern has been 419 raised by network operators who need to maintain autonomous systems 420 with a large number of peers. Each speaker peering with an external 421 router is responsible for propagating reachability and path 422 information to all other transit and border routers within that AS. 423 This is typically done by establishing internal BGP connections to 424 all transit and border routers in the local AS. 426 In a large AS, this leads to a full mesh of TCP connections (n * 427 (n-1)) and some method of configuring and maintaining those 428 connections. BGP does not specify how this information is to be 429 propagated, so alternatives, such as injecting BGP attribute 430 information into the local IGP have been suggested. Also, there is 431 effort underway to develop internal BGP "route reflectors" or a 432 reliable multicast transport of IBGP information which would reduce 433 configuration, memory and CPU requirements of conveying information 434 to all other internal BGP peers. 436 BGP "Route Reflector" extensions has been defined in RFC 1966 to 437 alleviate the the need for "full mesh" IBGP. 439 9. Internet Dynamics 441 As discussed in [BGP4-ANALYSIS], the driving force in CPU and 442 bandwidth utilization is the dynamic nature of routing in the 443 Internet. As the net has grown, the number of route changes per 444 second has increased. 446 We automatically get some level of damping when more specific NLRI is 447 aggregated into larger blocks, however this isn't sufficient. In 448 Appendix F of [BGP4] are descriptions of damping techniques that 449 should be applied to advertisements. In future specifications of 450 BGP-like protocols, damping methods should be considered for 451 mandatory inclusion in compliant implementations. 453 Route changes are announced using BGP UPDATE messages. The greatest 454 overhead in advertising UPDATE messages happens whenever route 455 changes to be announced are inefficiently packed.Announcing routing 456 changes sharing common attributes in a single BGP UPDATE message 457 [13.1] also helps save considerable bandwidth. 459 Persistent BGP errors may cause BGP peers to flap persistently if 460 peer dampening is not implemented. This would result in significant 461 CPU utilization. Implementors may find it useful to implement peer 462 dampening to avoid such persistent peer flapping [BGP4]. 464 10. BGP Routing Information Bases (RIBs) 466 [BGP4] states "Any local policy which results in routes being added 467 to an Adj-RIB-Out without also being added to the local BGP speaker's 468 forwarding table, is outside the scope of this document". 470 However, several well-known implementations do not confirm that Loc- 471 RIB entries were used to populate the forwarding table before 472 installing them in the Adj-RIB-Out. The most common occurrence of 473 this is when routes for a given prefix are presented by more than one 474 protocol and the preferences for the BGP learned route is lower than 475 that of another protocol. As such, the route learned via the other 476 protocol is used to populate the forwarding table. 478 It may be desirable for an implementation to provide a knob that 479 permits advertisement of "inactive" BGP routes. 481 It may be also desirable for an implementation to provide a knob that 482 allows a BGP speaker to advertise BGP routes that were not selected 483 by descision process. 485 11. Update Packing 487 The BGP4 protocol permits advertisement of multiple prefixes with a 488 common set of path attributes to be advertised in a single update 489 message, this is commonly referred to as "update packing". When 490 possible, update packing is recommended as it provides a mechanism 491 for more efficient behavior in a number of areas, to include: 493 o Reduction in system overhead due to generation or receipt of 494 fewer Update messages. 496 o Reduction in network overhead as a result of less packets 497 and lower bandwidth consumption. 499 o Allows you to process path attributes and look for matching 500 sets in your AS_PATH database (if you have one) less 501 frequently. Consistent ordering of the path attributes 502 allows for ease of matching in the database as you don't have 503 different representations of the same data. 505 The BGP protocol suggests that withdrawal information should be 506 packed in the begining of Update message along with information about 507 more or less specific reachable routes in a single UPDATE message. 508 This would help alleviate excessive route flapping in BGP. 510 12. Limit Rate Updates 512 The BGP protocol defines different mechanisms to rate limit the 513 Updates. The BGP protocol defines MinRouteAdvertisementInterval 514 parameter that determines the minimum time that must be elsape 515 between the advertisement of routes to a particular destination from 516 a single BGP speaker. This value is set on a per BGP peer basis. 518 13. Ordering of Path Attributes 520 The BGP protocol suggests that BGP speakers sending multiple prefixes 521 per an UPDATE message should sort and order path attributes according 522 to Type Codes. This would help their peers to quickly identify sets 523 of attributes from different update messages which are semantically 524 different. 526 Implementers may find it useful to order path attributes according to 527 Type Code so that sets of attributes with identical semantics can be 528 more quickly identified. 530 14. AS_SET Sorting 532 AS_SETs are commonly used in BGP route aggregation. They reduce the 533 size of AS_PATH information by listing AS numbers only once 534 regardless of any number of times it might appear in process of 535 aggregation. AS_SETs are usually sorted in increasing order to 536 facilitate efficient lookups of AS numbers within them. This 537 optimization is entirely optional. 539 15. Control over Version Negotiation 541 Because pre-BGP-4 route aggregation can't be supported by earlier 542 version of BGP, an implementation that supports versions in addition 543 to BGP-4 should provide the version support on a per-peer basis. 545 16. Reciept of Non-Transitive Attributes from eBGP Peer 547 E.g., LOCAL_PREF, RR or confed, etc.. 549 NEEDS MORE WORK 551 17. Security Considerations 553 BGP provides flexible and extendable mechanism for authentication and 554 security. The mechanism allows to support schemes with various 555 degree of complexity. BGP sessions are authenticated based on the IP 556 address of a peer. In addition, all BGP sessions are authenticated 557 based on the autonomous system number advertised by a peer. 559 Since BGP runs over TCP and IP, BGP's authentication scheme may be 560 augmented by any authentication or security mechanism provided by 561 either TCP or IP. 563 17.1. TCP MD5 Signature Option 565 RFC 2385 defines a way in which the TCP MD5 signature option can be 566 used to valid information transmitted between two peers. This method 567 prevents any third party from injecting information (e.g., a TCP RST) 568 into the datastream, or modifying the routing information carried 569 between two BGP peers. RFC ???? provides suggestions for choosing 570 passwords to be used with MD5. 572 TCP MD5 is not ubiquitously deployed at the moment, especially in 573 inter- domain scenarios, largely because of key distribution issues. 574 Most key distribution mechanisms are considered to be too "heavy" at 575 this point. 577 17.2. BGP Over IPSEC 579 BGP can run over IPSEC, either in a tunnel, or in transport mode, 580 where the TCP portion of the IP packet is encrypted. This not only 581 prevents random insertion of information into the data stream between 582 two BGP peers, it also prevents an attacker from learning the data 583 which is being exchanged between the peers. 585 IPSEC does, however, offer several options for exchanging session 586 keys, which may be useful on inter-domain configurations. These 587 options are being explored in many deployments, although no 588 definitive solution has been reach on the issue of key exchange for 589 BGP in IPSEC. 591 It should be noted that since BGP runs over TCP and IP, BGP is 592 vulnerable to the same denial of service or authentication attacks 593 that are present in any other TCP based protocol. 595 17.3. Miscellaneous 597 Another issue any routing protocol faces is providing evidence of the 598 validity and authority of the routing information carried within the 599 routing system. This is currently the focus of several efforts at 600 the moment, including efforts to define the threats which can be used 601 against this routing information in BGP [draft-murphy, attack tree], 602 and efforts at developing a means to provide validation and authority 603 for routing information carried within BGP [SBGP] [soBGP]. 605 In addition, the Routing Protocol Security Requirements (RPSEC) 606 working group has been chartered within the Routing Area of the IETF 607 in order to discuss and assist in addressing issues surrounding 608 routing protocol security. It is the intent that this work within 609 RPSEC will result in feedback to BGPv4 and future enhancements to the 610 protocol where appropriate. 612 17.4. PTOMAINE and GROW 614 The Prefix Taxonomy (PTOMAINE) working group, recently replaced by 615 the Global Routing Operations (GROW) working group, is chartered to 616 consider and measure the problem of routing table growth, the effects 617 of the interactions between interior and exterior routing protocols, 618 and the effect of address allocation policies and practices on the 619 global routing system. Finally, where appropriate, GROW will also 620 document the operational aspects of measurement, policy, security and 621 VPN infrastructures. 623 It is the intent that this work within GROW will result in feedback 624 to BGPv4 and future enhancements to the protocol as necessary. 626 One thing that I think you might want to add is something about 627 aggregation and the inability to aggregate over multiple provider 628 boundaries due to inadequate provider coordination. If you want you 629 can cite the ptomaine work if anything came of it or just mention 630 that the WG was created to address problems in this area. 632 If you want something on the PRD to IRR and RPSL I can put together a 633 few paragraphs. 635 17.5. Internet Routing Registries (IRRs) 637 Many organizations register their routing policy and prefix 638 origination in the various distributed databases of the Internet 639 Routing Registry. These databases provide access to the information 640 using the RPSL language as defined in [RFC 2622]. While registered 641 information may be maintained and correct for certain providers, the 642 lack of timely or correct data in the various IRR databases has 643 prevented wide-spread use of this resource. 645 17.6. Acknowledgements 647 We would like to thank Paul Traina and Yakov Rekhter for authoring 648 previous versions of this document. We would also like to 649 acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for 650 valuable feedback on this document. 652 18. References 654 [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 655 BGP", RFC 1105, June 1989. 657 [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 658 BGP", RFC 1105, June 1990. 660 [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization 661 Criteria", RFC 1264, October 1991. 663 [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 664 (BGP-3)", RFC 1105, October 1991. 666 [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless 667 Inter-Domain Routing (CIDR): an Address Assignment and 668 Aggregation Strategy", RFC 1519, September 1993. 670 [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and 671 Implementation Experience", RFC 1656, July 1994. 673 [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 674 (BGP-4)", RFC 1771, March 1995. 676 [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the 677 Border Gateway Protocol in the Internet", RFC 1772, March 678 1995. 680 [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 681 1773, March 1995. 683 [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification 684 Language", RFC 2622, June 1999. 686 [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - 687 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 689 [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous 690 System Confederations for BGP", RFC 3065, Febuary 2001. 692 [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP 693 Persistent Route Oscillation Condition", RFC 3345, 694 August 2002. 696 [BGP4-ANALYSIS] Work in Progress. 698 [BGP4-IMPL] Work in Progress. 700 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border 701 Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 703 19. Authors' Addresses 705 Danny McPherson 706 Arbor Networks 707 Email: danny@arbor.net 709 Keyur Patel 710 Cisco Systems 711 Email: keyupate@cisco.com 713 20. Full Copyright Statement 715 Copyright (C) The Internet Society (2003). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist in its implementation may be prepared, copied, published 720 and distributed, in whole or in part, without restriction of any 721 kind, provided that the above copyright notice and this paragraph are 722 included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into languages other than 729 English. 731 The limited permissions granted above are perpetual and will not be 732 revoked by the Internet Society or its successors or assigns. 734 This document and the information contained herein is provided on an 735 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 736 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 737 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 738 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 739 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.