idnits 2.17.1 draft-li-bgp-stability-00.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 25, 2007) is 6180 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: 'TON-1998' is mentioned on line 519, but not defined == Missing Reference: 'Infocom-1999' is mentioned on line 491, but not defined == Missing Reference: 'FTCS-1999' is mentioned on line 486, but not defined == Missing Reference: 'Sigcomm-2000' is mentioned on line 510, but not defined == Missing Reference: 'Infocom-2001' is mentioned on line 495, but not defined == Missing Reference: 'Sigcomm-2002' is mentioned on line 514, but not defined == Missing Reference: 'PCC-2004' is mentioned on line 504, but not defined == Missing Reference: 'Infocom-2005' is mentioned on line 500, but not defined Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing T. Li 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track May 25, 2007 5 Expires: November 26, 2007 7 BGP Stability Improvements 8 draft-li-bgp-stability-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 26, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 BGP is the routing protocol used to tie the Autonomous Systems (ASes) 42 of the Internet together. The ongoing stability of BGP in the face 43 of arbitrary inputs, both malicious and unintentional, is of primary 44 importance to the overall stability of the Internet. The overall 45 issue is not a new one. Previously, one aspect of stability, known 46 as route flap damping was originally discussed in RFC 2439. In the 47 intervening years, a great deal of experience with flap damping and 48 other stability concerns has been accumulated. Most recently, the 49 issue of BGP stability has been highlighted in RAWS. This document 50 describes the experience that has been gained concerning stability in 51 the intervening years, hypotheses about remaining problems, 52 suggestions for experiments to be performed, and proposals for 53 possible alternatives. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Observations . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3.1. Path hunting . . . . . . . . . . . . . . . . . . . . . 4 62 1.4. The wavefront model . . . . . . . . . . . . . . . . . . . 5 63 1.4.1. Refraction . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Flap damping . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Rapid convergence . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Reduced overhead . . . . . . . . . . . . . . . . . . . . . 6 68 3. Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Turn it off . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Alternate parameters . . . . . . . . . . . . . . . . . . . 7 71 3.3. Band pass filtering . . . . . . . . . . . . . . . . . . . 7 72 3.4. Path length damping . . . . . . . . . . . . . . . . . . . 7 73 3.5. Optimal path hysteresis . . . . . . . . . . . . . . . . . 8 74 3.6. Delayed best path selection . . . . . . . . . . . . . . . 9 75 4. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1. Call for collaboration . . . . . . . . . . . . . . . . . . 9 77 4.2. Literature search . . . . . . . . . . . . . . . . . . . . 9 78 4.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.4. Prototyping, Testing and Pilot Deployment . . . . . . . . 10 80 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 8.3. Potential References . . . . . . . . . . . . . . . . . . . 11 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 Intellectual Property and Copyright Statements . . . . . . . . . . 13 90 1. Introduction 92 BGP [RFC4271] is the routing protocol used to tie the Autonomous 93 Systems (ASes) of the Internet together. The ongoing stability of 94 BGP in the face of arbitrary inputs, both malicious and 95 unintentional, is of primary importance to the overall stability of 96 the Internet. The overall issue is not a new one. Previously, one 97 aspect of stability, known as route flap damping was originally 98 discussed in RFC 2439 [RFC2439]. In the intervening years, a great 99 deal of experience with flap damping and other stability concerns has 100 been accumulated. Most recently, the issue of BGP stability has been 101 highlighted in RAWS [I-D.iab-raws-report]. This document describes 102 the experience that has been gained concerning stability in the 103 intervening years, hypotheses about remaining problems, suggestions 104 for experiments to be performed, and proposals for possible 105 alternatives. 107 Please note that this document is very much a work-in-progress. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 1.2. History 117 The circuits used in computer networks have the unfortunate property 118 that they can intermittently fail and then recover. This was an 119 especially common failure mode for copper-based circuits. Under such 120 circumstances, when there was a BGP speaker on both ends of the 121 circuit, any prefixes advertised across the link would tend to 122 oscillate at the frequency induced by the intermittent link. The 123 oscillating prefixes would then propagate across the full Internet, 124 causing the entire routing subsystem to churn at the rate of the 125 prefix. 127 Individually, a single such prefix is not a significant issue. 128 However, as the Internet continued to scale upwards, it became 129 obvious that the CPU requirements to deal with the ever-increasing 130 number of oscillating prefixes would quickly become onerous. This 131 was aggravated by the fact that the party responsible for the 132 flapping circuit was frequently unaware of the problem, or, worse 133 yet, unwilling to address the issue. 135 Thus, the original goal of route flap damping was to protect the 136 control plane from oscillations. This was done by determining the 137 number of flaps and the time elapsed since the last transition. This 138 is fed into an exponential decay function, and, if the prefix is 139 found to be flapping based on this data, the actual propagation of 140 the route is suppressed. Since the frequency information must be 141 stored even if the prefix is not currently active, there is state 142 overhead associated with flap damping for each prefix that has been 143 oscillating. 145 1.3. Observations 147 Unfortunately, flap damping isn't truly discerning about the nature 148 of routing changes. Any routing change can easily be misinterpreted 149 by flap damping as instability, resulting in premature damping of 150 prefixes [Harmful]. 152 1.3.1. Path hunting 154 One source of path changes is BGP's normal mechanism for _path 155 exploration_ or _path hunting_. These situations occur because BGP 156 is a path-vector protocol, where each BGP speaker advertises the path 157 that it is using to its neighbors, complete with the full AS path to 158 the destination. Since the number of possible paths through even a 159 simple topology is large, there can be many different path 160 transitions that can possibly be advertised. 162 Path hunting can occur both when a prefix is first advertised or when 163 a prefix is withdrawn. At advertisement time, the prefix may 164 propagate through the topology at different rates, sometimes 165 resulting in it first appearing at an AS with a suboptimal path. 166 Over time, optimal paths will appear where suboptimal paths were 167 before, resulting in a path change that is subsequently propagated. 169 Similarly, when a prefix is withdrawn from the network, each AS that 170 receives the withdraw will select some other historical path and 171 propagate it. If the historical path is subsequently withdrawn, the 172 AS will again select another historical path. This will continue 173 until the entire possible path space has been explored and eventually 174 withdrawn. 176 Interestingly, the amount of path hunting can increase dramatically 177 as the meshiness of the topology increases. It's easy to observe 178 this if you first consider an acyclic topology (i.e., a tree). In 179 such a topology, there is only one possible path, so there is no 180 hunting. If a single link is added to this topology, then there is 181 one cycle in the graph and at most two possible paths for BGP to 182 explore. Subsequent links can add many more alternate paths, 183 depending on their placement. 185 1.4. The wavefront model 187 An intuitive means of understanding the observed behavior is by 188 analogy to a wavefront. Any change in the network triggers the 189 dissemination of information (either updates or withdrawals) through 190 the topology from the point of occurrence. The information travels 191 outwards along all of the paths supported by BGP, in much the same 192 way that a wave would propagate from a pebble dropped in a lake. 194 The wavefront expands at each BGP speaker, where the information is 195 propagated to all other BGP peers, including ones that already have 196 the information. If the newly arrived information is inferior to the 197 existing path information, then the wave dies out at that BGP 198 speaker. If the newly arrived path is the best path, then it 199 continues to be the wavefront of the best information. It's easy to 200 see from this that a single change in the network can thus generate 201 multiple waves. 203 1.4.1. Refraction 205 As can be seen from the above, information does not traverse the full 206 BGP mesh at fixed rates. Differences in implementations, processing 207 loads, propagation delay, damping parameters, and policy can all 208 contribute to delaying optimal path information. Continuing the 209 wavefront analogy, we know that waves propagate through different 210 materials at different speeds. This phenomenon is known as 211 _refraction_, and as seen above, can lead to the multiplication of 212 wavefronts. Each additional wavefront represents additional 213 processing burden on the routing subsystem. 215 It is interesting to note that flap damping itself may be a 216 contributor to the creation of additional wavefronts. Since a route 217 that is being damped will be delayed for a long time, damping is 218 effectively delaying a wave of information, possibly creating more 219 refractive effects. 221 2. Goals 223 2.1. Flap damping 225 As we reconsider the mechanisms that constitute flap damping, we need 226 to keep in mind that the original goals of detecting and protecting 227 the routing subsystem from noisy inputs is still a requirement. 228 While copper circuits are now less common in the core, the overall 229 network has expanded dramatically and there is a wide variance in the 230 skills and experience in operational roles. 232 As a result, it is still possible for an errant AS to inject flapping 233 information into the BGP mesh, either as the result of policy 234 misconfiguration, implementation error, an intermittent circuit, or 235 even as an intentional destructive act. Thus, it is important that 236 there still be mechanisms that intervene and ameliorate these 237 effects, protecting the routing subsystem. 239 2.2. Rapid convergence 241 While protecting the routing system is of paramount importance, it is 242 also vital that the routing subsystem also continue to perform its 243 primary task: providing routing. Any flap damping mechanism must 244 continue to provide rapid convergence to some workable path so that 245 connectivity is restored. However, this goal should not be construed 246 to require rapid optimality. While a best path should eventually be 247 selected and propagated, it is far more important that some 248 connectivity be restored immediately. Most applications can survive 249 with a sub-optimal path, while no applications can succeed if no path 250 is selected. 252 2.3. Reduced overhead 254 Flap damping should also strive to deter the unnecessary exchange of 255 information. As described above, both path hunting and refractive 256 effects cause unnecessary churn in BGP. The flap damping mechanism 257 should be generalized to help suppress as much of this unnecessary 258 information as possible. 260 3. Hypotheses 262 In this section, we put forth a number of hypotheses about possible 263 mechanisms to achieve the goals above. As of this writing, more 264 investigation is needed on each of these theories, and where possible 265 we've included some discussion of the experiments that we feel would 266 be worthwhile. Our goal here is to examine a number of different 267 mechanisms, understand their relative benefits, and select a small 268 subset to become the core set of replacement mechanisms. 270 3.1. Turn it off 272 Given the concern about the refractive effects of path damping, 273 [RIPE-378] recommends that path damping be disabled. While this is 274 not unreasonable given the lack of beneficial alternatives, we feel 275 that some of the possibilities presented here will eventually prevail 276 and that this sentiment can be changed over time. 278 3.2. Alternate parameters 280 It has been suggested in [Harmful] that the default flap damping 281 parameters in existing implementations are simply too aggressive and 282 quickly convert normal path hunting into a damping event that 283 precludes connectivity. Significantly increasing the parameters 284 could permit significantly more churn to be passed by the routing 285 subsystem while still filtering out truly periodic sources of flap. 287 It would be useful to test this by simply configuring numerous 288 differing parameters and observing if there is any beneficial effect. 289 At this time, we have no recommendations for possible alternative 290 parameter settings. 292 3.3. Band pass filtering 294 Another view is that classical flap damping isn't working as well as 295 we might like because it is measuring frequency. The current 296 mechanism looks for a number of changes in a given period of time. 297 If the route exceeds this threshold frequency, then it is damped. 298 The threshold frequency is necessarily set fairly low so that it will 299 damp true flapping circuits. 301 Unfortunately, path hunting creates a high frequency burst that 302 incorrectly triggers damping. This acts as a false positive for 303 damping that we would like to avoid. One alternative approach is to 304 shift from looking for flapping above a given frequency and simply 305 accept that when there is a real topological change, there will be 306 extensive high frequency path changes. After some time, those path 307 changes should stop and the route should then resume its stability. 308 Subsequent path changes would then be indicative of real oscillation 309 and would be subject to damping. 311 The implementation of this would be relatively straightforward. When 312 a change is seen on a stable route, it opens an oscillation window of 313 a fixed duration (e.g., 60s). Any changes within that window are not 314 considered as contributing to flap damping. After the window is 315 closed, any subsequent changes would count as significant events 316 towards damping. Effectively, this technique creates a filter that 317 passes very, very low frequencies and high frequencies, but will 318 detect and deter ongoing route changes within a certain frequency 319 band. This is normally known as a band pass filter. 321 3.4. Path length damping 323 The increased meshiness of the core of the Internet has significantly 324 changed the nature of path changes that are visible in BGP. As the 325 meshiness of the network increases, the number of parallel links 326 between any given pair of ASes tends to increase. This helps protect 327 against single link failures between ASes. This also reduces the 328 frequency of AS path changes on transit prefixes because most of the 329 link failures in the densely meshed part of the network will not 330 result in AS path change. 332 As a result, when a BGP speaker does see a change in the AS path, and 333 in particular, when the AS path length increases, this would seem to 334 be a good heuristic indication that there is some significant failure 335 in the less densely meshed portion of the network. As a result, it 336 seems likely that such failures are less likely to have alternative 337 working paths and that the increase in path length is a harbinger of 338 path hunting that is likely to be unsuccessful. We therefore suggest 339 that this event could be used to trigger a flap suppression period, 340 which would allow the prefix to oscillate arbitrarily without 341 propagation to the remainder of the network. The obvious risk is 342 that this would be a false negative, unnecessarily disrupting 343 connectivity. 345 Again, the implementation of this would be relatively 346 straightforward. When a BGP speaker found that it needed to change 347 its best path for a prefix and that the new best path was longer than 348 the previous best path, then it would issue withdraw messages to its 349 neighbors and start a timer. Subsequent changes to the prefix would 350 restart the timer. When the timer expired, the BGP speaker would 351 perform a normal best path election and advertise the result, if any. 353 3.5. Optimal path hysteresis 355 It has been observed that the overall topology of the Internet at the 356 AS level changes at a fairly low rate. Thus, the optimal AS path to 357 a given prefix, ignoring transient issues, changes at a very low 358 rate. This suggests that caching the optimal AS path and waiting for 359 it to reappear would be another alternative heuristic to help select 360 only the long-term optimal path. 362 An implementation of this technique might retain a copy of the AS 363 path on per-prefix basis, even if it had no active path to the 364 prefix. Because most implementations maintain a cache of AS paths, 365 this is not necessarily prohibitively expensive. When a new AS path 366 is received for a prefix, the new path is compared to the cached 367 optimal path. If it matches, or it is preferable to the stored 368 optimal path, then the new path is immediately accepted, advertised, 369 and the cache can be updated appropriately. However, if the new AS 370 path is inferior to the cached path, then the implementation can 371 infer that there is some path hunting in progress and can choose to 372 either not perform best path selection, not select the new path, or 373 not advertise the new path. Again, after a suitable period has 374 elapsed, the implementation may decide that the optimal path is 375 unlikely to appear and may process the inferior path normally. 377 3.6. Delayed best path selection 379 Another observation based on the discussion in section Section 1.4.1 380 is that the amount of flap is exacerbated by each AS selecting the 381 best possible path each time a new path is presented. This is not 382 strictly required by BGP, so ignoring some of the incoming paths 383 would be perfectly acceptable. Further, an implementation could 384 reasonably delay performing any best path analysis for an arbitrarily 385 long time, as long as it continued to advertise the path it actually 386 used. Thus, one possible policy would be to only perform best path 387 selection when absolutely required. When the first path for a prefix 388 arrives, the implementation would immediately select that path, 389 thereby restoring connectivity. Subsequent paths from other 390 neighbors for the same prefix would not trigger a new best path 391 computation. Rather, they would simply start a timer that would only 392 expire when the paths had stabilized. 394 4. Next steps 396 4.1. Call for collaboration 398 As can be seen from the above, there is a great deal of work yet to 399 be done on this subject. Collaborators are most welcome in any 400 aspect of the work. 402 4.2. Literature search 404 There are a number of technical articles listed below that have been 405 published on BGP flap damping and stability that need to be reviewed 406 and included if they prove substantive. A few known ones are listed 407 here. There are very likely a number of other articles in the 408 literature that are relevant. 410 [TON-1998] 412 [Infocom-1999] 414 [FTCS-1999] 416 [Sigcomm-2000] 418 [Infocom-2001] 420 [Sigcomm-2002] 422 [PCC-2004] 424 [Infocom-2005] 426 4.3. Analysis 428 A number of projects have collected traces of BGP update messages 429 that demonstrate both flap and path hunting. It would be of great 430 interest to examine the effects of some of the proposal in Section 3 431 in detail on these traces. 433 4.4. Prototyping, Testing and Pilot Deployment 435 After some analysis, it would then be helpful to actually implement 436 the most useful possible solutions in a number of BGP 437 implementations. Since this is a change to BGP, extensive testing is 438 going to be necessary and a period of pilot deployment will be 439 required. Implementers, testers, and operators could help accelerate 440 this portion of the project. 442 5. Acknowledgments 444 This document builds on the work of RFC 2439 [RFC2439] and we would 445 like to thank Curtis Villamizar, Ravi Chandra, and Ramesh Govindan 446 for their excellent work. 448 6. IANA Considerations 450 This memo includes no requests to IANA. 452 7. Security Considerations 454 This document raises no new security issues. 456 8. References 458 8.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 464 Protocol 4 (BGP-4)", RFC 4271, January 2006. 466 8.2. Informative References 468 [Harmful] Bush, R., Griffin, T., and Z. Mao, "Route flap damping: 469 harmful?", . 471 [I-D.iab-raws-report] 472 Meyers, D., "Report from the IAB Workshop on Routing and 473 Addressing", draft-iab-raws-report-02 (work in progress), 474 April 2007. 476 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 477 Flap Damping", RFC 2439, November 1998. 479 [RIPE-378] 480 Smith, P. and C. Panigl, "RIPE Routing Working Group 481 Recommendations on Route-flap Damping", 482 . 484 8.3. Potential References 486 [FTCS-1999] 487 Labovitz, C., Ahuja, A., and F. Jahanian, "Experimental 488 Study of Internet Stability and Wide-Area Network 489 Failures", FTCS 1999. 491 [Infocom-1999] 492 Labovitz, C., Malan, G., and F. Jahanian, "Origins of 493 Internet Routing Instability", Infocom 1999. 495 [Infocom-2001] 496 Labovitz, C., Ahuja, A., Wattenhofer, R., and S. 497 Venkatachary, "The Impact of Internet Policy and Topology 498 on Delayed Routing Convergence", Infocom 2001. 500 [Infocom-2005] 501 Chandrashekar, J., Duan, Z., Zhang, Z., and J. Krasky, 502 "Limiting path exploration in BGP", Infocom 2005. 504 [PCC-2004] 505 Duan, Z., Chandrashekar, J., Krasky, J., Xu, K., and Z. 506 Zhang, "Damping BGP Route Flaps", IEEE International 507 Conference on Performance, Computing, and 508 Communications 2002. 510 [Sigcomm-2000] 511 Labovitz, C., Ahuja, A., Bose, A., and F. Jahanian, 512 "Delayed Internet Routing Convergence", Sigcomm 2000. 514 [Sigcomm-2002] 515 Mao, Z., Govindan, R., Varghese, G., and R. Katz, "Route 516 Flap Damping Exacerbates Internet Routing Convergence", 517 Sigcomm 2002. 519 [TON-1998] 520 Labovitz, C., Malan, G., and F. Jahanian, "Internet 521 Routing Instability", TON 1998. 523 Author's Address 525 Tony Li 526 Cisco Systems, Inc. 527 170 W. Tasman Dr. 528 San Jose, CA 95134 529 US 531 Phone: +1 408 853 1494 532 Email: tli@cisco.com 534 Full Copyright Statement 536 Copyright (C) The IETF Trust (2007). 538 This document is subject to the rights, licenses and restrictions 539 contained in BCP 78, and except as set forth therein, the authors 540 retain all their rights. 542 This document and the information contained herein are provided on an 543 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 544 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 545 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 546 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 547 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 548 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Intellectual Property 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Acknowledgment 576 Funding for the RFC Editor function is provided by the IETF 577 Administrative Support Activity (IASA).