idnits 2.17.1 draft-dimitri-grow-rss-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 648. 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 (July 13, 2008) is 5765 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 54, but not defined == Missing Reference: 'Fuller07' is mentioned on line 91, but not defined == Unused Reference: 'Labovitz00' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'Li07' is defined on line 560, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou 3 Internet Draft J. Lowe 4 Intended Status: Informational Alcatel-Lucent 5 Created: July 13, 2008 6 Expires: January 12, 2009 8 Routing System Stability 10 draft-dimitri-grow-rss-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 12, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 Understanding the dynamics of the Internet routing system is 44 fundamental to ensure its robustness/stability and to improve the 45 mechanisms of the BGP routing protocol. This documents outlines a 46 program of activity for identifying, documenting and analyzing the 47 dynamic properties of the Internet and its routing system. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Document History 57 This is the initial version of this document. 59 1. Introduction 61 Understanding the dynamics of the Internet routing system is 62 fundamental to ensuring its stability and improving the mechanisms of 63 the BGP routing protocol [RFC4271]. Investigations on the Internet 64 routing system dynamics involve investigations on routing engine 65 resource consumption, in particular, memory and CPU. 67 System resource consumption depends on two items. First, there is the 68 size of the routing space. The greater the number of routing entries 69 there are, the greater the memory requirement on a routing device, 70 and the greater the need for increased processing and searching 71 capabilities to perform lookup operations. Second, the greater the 72 number of adjacency and peering relationships between routing 73 devices, the greater the dynamics associated with the routing 74 information updates exchanged between all these adjacencies and 75 peerings. This activity also increases the memory requirements for 76 the operation of the routing protocol. 78 In other words, as the routing system grows [Huston07a], so do the 79 requirements for routing engine memory and processing capacity. From 80 a routing dynamics viewpoint, minimizing the amount of BGP routing 81 information exchanged by routers is key to grappling with increasing 82 requirements on memory and CPU. 84 So, although current routing engines could potentially support up to 85 O(1M) routing table entries instabilities resulting i) from routing 86 protocol behavior, ii) routing protocol information exchanges, and 87 iii) changes in network topology may adversely affect the network's 88 ability to remain in a useable state for extended periods of time. 89 Note however that in terms of number of active routing entries, such 90 routing engine could at worst have to deal with O(1M) routes 91 within the next 5 years, see [Fuller07]. 93 2. Objectives 95 The overall goal is to identify, root cause and document - in a 96 structured manner - occurrences of Internet routing stability 97 phenomena using data from operational networks. 99 To help accomplish this goal, the following tasks will be undertaken. 101 1. Development of a methodology to process and interpret routing 102 table data. One guiding principle will be to be able to reproduce 103 phenomena previously observed at different locations. This work 104 will include documenting what information to collect and how it 105 should be archived. 107 2. Identification of a set of stability criteria and development of 108 methods for using them to provide a better understanding of the 109 routing system's stability. Other working groups may find this 110 beneficial in addition to the GROW working group. 112 3. Begin investigation into how routing protocol behavior and network 113 dynamics mutually influence each other. The nature of the 114 observations collected in the first task will suggest directions 115 to proceed with this work. 117 This proposed approach would allow rigor and consistency to be 118 brought to the study of network and routing stability. For example, 119 it would allow for a unified approach to the cross-validation of 120 techniques for looking at improving path exploration effects on the 121 routing system. 123 3. Relevance to the GROW working group charter 125 This effort fits into the GROW working group's charter to deal with 126 BGP operational issues related to routing table growth rates and the 127 dynamic properties of the routing system. 129 GROW has an advisory role to the IDR working group to provide 130 commentary on whether BGP is addressing relevant operational needs 131 and, where appropriate, suggest course corrections, which puts this 132 effort in a central place in the BGP investigation process. 134 Also, since the GROW working group community is directly linked to 135 the broader BGP operational community, this effort goes together with 136 obtaining routing table data from the field. 138 4. Routing system stability 140 In order to begin the discussion defined in work item detailed in 141 Section 2, point 2, this section proposes a number of definitions for 142 common routing and network stability terms. 144 The stability of a routing system is characterized by its response 145 (in terms of processing routing information) to inputs of finite 146 amplitude. 148 These inputs may be classified as either internal system events, such 149 as routing protocol configuration changes, or as external system 150 events, such as routing information updates. Such events are 151 sometimes loosely referred to as routing "instabilities"; however, 152 this term should be reserved for discussion about how the routing 153 system responds to such events. 155 A routing system, which returns to its initial equilibrium state, 156 when disturbed by an external and/or internal event, is considered to 157 be stable. 159 A routing system, which transitions to a new equilibrium state, when 160 disturbed by an external and/or internal event, is considered to be 161 marginally stable. 163 Such state transitions, whether stable or marginal, should occur 164 before the arrival of new input events. 166 The magnitude of the output of a stable routing system is small 167 whenever the input is small. That is, a single routing information 168 update shall not result in output amplification. Equivalently, a 169 stable system's output will always decrease to zero whenever the 170 input events stop. 172 A routing system, which remains in an unending condition of 173 transition from one state to another when disturbed by an external or 174 internal event, is considered to be unstable. 176 The degree to which a routing system, or components thereof, can 177 function correctly in the presence of input events is a measure of 178 the robustness of the system. 180 A precise definition of stability requires the specification of the 181 following elements: 183 o) The system being examined: for example, a system might be 184 comprised of: the routing system and associated events, such as 185 input events, outputs, and related arrival rates. 187 o) A convergence metric: a metric to define the convergence 188 characteristics of the system. 190 o) A stability metric: a metric that describes the degree of 191 stability of the system and indicates how close the system is to 192 being unstable. 194 The convergence and stability metrics may be affected by the 195 following parameters: 197 o) The number of routing entries (where, each entry R toward an 198 existing prefix D has an associated attribute set A consisting of 199 AS-Path, MED, and Local Preference, etc.); 201 o) The number of CPU cycles, C, required to process a routing entry, 202 and its associated memory space, M; 204 o) The input events and their arrival rates; 206 o) The output events associated with the processing of each input 207 event. 209 5. Mathematical formulation 211 Section 4 outlined some proposals for definitions of commonly used 212 stability terms applied to network and routing systems. In this 213 section, an initial attempt is made to build a mathematical 214 formulation around those concepts in order to begin the development 215 of more practical metrics. 217 5.1 General Formulation 219 Let RT be the "Routing Table" and RT(n) represent the routing table 220 at some time n. At time n+1, the routing table can be expressed as 221 the sum of two components: 223 RT(n+1) = RTo(n) + deltaRT(n+1) (1) 225 In this equation, RTo(n) is the set of routes that experience no 226 change between n and n+1, and deltaRT(n+1) accounts for all route 227 changes (additions, deletions, and changes to previously existing 228 routes) between n and n+1. deltaRT(n+1) itself can expressed as the 229 sum of two components: 231 deltaRT(n+1) = RTc(n+1) + RTn(n+1) (2) 233 In this equation, RTc(n+1) is a set of routes at time n that 234 experience some sort of change at time n+1. Rtn(n+1) is a set of new 235 routes observed at time n+1 that were not present at time n. 237 RTc and RTn are each composed of two parts: one due to changes in 238 network state (new routes appearing, changes to existing routes, 239 etc.), and a second attributable to routing protocol changes (BGP 240 session failure, BGP route attribute changes, changes to filtering 241 policies, etc.). Equation (1) can be expanded to account for these 242 separate effects. First, substitute equation (2) into equation (1): 244 RT(n+1) = RTo(n) + RTc(n+1) + RTn(n+1) (3) 245 As was mentioned, the terms RTc(n+1) and RTn(n+1) can be further 246 expanded into their two constitute components: 248 RTc(n+1) = RTcN(n+1) + RTcR(n+1) (4) 250 RTn(n+1) = RTnN(n+1) + RTnR(n+1) (5) 252 In these two equations, "N" denotes the component due to network 253 topology changes, and "R" denotes the component due to routing 254 protocol changes. 256 These equations can be used as the basis for deriving the convergence 257 and stability metrics discussed in Section 4. However, there are a 258 number of issues that will need to be resolved in order to make 259 progress: 261 a) Some thought will need to be done on how to distinguish between 262 network and routing protocol effects; 264 b) Some thought needs to be given to "timescales of applicability" 265 in order to make assessments about what constitutes instability 266 in a routing system from a practical point-of-view; 268 c) Some thought needs to given to how a protocol can absorb network 269 instabilities. [RFC2902] touches on this issue and indicated that 270 damping the effects of route updates enhances stability, but 271 possibly at the cost of reachability for some prefixes. 273 5.2 Derivation of stability metrics 275 In this section we propose an algorithm for calculating a stability 276 metric for a route and a routing table. 278 First, we should make an attempt to quantify what we mean by stable, 279 marginally stable, and unstable in the context of the routing table 280 RT(n+1). Please note that this work is preliminary and is still in 281 the process of being refined and tested. 283 We can start with the basic equation we previously developed: 285 RT(n+1) = RTo(n) + deltaRT(n+1) 287 Let |deltaRT(n+1)| be the magnitude of the change to the routing 288 table at some time n+1. 290 For a routing table, RT(n+1), to be stable, the following condition 291 must be met: 293 |deltaRT(n+1)| =< alpha as t -> infinity, 294 where alpha is a small, positive number. 296 For marginally stable systems, the following condition must be met: 298 alpha < |deltaRT(n+1)| =< beta as t -> infinity, 300 where beta is a small, positive number, greater than alpha. 302 For unstable systems, the following condition is met: 304 |deltaRT(n+1)| > beta as t -> infinity. 306 One can see that I have not made distinctions for new routes or 307 changed routes, or for the source of disturbances to the system. 308 This is a definition of stability at the highest, or coarsest, 309 level. 311 As well, alpha and beta are going to need to be set based on some 312 sort of operational criteria. Among other things, alpha and beta 313 will be dependent on the observation sampling frequency. 315 In order to be able to compute |deltaRT(n+1)| we need to be able 316 to calculate a stability metric for an individual route. 318 A route, rti(n+1), which is a component of RT(n+1), consists of: 320 rti(n+1) = {destination, path, attributes}. 322 A stability metric for rti might be most easily defined by an 323 algorithm and in the next several paragraphs we will undertake 324 such a development. 326 Let the stability metric associated with a route rti be called fi. 327 When a route is created, the initial value of fi is 0. 329 If rti never experiences any change, then fi remains constant at 0. 331 If rti does experience a change (path or attribute or withdrawal), 332 then fi changes according to the following: 334 if rti(n+1) != rti(n) then 336 /* the route has changed */ 338 fi(n+1) = fi(n) + 1 340 else 342 /* the route did not change */ 344 if fi(n) = 0 then 346 /* fi never drops to less than 0 */ 347 fi(n+1) = 0 349 else 351 /* fi is decremented if there is no change in rti */ 353 fi(n+1) = f(n) - 1 355 end if 357 end if 359 So, how does this work in the case where rti is withdrawn at some 360 time n+1? Conceivably, fi(n+1) is 1 at a minimum when withdrawal 361 occurs, and some non-zero value fi(n)+1, say gamma, at most 362 according to the algorithm. As t increases, fi is kept around 363 until it equals zero, at which time the route, rti, is discarded. 365 With this definition of a stability metric for an individual 366 route, one can take a stab at calculating a stability metric for 367 an entire routing table. 369 |deltarti(n+1)| is introduced as the change in stability metric 370 of a single route, rti, from t=n to t=n+1. It is used to calculate 371 |deltaRT(n+1)|, the stability metric of the entire routing table, 372 RT, at time t=n+1. 374 |deltaRT(n+1)| is normalized so that 0 is the minimum value and 1 375 is the maximum, where 0 implies perfect stability, and so that 1 376 indicates complete instability. 378 Here is the candidate algorithm to evaluate |deltaRT(n+1)|: 380 for i = 1 to number of routes in RT(n+1) 382 if rti(n+1) is a new route then 384 |deltarti(n+1)| = 0 386 else 388 /* rti(n+1) is an existing route */ 390 if fi(n) = 0 and fi(n+1) = 0 then 392 /* no change occured to the route */ 394 |deltarti(n+1)| = 0 396 else 398 /* a change occured to the route */ 400 if fi(n+1) > fi(n) then 401 |deltarti(n+1)| = fi(n+1) / [fi(n+1) + 1] 403 else 405 |deltarti(n+1)| = fi(n+1) / fi(n) 407 end if 409 end if 411 end if 413 end i loop 415 |deltaRT(n+1)| = Sum(deltarti(n+1)) / total number of routes in 416 RT(n+1) 418 We will conclude this section by illustrating some notable 419 properties and showing some example calculations. 421 It should be noted that: 422 - fi(n+1) and fi(n) can only be equal if they are both equal to 0 423 otherwise, fi(n+1) and fi(n) only differ by 1, and there is no 424 theoretical upper limit on either fi(n+1) or fi(n). 425 - 0 =< |deltarti(n+1)| =< 1, but, |deltarti(n+1)| only takes on 426 values from the set: {0, 0/1, 1/2, 2/3, 3/4, 4/5, .. , m/m+1, ..} 427 - 0 =< |deltaRT(n+1)| =< 1, but, the particular values it assumes 428 are continously variable from 0 to 1 unlike |deltarti(n+1)|. 430 The following 3 example calculations show values for |deltaRT(n+1)| 431 in a number of simple, but indicative situations. 433 Example 1: 435 fi(n) = {0, 1, 2, 1, 0, 0} and fi(n+1) = {1, 2, 1, 0, 0, 0} 437 |deltaRT(n+1)| = (1/2 + 2/3 + 1/2 + 0/1 + 0 + 0) / 6 438 |deltaRT(n+1)| = 0.278 (rather stable) 440 Example 2: 442 fi(n) = {0, 0, 0, 0, 0, 0} and fi(n+1) = {1, 1, 1, 1, 1, 1} 444 |deltaRT(n+1)| = (0/1 + 0/1 + 0/1 + 0/1 + 0/1 + 0/1) / 6 445 |deltaRT(n+1)| = 0 (still stable, too early to judge) 447 Example 3: 449 fi(n) = {56, 20, 63, 64, 0, 5} and fi(n+1) = {57, 19, 64, 65, 0, 4} 451 |deltaRT(n+1)| = (57/58 + 19/20 + 64/65 + 65/66 + 0 + 4/5) / 6 452 |deltaRT(n+1)| = 0.784 (very unstable) 454 6. Previous work on BGP and Routing system stability 456 There have been numerous studies of BGP dynamics over the years. In 457 subsequent versions of this draft, they will be summarized in this 458 section and general findings will be drawn. 460 In this version of the document, we will just outline some of the 461 findings surrounding recent studies concerned with interactions of 462 BGP with Route Flap Damping (RFD) in order to show some of the 463 complexity in understanding BGP dynamics. 465 Work began in the early 1990s on an enhancement to the BGP called 466 "Route Flap Damping" [RFC2439]. The purpose of RFD was to prevent or 467 limit sustained route oscillations that could potentially put an 468 undue processing load on BGP. At that time there was a belief that 469 the predominate cause of route oscillation was due to BGP routing 470 sessions going up and down because they were being carried on 471 circuits that were themselves persistently going up and down (see 472 [Huston07b] for a fuller discussion). This would result in a constant 473 stream of route updates and withdrawals from the affected BGP 474 sessions that could propagate through the entire network due to the 475 network's flat addressing architecture. The first draft of the RFD 476 algorithm specification appeared in October 1993, updates and 477 revisions lead to the publication of RFC 2439, BGP Route Flap 478 Damping, in November 1998 [RFC2439]. 480 Over the next several years, RIPE published three recommendations, 481 [RIPE178], [RIPE210] and [RIPE229] in an attempt to establish 482 guidelines for operators when setting RFD's user configurable 483 parameters. The ultimate goal was to make the deployment of RFD 484 consistent throughout the network because different vendors provided 485 different default values for RFD's various parameters, and this could 486 result in different damping behaviors across the network. The last of 487 these recommendations, [RIPE229], was published in October 2001. 489 In August 2002, Mao et al. [Mao02] published a paper that discussed 490 how the use of RFD, as specified in RFC 2439. They showed that RFD 491 can significantly slowdown the convergence times of relatively stable 492 routing entries. This abnormal behavior arises during route 493 withdrawal from the interaction of RFD with "BGP path exploration" 494 (in which in response to path failures or routing policy changes, 495 some BGP routers may try a sequence of transient alternate paths 496 before selecting a new path or declaring destination unreachability). 497 The NANOG 2002 presentation of Bush et al. [Bush02] succinctly 498 summarized the findings of Mao et al. [Mao02] and presented some 499 observational data to illustrate the phenomena. The overall 500 conclusion of this work was that it was best not to use RFD so that 501 the overall ability of the network to re-converge after an episode of 502 "BGP path exploration" was not needlessly slowed. In May 2006, RIPE 503 published a final set of RFD recommendations [RIPE378] that directed 504 operators to not use RFD due primarily to the findings presented in 505 [Mao02]. 507 Recently, solutions such as EPIC [Chandrashekar05], or improving BGP 508 convergence through Root Cause Notification (BGP-RCN) [Pei05] have 509 been proposed to solve the "BGP path exploration" problem; however, 510 there are several details that still require consideration. 512 BGP stability has also been reported in [RFC4984], outcome of the 513 Routing and Addressing Workshop held by the Internet Architecture 514 Board (IAB). 516 7. Security Considerations 518 TBD. 520 8. IANA Considerations 522 This document makes no requests to IANA for action. 524 9. References 526 9.1 Normative References 528 [RFC2902] S.Deering, et al., "Overview of the 1998 IAB Routing 529 Workshop", RFC 2902, August 2000. 531 [RFC2439] Villamizar, C., Chandra, R., and Govindan, R., "BGP Route 532 Flap Damping", RFC 2439, November 1998. 534 [RFC4271] Y.Rekhter, T. Li, and S.Hares, Ed., "A Border Gateway 535 Protocol 4 (BGP-4)", RFC 4271, January 2006. 537 [RFC4984] D.Meyer, Ed., L.Zhang, Ed., K.Fall, Ed., "Report from 538 the IAB Workshop on Routing and Addressing", RFC 4984, 539 September 2007. 541 9.2 Informative References 543 [Bush02] Bush, R., Griffin, T., and Mao, Z.M., "Route flap damping 544 harmful?", NANOG-26, 28 October 2002. 545 http://www.nanog.org/mtg-0210/ppt/flap.pdf 547 [Chandrashekar05] J.Chandrashekar, Z.Duan, Z.-L.Zhang, and J.Krasky, 548 Limiting path exploration in BGP, In Proc. IEEE INFOCOM 549 2005, Miami, Florida, March 2005. 551 [Huston07a] G.Huston, http://bgp.potaroo.net, 2007. 553 [Huston07b] G.Huston, "Damping BGP", June 2007, 554 http://www.potaroo.net/ispcol/2007-06/dampbgp.html 556 [Labovitz00] C.Labovitz, A.Ahuja, A.Bose, and F.Jahanian, "Delayed 557 Internet Routing Convergence," in Proceedings of ACM 558 SIGCOMM'00. 560 [Li07] T.Li, G.Huston, "BGP Stability Improvements", Internet 561 draft, work in progress, draft-li-bgp-stability-01, June 562 2007. 564 [Mao02] Z.Mao, R.Govindan, G.Varghese, and R.Katz, "Route Flap 565 Damping Exacerbates Internet Routing Convergence", ACM 566 SIGCOMM'02, August 2002. 568 [Pei05] D.Pei, M.Azuma, D.Massey, and L.Zhang, "BGP-RCN: 569 improving BGP convergence through root cause 570 notification", Computer Networks, ISDN Syst. vol. 48, no. 571 2, pp 175-194, June 2005. 573 [RIPE178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and 574 Schmitz, J., "RIPE Routing-WG Recommendations for 575 coordinated route-flap damping parameters", RIPE-178, 2 576 February 1998. 577 http://www.ripn.net:8080/nic/ripe-docs/ripe-178.txt 579 [RIPE210] Barber, T., Doran S., Karrenberg, Pangil, C., and 580 Schmitz, J., "RIPE Routing-WG Recommendation for 581 coordinated route-flap damping parameters", RIPE-210, 12 582 May 2000. http://www.ripn.net/nic/ripe-docs/ripe-210.txt 584 [RIPE229] Panigl, C., Schmitz, J., Smith, P., and Vistoli, C., 585 "RIPE Routing-WG Recommendations for Coordinated Route- 586 flap Damping Parameters", RIPE-229, 22 October 2001. 587 ftp://ftp.ripe.net/ripe/docs/ripe-229.txt 589 [RIPE378] Smith, P., and Panigl, C., "RIPE Routing Working Group 590 Recommendations on Route-flap Damping", RIPE-378, 11 May 591 2006. http://www.ripe.net/ripe/docs/ripe-378.html 593 10. Authors' Addresses 595 Dimitri Papadimitriou 596 Alcatel-Lucent 597 Copernicuslaan 50 598 B-2018 Antwerpen, Belgium 599 Phone: +32 3 2408491 600 Email: dimitri.papadimitriou@alcatel-lucent.be 602 James Lowe 603 Alcatel-Lucent 604 600 March Road 605 Ottawa, Ontario 606 Canada, K2K 2E6 607 Phone: 1-613-784-1495 608 Email: jim.lowe@alcatel-lucent.com 610 Full Copyright Statement 612 Copyright (C) The IETF Trust (2008). 614 This document is subject to the rights, licenses and restrictions 615 contained in BCP 78, and except as set forth therein, the authors 616 retain all their rights. 618 This document and the information contained herein are provided on an 619 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 620 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 621 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 622 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 623 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Intellectual Property 628 The IETF takes no position regarding the validity or scope of any 629 Intellectual Property Rights or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; nor does it represent that it has 633 made any independent effort to identify any such rights. Information 634 on the procedures with respect to rights in RFC documents can be 635 found in BCP 78 and BCP 79. 637 Copies of IPR disclosures made to the IETF Secretariat and any 638 assurances of licenses to be made available, or the result of an 639 attempt made to obtain a general license or permission for the use of 640 such proprietary rights by implementers or users of this 641 specification can be obtained from the IETF on-line IPR repository at 642 http://www.ietf.org/ipr. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 this standard. Please address the information to the IETF at 648 ietf-ipr@ietf.org. 650 Acknowledgement 652 Funding for the RFC Editor function is provided by the IETF 653 Administrative Support Activity (IASA).