idnits 2.17.1 draft-ietf-grow-bgp-med-considerations-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 523), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 106: '...ith lower metric SHOULD be preferred. ...' RFC 2119 keyword, line 107: '...T_DISC attribute MAY be propagated ove...' RFC 2119 keyword, line 109: '...eceived from a neighboring AS MUST NOT...' RFC 2119 keyword, line 112: '... A BGP speaker MUST implement a mech...' RFC 2119 keyword, line 115: '...rom a route, then this removal MUST be...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 370 has weird spacing: '...us more pre...' -- 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 2005) is 6981 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: 'RFC 1519' is defined on line 449, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2796 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 3065 (Obsoleted by RFC 5065) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 Arbor Networks, Inc. 3 Vijay Gill 4 AOL 5 Category Informational 6 Expires: September 2005 March 2005 8 BGP MED Considerations 9 11 Status of this Memo 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 The BGP MED attribute provides a mechanism for BGP speakers to convey 47 to an adjacent AS the optimal entry point into the local AS. While 48 BGP MEDs function correctly in many scenarios, there are a number of 49 issues which may arise when utilizing MEDs in dynamic or complex 50 topologies. 52 This document discusses implementation and deployment considerations 53 regarding BGP MEDs and provides information which implementors and 54 network operators should be familiar with. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. About the MULTI_EXIT_DISC (MED) Attribute . . . . . . . . . 4 60 1.2. MEDs and Potatos. . . . . . . . . . . . . . . . . . . . . . 5 61 2. Implementation and Protocol Considerations . . . . . . . . . . 6 62 2.1. MULTI_EXIT_DISC is a Optional Non-Transitive 63 Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.2. MED Values and Preferences. . . . . . . . . . . . . . . . . 7 65 2.3. Comparing MEDs Between Different Autonomous 66 Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.4. MEDs, Route Reflection and AS Confederations 68 for BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.5. Route Flap Damping and MED Churn. . . . . . . . . . . . . . 9 70 2.6. Effects of MEDs on Update Packing Efficiency. . . . . . . . 9 71 2.7. Temporal Route Selection. . . . . . . . . . . . . . . . . . 10 72 3. Deployment Considerations. . . . . . . . . . . . . . . . . . . 10 73 3.1. Comparing MEDs Between Different Autonomous 74 Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.2. Effects of Aggregation on MEDs` . . . . . . . . . . . . . . 11 76 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 77 4.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1. Normative References. . . . . . . . . . . . . . . . . . . . 14 80 5.2. Informative References. . . . . . . . . . . . . . . . . . . 15 81 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The BGP MED attribute provides a mechanism for BGP speakers to convey 86 to an adjacent AS the optimal entry point into the local AS. While 87 BGP MEDs function correctly in many scenarios, there are a number of 88 issues which may arise when utilizing MEDs in dynamic or complex 89 topologies. 91 This document discusses implementation and deployment considerations 92 regarding BGP MEDs and provides information which implementors and 93 network operators should be familiar with. 95 1.1. About the MULTI_EXIT_DISC (MED) Attribute 97 The BGP MULTI_EXIT_DISC (MED) attribute, formerly known as the 98 INTER_AS_METRIC, is currently defined in section 5.1.4 of [BGP4], as 99 follows: 101 The MULTI_EXIT_DISC is an optional non-transitive attribute which 102 is intended to be used on external (inter-AS) links to discriminate 103 among multiple exit or entry points to the same neighboring AS. 104 The value of the MULTI_EXIT_DISC attribute is a four octet unsigned 105 number which is called a metric. All other factors being equal, the 106 exit point with lower metric SHOULD be preferred. If received over 107 EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to 108 other BGP speakers within the same AS (see also 9.1.2.2). The 109 MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT 110 be propagated to other neighboring ASs. 112 A BGP speaker MUST implement a mechanism based on local 113 configuration which allows the MULTI_EXIT_DISC attribute to be 114 removed from a route. If a BGP speaker is configured to remove the 115 MULTI_EXIT_DISC attribute from a route, then this removal MUST be 116 done prior to determining the degree of preference of the route and 117 performing route selection (Decision Process phases 1 and 2). 119 An implementation MAY also (based on local configuration) alter the 120 value of the MULTI_EXIT_DISC attribute received over EBGP. If a 121 BGP speaker is configured to alter the value of the MULTI_EXIT_DISC 122 attribute received over EBGP, then altering the value MUST be done 123 prior to determining the degree of preference of the route and 124 performing route selection (Decision Process phases 1 and 2). See 125 Section 9.1.2.2 of BGP4] for necessary restrictions on this. 127 Section 9.1.2.2 (c) of [BGP4] defines the following route selection 128 criteria regarding MEDs: 130 c) Remove from consideration routes with less-preferred 131 MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable 132 between routes learned from the same neighboring AS (the neighbor- 133 ing AS is determined from the AS_PATH attribute). Routes which do 134 not have the MULTI_EXIT_DISC attribute are considered to have the 135 lowest possible MULTI_EXIT_DISC value. 137 This is also described in the following procedure: 139 for m = all routes still under consideration 140 for n = all routes still under consideration 141 if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)) 142 remove route m from consideration 144 In the pseudo-code above, MED(n) is a function which returns the 145 value of route n's MULTI_EXIT_DISC attribute. If route n has no 146 MULTI_EXIT_DISC attribute, the function returns the lowest possi- 147 ble MULTI_EXIT_DISC value, i.e. 0. 149 If a MULTI_EXIT_DISC attribute is removed before re-advertising a 150 route into IBGP, then comparison based on the received EBGP 151 MULTI_EXIT_DISC attribute MAY still be performed. If an 152 implementation chooses to remove MULTI_EXIT_DISC, then the optional 153 comparison on MULTI_EXIT_DISC if performed at all MUST be performed 154 only among EBGP learned routes. The best EBGP learned route may 155 then be compared with IBGP learned routes after the removal of the 156 MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a 157 subset of EBGP learned routes and the selected "best" EBGP learned 158 route will not have MULTI_EXIT_DISC removed, then the 159 MULTI_EXIT_DISC must be used in the comparison with IBGP learned 160 routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used in 161 route comparisons which reach this step in the Decision Process. 162 Including the MULTI_EXIT_DISC of an EBGP learned route in the 163 comparison with an IBGP learned route, then removing the 164 MULTI_EXIT_DISC attribute and advertising the route has been proven 165 to cause route loops. 167 1.2. MEDs and Potatos 169 In a situation where traffic flows between a pair of hosts, each 170 connected to different transit networks, which are themselves 171 interconnected at two or more locations, each transit network has the 172 choice of either sending traffic to the closest peering to the 173 adjacent transit network or passing traffic to the interconnection 174 location which advertises the least cost path to the destination 175 host. 177 The former method is called "hot potato routing" (or closest-exit) 178 because like a hot potato held in bare hands, whoever has it tries to 179 get rid of it quickly. Hot potato routing is accomplished by not 180 passing the EGBP learned MED into IBGP. This minimizes transit 181 traffic for the provider routing the traffic. Far less common is 182 "cold potato routing" (or best-exit) where the transit provider uses 183 their own transit capacity to get the traffic to the point that 184 adjacent transit provider advertised as being closest to the 185 destination. Cold potato routing is accomplished by passing the EBGP 186 learned MED into IBGP. 188 If one transit provider uses hot potato routing and another uses cold 189 potato, traffic between the two tends to be more symmetric. 190 Depending on the business relationships, if one provider has more 191 capacity or a significantly less congested backbone network, then 192 that provider may use cold potato routing. An example of widespread 193 use of cold potato routing was the NSF funded NSFNET backbone and NSF 194 funded regional networks in the mid 1990s. 196 In some cases a provider may use hot potato routing for some 197 destinations for a given peer AS and cold potato routing for others. 198 An example of this is the different treatment of commercial and 199 research traffic in the NSFNET in the mid 1990s. Today many 200 commercial networks exchange MEDs with customers but not bilateral 201 peers. However, commercial use of MEDs varies widely, from 202 ubiquitous use of MEDs to no use of MEDs at all. 204 In addition, many deployments of MEDs today are likely behaving 205 differently (e.g., resulting is sub-optimal routing) than the network 206 operator intended, thereby resulting not in hot or cold potatos, but 207 mashed potatos! More information on unintended behavior resulting 208 from MEDs is provided throughout this document. 210 2. Implementation and Protocol Considerations 212 There are a number of implementation and protocol peculiarities 213 relating to MEDs that have been discovered that may affect network 214 behavior. The following sections provide information on these 215 issues. 217 2.1. MULTI_EXIT_DISC is a Optional Non-Transitive Attribute 219 MULTI_EXIT_DISC is a non-transitive optional attribute whose 220 advertisement to both IBGP and EBGP peers is discretionary. As a 221 result, some implementations enable sending of MEDs to IBGP peers by 222 default, while others do not. This behavior may result in sub- 223 optimal route selection within an AS. In addition, some 224 implementations send MEDs to EBGP peers by default, while others do 225 not. This behavior may result in sub-optimal inter-domain route 226 selection. 228 2.2. MED Values and Preferences 230 Some implementations consider an MED value of zero as less preferable 231 than no MED value. This behavior resulted in path selection 232 inconsistencies within an AS. The current draft version of the BGP 233 specification [BGP4] removes ambiguities that existed in [RFC 1771] 234 by stating that if route n has no MULTI_EXIT_DISC attribute, the 235 lowest possible MULTI_EXIT_DISC value (i.e. 0) should be assigned to 236 the attribute. 238 It is apparent that different implementations and different versions 239 of the BGP draft specification have been all over the map with 240 interpretation of missing-MED. For example, earlier versions of the 241 specification called for a missing MED to be assigned the highest 242 possible MED value (i.e., 2^32-1). 244 In addition, some implementations have been shown to internally 245 employ a maximum possible MED value (2^32-1) as an "infinity" metric 246 (i.e., the MED value is used to tag routes as unfeasible), and would 247 upon on receiving an update with an MED value of 2^32-1 rewrite the 248 value to 2^32-2. Subsequently, the new MED value would be propagated 249 and could result in routing inconsistencies or unintended path 250 selections. 252 As a result of implementation inconsistencies and protocol revision 253 variances, many network operators today explicitly reset all MED 254 values on ingress to conform to their internal routing policies 255 (i.e., to include policy that requires that MED values of 0 and 256 2^32-1 NOT be used in configurations, whether the MEDs are directly 257 computed or configured), so as to not have to rely on all their 258 routers having the same missing-MED behavior. 260 2.3. Comparing MEDs Between Different Autonomous Systems 262 The MED was intended to be used on external (inter-AS) links to 263 discriminate among multiple exit or entry points to the same 264 neighboring AS. However, a large number of MED applications now 265 employ MEDs for the purpose of determining route preference between 266 like routes received from different autonomous systems. 268 A large number of implementations provide the capability to enable 269 comparison of MEDs between routes received from different neighboring 270 autonomous systems. While this capability has demonstrated some 271 benefit (e.g., that described in [RFC 3345]), operators should be 272 wary of the potential side effects with enabling such a function. 273 The deployment section below provides some examples as to why this 274 may result in undesirable behavior. 276 2.4. MEDs, Route Reflection and AS Confederations for BGP 278 In particular configurations, the BGP scaling mechanisms defined in 279 "BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC 2796] 280 and "Autonomous System Confederations for BGP" [RFC 3065] will 281 introduce persistent BGP route oscillation [RFC 3345]. The problem 282 is inherent in the way BGP works: a conflict exists between 283 information hiding/hierarchy and the non-hierarchical selection 284 process imposed by lack of total ordering caused by the MED rules. 285 Given current practices, we see the problem most frequently manifest 286 itself in the context of MED + route reflectors or confederations. 288 One potential way to avoid this is by configuring inter-Member-AS or 289 inter-cluster IGP metrics higher than intra-Member-AS IGP metrics 290 and/or using other tie breaking policies to avoid BGP route selection 291 based on incomparable MEDs. Of course, IGP metric constraints may be 292 unreasonably onerous for some applications. 294 Comparing MEDs between differing adjacent autonomous systems (which 295 is discussed in other sections), or not utilizing MEDs at all, 296 significantly decreases the probability of introducing potential 297 route oscillation conditions into the network. 299 Although perhaps "legal" as far as current specifications are 300 concerned, modifying MED attributes received on any type of IBGP 301 session (e.g., standard IBGP, AS confederations EIBGP, route 302 reflection, etc..) is NOT recommended. 304 2.5. Route Flap Damping and MED Churn 306 MEDs are often derived dynamically from IGP metrics or additive costs 307 associated with an IGP metric to a given BGP NEXT_HOP. This 308 typically provides an efficient model for ensuring that the BGP MED 309 advertised to peers used to represent the best path to a given 310 destination within the network is aligned with that of the IGP within 311 a given AS. 313 The consequence with dynamically derived IGP-based MEDs is that 314 instability within an AS, or even on a single given link within the 315 AS, can result in wide-spread BGP instability or BGP route 316 advertisement churn that propagates across multiple domains. In 317 short, if your MED "flaps" every time your IGP metric flaps, you're 318 routes are likely going to be suppressed as a result of BGP Route 319 Flap Damping [RFC 2439]. 321 Employment of MEDs may compound the adverse effects of BGP flap 322 dampening behavior because it many cause routes to be re- advertised 323 solely to reflect an internal topology change. 325 Many implementations don't have a practical problem with IGP 326 flapping, they either latch their IGP metric upon first advertisement 327 or they employ some internal suppression mechanism. Some 328 implementations regard BGP attribute changes as less significant than 329 route withdrawals and announcements to attempt to mitigate the impact 330 of this type of event. 332 2.6. Effects of MEDs on Update Packing Efficiency 334 Multiple unfeasible routes can be advertised in a single BGP Update 335 message. The BGP4 protocol also permits advertisement of multiple 336 prefixes with a common set of path attributes to be advertised in a 337 single update message, this is commonly referred to as "update 338 packing". When possible, update packing is recommended as it 339 provides a mechanism for more efficient behavior in a number of 340 areas, to include: 342 o Reduction in system overhead due to generation or receipt of 343 fewer Update messages. 345 o Reduction in network overhead as a result of fewer packets and 346 lower bandwidth consumption. 348 o Allows processing of path attributes and searches for matching 349 sets in your AS_PATH database (if you have one) less frequently. 350 Consistent ordering of the path attributes allows for ease of 351 matching in the database as you don't have different 352 representations 353 of the same data. 355 Update packing requires that all feasible routes within a single 356 update message share a common attribute set, to include a common 357 MULTI_EXIT_DISC value. As such, potential wide-scale variance in MED 358 values introduces another variable and may resulted in a marked 359 decrease in update packing efficiency. 361 2.7. Temporal Route Selection 363 Some implementations have had bugs which lead to temporal behavior in 364 MED-based best path selection. These usually involved methods used 365 to store the oldest route along with ordering routes for MED in 366 earlier implementations that cause non-deterministic behavior on 367 whether the oldest route would truly be selected or not. 369 The reasoning for this is that "older" paths are presumably more 370 stable, and thus more preferable. However, temporal behavior in 371 route selection results in non-deterministic behavior, and as such, 372 is often undesirable. 374 3. Deployment Considerations 376 It has been discussed that accepting MEDs from other autonomous 377 systems have the potential to cause traffic flow churns in the 378 network. Some implementations only ratchet down the MED and never 379 move it back up to prevent excessive churn. 381 However, if a session is reset, the MEDs being advertised have the 382 potential of changing. If an network is relying on received MEDs to 383 route traffic properly, the traffic patterns have the potential for 384 changing dramatically, potentially resulting in congestion on the 385 network. Essentially, accepting and routing traffic based on MEDs 386 allows other people to traffic engineer your network. This may or may 387 not be acceptable to you. 389 As previously discussed, many network operators choose to reset MED 390 values on ingress. In addition, many operators explicitly do not 391 employ MED values of 0 or 2^32-1 in order to avoid inconsistencies 392 with implementations and various revisions of the BGP specification. 394 3.1. Comparing MEDs Between Different Autonomous Systems 396 Although the MED was meant to only be used when comparing paths 397 received from different external peers in the same AS, many 398 implementations provide the capability to compare MEDs between 399 different autonomous systems as well. AS operators often use 400 LOCAL_PREF to select the external preferences (primary, secondary 401 upstreams, peers, customers, etc.), using MED instead of LOCAL_PREF 402 would possibility lead to an inconsistent distribution of best routes 403 as MED is compared only after the AS_PATH length. 405 Though this may seem a fine idea for some configurations, care must 406 be taken when comparing MEDs between different autonomous systems. 407 BGP speakers often derive MED values by obtaining the IGP metric 408 associated with reaching a given BGP NEXT_HOP within the local AS. 409 This allows MEDs to reasonably reflect IGP topologies when 410 advertising routes to peers. While this is fine when comparing MEDs 411 between multiple paths learned from a single AS, it can result in 412 potentially "weighted" decisions when comparing MEDs between 413 different autonomous systems. This is most typically the case when 414 the autonomous systems use different mechanisms to derive IGP 415 metrics, BGP MEDs, or perhaps even use different IGP protocols with 416 vastly contrasting metric spaces (e.g., OSPF v. traditional metric 417 space in IS-IS). 419 3.2. Effects of Aggregation on MEDs` 421 Another MED deployment consideration involves the impact that 422 aggregation of BGP routing information has on MEDs. Aggregates are 423 often generated from multiple locations in an AS in order to 424 accommodate stability, redundancy and other network design goals. 425 When MEDs are derived from IGP metrics associated with said 426 aggregates the MED value advertised to peers can result in very 427 suboptimal routing. 429 4. Security Considerations 431 The MED was purposely designed to be a "weak" metric that would only 432 be used late in the best-path decision process. The BGP working 433 group was concerned that any metric specified by a remote operator 434 would only affect routing in a local AS IF no other preference was 435 specified. A paramount goal of the design of the MED was to ensure 436 that peers could not "shed" or "absorb" traffic for networks that 437 they advertise. As such, accepting MEDs from peers may in some sense 438 increase a network's susceptibility to exploitation by peers. 440 4.1. Acknowledgments 442 Thanks to John Scudder for applying his usual keen eye and 443 constructive insight. Also, thanks to Curtis Villamizar, JR Mitchell 444 and Pekka Savola for their valuable feedback. 446 5. References 447 5.1. Normative References 449 [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless 450 Inter-Domain Routing (CIDR): an Address Assignment and 451 Aggregation Strategy", RFC 1519, September 1993. 453 [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 454 (BGP-4)", RFC 1771, March 1995. 456 [RFC 2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection 457 - An Alternative to Full Mesh IBGP", RFC 2796, April 458 2000. 460 [RFC 3065] Traina, P., McPherson, D., Scudder, J.. "Autonomous System 461 Confederations for BGP", RFC 3065, February 2001. 463 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border 464 Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 466 5.2. Informative References 468 [RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping", 469 RFC 2439, November 1998. 471 [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP 472 Persistent Route Oscillation Condition", RFC 3345, 473 August 2002. 475 6. Authors' Addresses 477 Danny McPherson 478 Arbor Networks 479 Email: danny@arbor.net 481 Vijay Gill 482 AOL 483 Email: VijayGill9@aol.com 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Disclaimer of Validity 511 This document and the information contained herein are provided on an 512 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 513 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 514 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 515 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 516 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 517 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 519 Copyright Statement 521 Copyright (C) The Internet Society (2005). This document is subject 522 to the rights, licenses and restrictions contained in BCP 78, and 523 except as set forth therein, the authors retain all their rights. 525 Acknowledgment 527 Funding for the RFC Editor function is currently provided by the 528 Internet Society.