idnits 2.17.1 draft-ietf-grow-rss-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2009) is 5504 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 46, but not defined == Missing Reference: 'Fuller07' is mentioned on line 83, but not defined == Unused Reference: 'Labovitz00' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'Li07' is defined on line 551, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 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: March 22, 2009 6 Expires: September 21, 2009 8 Routing System Stability 10 draft-ietf-grow-rss-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and 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 Abstract 35 Understanding the dynamics of the Internet routing system is 36 fundamental to ensure its robustness/stability and to improve the 37 mechanisms of the BGP routing protocol. This documents outlines a 38 program of activity for identifying, documenting and analyzing the 39 dynamic properties of the Internet and its routing system. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [RFC2119]. 47 Document History 49 This is the initial version of this document. 51 1. Introduction 53 Understanding the dynamics of the Internet routing system is 54 fundamental to ensuring its stability and improving the mechanisms of 55 the BGP routing protocol [RFC4271]. Investigations on the Internet 56 routing system dynamics involve investigations on routing engine 57 resource consumption, in particular, memory and CPU. 59 System resource consumption depends on two items. First, there is the 60 size of the routing space. The greater the number of routing entries 61 there are, the greater the memory requirement on a routing device, 62 and the greater the need for increased processing and searching 63 capabilities to perform lookup operations. Second, the greater the 64 number of adjacency and peering relationships between routing 65 devices, the greater the dynamics associated with the routing 66 information updates exchanged between all these adjacencies and 67 peerings. This activity also increases the memory requirements for 68 the operation of the routing protocol. 70 In other words, as the routing system grows [Huston07a], so do the 71 requirements for routing engine memory and processing capacity. From 72 a routing dynamics viewpoint, minimizing the amount of BGP routing 73 information exchanged by routers is key to grappling with increasing 74 requirements on memory and CPU. 76 So, although current routing engines could potentially support up to 77 O(1M) routing table entries instabilities resulting i) from routing 78 protocol behavior, ii) routing protocol information exchanges, and 79 iii) changes in network topology may adversely affect the network's 80 ability to remain in a useable state for extended periods of time. 81 Note however that in terms of number of active routing entries, such 82 routing engine could at worst have to deal with O(1M) routes 83 within the next 5 years, see [Fuller07]. 85 2. Objectives 87 The overall goal is to identify, root cause and document - in a 88 structured manner - occurrences of Internet routing stability 89 phenomena using data from operational networks. 91 To help accomplish this goal, the following tasks will be undertaken. 93 1. Development of a methodology to process and interpret routing 94 table data. One guiding principle will be to be able to reproduce 95 phenomena previously observed at different locations. This work 96 will include documenting what information to collect and how it 97 should be archived. 99 2. Identification of a set of stability criteria and development of 100 methods for using them to provide a better understanding of the 101 routing system's stability. Other working groups may find this 102 beneficial in addition to the GROW working group. 104 3. Begin investigation into how routing protocol behavior and network 105 dynamics mutually influence each other. The nature of the 106 observations collected in the first task will suggest directions 107 to proceed with this work. 109 This proposed approach would allow rigor and consistency to be 110 brought to the study of network and routing stability. For example, 111 it would allow for a unified approach to the cross-validation of 112 techniques for looking at improving path exploration effects on the 113 routing system. 115 3. Relevance to the GROW working group charter 117 This effort fits into the GROW working group's charter to deal with 118 BGP operational issues related to routing table growth rates and the 119 dynamic properties of the routing system. 121 GROW has an advisory role to the IDR working group to provide 122 commentary on whether BGP is addressing relevant operational needs 123 and, where appropriate, suggest course corrections, which puts this 124 effort in a central place in the BGP investigation process. 126 Also, since the GROW working group community is directly linked to 127 the broader BGP operational community, this effort goes together with 128 obtaining routing table data from the field. 130 4. Routing system stability 132 In order to begin the discussion defined in work item detailed in 133 Section 2, point 2, this section proposes a number of definitions for 134 common routing and network stability terms. 136 The stability of a routing system is characterized by its response 137 (in terms of processing routing information) to inputs of finite 138 amplitude. 140 These inputs may be classified as either internal system events, such 141 as routing protocol configuration changes, or as external system 142 events, such as routing information updates. Such events are 143 sometimes loosely referred to as routing "instabilities"; however, 144 this term should be reserved for discussion about how the routing 145 system responds to such events. 147 A routing system, which returns to its initial equilibrium state, 148 when disturbed by an external and/or internal event, is considered to 149 be stable. 151 A routing system, which transitions to a new equilibrium state, when 152 disturbed by an external and/or internal event, is considered to be 153 marginally stable. 155 Such state transitions, whether stable or marginal, should occur 156 before the arrival of new input events. 158 The magnitude of the output of a stable routing system is small 159 whenever the input is small. That is, a single routing information 160 update shall not result in output amplification. Equivalently, a 161 stable system's output will always decrease to zero whenever the 162 input events stop. 164 A routing system, which remains in an unending condition of 165 transition from one state to another when disturbed by an external or 166 internal event, is considered to be unstable. 168 The degree to which a routing system, or components thereof, can 169 function correctly in the presence of input events is a measure of 170 the robustness of the system. 172 A precise definition of stability requires the specification of the 173 following elements: 175 o) The system being examined: for example, a system might be 176 comprised of: the routing system and associated events, such as 177 input events, outputs, and related arrival rates. 179 o) A convergence metric: a metric to define the convergence 180 characteristics of the system. 182 o) A stability metric: a metric that describes the degree of 183 stability of the system and indicates how close the system is to 184 being unstable. 186 The convergence and stability metrics may be affected by the 187 following parameters: 189 o) The number of routing entries (where, each entry R toward an 190 existing prefix D has an associated attribute set A consisting of 191 AS-Path, MED, and Local Preference, etc.); 193 o) The number of CPU cycles, C, required to process a routing entry, 194 and its associated memory space, M; 196 o) The input events and their arrival rates; 198 o) The output events associated with the processing of each input 199 event. 201 5. Mathematical formulation 203 Section 4 outlined some proposals for definitions of commonly used 204 stability terms applied to network and routing systems. In this 205 section, an initial attempt is made to build a mathematical 206 formulation around those concepts in order to begin the development 207 of more practical metrics. 209 5.1 General Formulation 211 Let RT be the "Routing Table" and RT(n) represent the routing table 212 at some time n. At time n+1, the routing table can be expressed as 213 the sum of two components: 215 RT(n+1) = RTo(n) + deltaRT(n+1) (1) 217 In this equation, RTo(n) is the set of routes that experience no 218 change between n and n+1, and deltaRT(n+1) accounts for all route 219 changes (additions, deletions, and changes to previously existing 220 routes) between n and n+1. deltaRT(n+1) itself can expressed as the 221 sum of two components: 223 deltaRT(n+1) = RTc(n+1) + RTn(n+1) (2) 225 In this equation, RTc(n+1) is a set of routes at time n that 226 experience some sort of change at time n+1. Rtn(n+1) is a set of new 227 routes observed at time n+1 that were not present at time n. 229 RTc and RTn are each composed of two parts: one due to changes in 230 network state (new routes appearing, changes to existing routes, 231 etc.), and a second attributable to routing protocol changes (BGP 232 session failure, BGP route attribute changes, changes to filtering 233 policies, etc.). Equation (1) can be expanded to account for these 234 separate effects. First, substitute equation (2) into equation (1): 236 RT(n+1) = RTo(n) + RTc(n+1) + RTn(n+1) (3) 237 As was mentioned, the terms RTc(n+1) and RTn(n+1) can be further 238 expanded into their two constitute components: 240 RTc(n+1) = RTcN(n+1) + RTcR(n+1) (4) 242 RTn(n+1) = RTnN(n+1) + RTnR(n+1) (5) 244 In these two equations, "N" denotes the component due to network 245 topology changes, and "R" denotes the component due to routing 246 protocol changes. 248 These equations can be used as the basis for deriving the convergence 249 and stability metrics discussed in Section 4. However, there are a 250 number of issues that will need to be resolved in order to make 251 progress: 253 a) Some thought will need to be done on how to distinguish between 254 network and routing protocol effects; 256 b) Some thought needs to be given to "timescales of applicability" 257 in order to make assessments about what constitutes instability 258 in a routing system from a practical point-of-view; 260 c) Some thought needs to given to how a protocol can absorb network 261 instabilities. [RFC2902] touches on this issue and indicated that 262 damping the effects of route updates enhances stability, but 263 possibly at the cost of reachability for some prefixes. 265 5.2 Derivation of stability metrics 267 In this section we propose an algorithm for calculating a stability 268 metric for a route and a routing table. 270 First, we should make an attempt to quantify what we mean by stable, 271 marginally stable, and unstable in the context of the routing table 272 RT(n+1). Please note that this work is preliminary and is still in 273 the process of being refined and tested. 275 We can start with the basic equation we previously developed: 277 RT(n+1) = RTo(n) + deltaRT(n+1) 279 Let |deltaRT(n+1)| be the magnitude of the change to the routing 280 table at some time n+1. 282 For a routing table, RT(n+1), to be stable, the following condition 283 must be met: 285 |deltaRT(n+1)| =< alpha as t -> infinity, 286 where alpha is a small, positive number. 288 For marginally stable systems, the following condition must be met: 290 alpha < |deltaRT(n+1)| =< beta as t -> infinity, 292 where beta is a small, positive number, greater than alpha. 294 For unstable systems, the following condition is met: 296 |deltaRT(n+1)| > beta as t -> infinity. 298 One can see that we have not made distinctions for new routes or 299 changed routes, or for the source of disturbances to the system. 300 This is a definition of stability at the highest, or coarsest, 301 level. 303 As well, alpha and beta will need to be set based on some sort of 304 operational criteria. Among other things, alpha and beta will be 305 dependent on the observation sampling frequency. 307 In order to be able to compute |deltaRT(n+1)| we need to be able 308 to calculate a stability metric for an individual route. 310 A route, rti(n+1), which is a component of RT(n+1), consists of: 312 rti(n+1) = {destination, path, attributes}. 314 A stability metric for rti might be most easily defined by an 315 algorithm and in the next several paragraphs we will undertake 316 such a development. 318 Let the stability metric associated with a route rti be called fi. 319 When a route is created, the initial value of fi is 0. 321 If rti never experiences any change, then fi remains constant at 0. 323 If rti does experience a change (path or attribute or withdrawal), 324 then fi changes according to the following: 326 if rti(n+1) != rti(n) then 328 /* the route has changed */ 330 fi(n+1) = fi(n) + 1 332 else 334 /* the route did not change */ 336 if fi(n) = 0 then 338 /* fi never drops to less than 0 */ 339 fi(n+1) = 0 341 else 343 /* fi is decremented if there is no change in rti */ 345 fi(n+1) = f(n) - 1 347 end if 349 end if 351 So, how does this work in the case where rti is withdrawn at some 352 time n+1? Conceivably, fi(n+1) is 1 at a minimum when withdrawal 353 occurs, and some non-zero value fi(n)+1, say gamma, at most 354 according to the algorithm. As t increases, fi is kept around 355 until it equals zero, at which time the route, rti, is discarded. 357 With this definition of a stability metric for an individual 358 route, one can take a stab at calculating a stability metric for 359 an entire routing table. 361 |deltarti(n+1)| is introduced as the change in stability metric 362 associated with a single route, rti, from t=n to t=n+1. It is used 363 to calculate |deltaRT(n+1)|, the stability metric of the entire 364 routing table, RT, at time t=n+1. 366 |deltaRT(n+1)| is normalized so that 0 is the minimum value and 1 367 is the maximum, where 0 implies perfect stability, and 1 indicates 368 complete instability. 370 Here is the candidate algorithm to evaluate |deltaRT(n+1)|: 372 for i = 1 to number of routes in RT(n+1) 374 if rti(n+1) is a new route then 376 |deltarti(n+1)| = 0 378 else 380 /* rti(n+1) is an existing route */ 382 if fi(n) = 0 and fi(n+1) = 0 then 384 /* no change occurred to the route */ 386 |deltarti(n+1)| = 0 388 else 390 /* a change occurred to the route */ 392 if fi(n+1) > fi(n) then 393 |deltarti(n+1)| = [fi(n) + 1] / [fi(n+1) + 1] 395 else 397 |deltarti(n+1)| = fi(n+1) / fi(n) 399 end if 401 end if 403 end if 405 end i loop 407 |deltaRT(n+1)| = Sum(deltarti(n+1)) / total number of routes in 408 RT(n+1) 410 The following notable properties can be observed: 411 - fi(n+1) and fi(n) can only be equal if they are both equal to 0 412 otherwise, fi(n+1) and fi(n) only differ by 1, and there is no 413 theoretical upper limit on either fi(n+1) or fi(n). 414 - 0 =< |deltarti(n+1)| =< 1 416 We conclude this section by showing some example calculations for 417 |deltaRT(n+1)| in a number of simple, but indicative situations. 419 Example 1: 421 fi(n) = {0, 1, 2, 1, 0, 0} and fi(n+1) = {1, 2, 1, 0, 0, 0} 422 |deltaRT(n+1)| = (1/2 + 2/3 + 1/2 + 0/1 + 0 + 0) / 6 423 |deltaRT(n+1)| = 0.278 (rather stable) 425 Example 2: 427 fi(n) = {0, 0, 0, 0, 0, 0} and fi(n+1) = {1, 1, 1, 1, 1, 1} 428 |deltaRT(n+1)| = (1/2 + 1/2 + 1/2 + 1/2 + 1/2 + 1/2) / 6 429 |deltaRT(n+1)| = 0.5 (possibly heading to instability, but too early 430 to judge) 432 Example 3: 434 fi(n) = {0, 1, 0, 1, 0, 1} and fi(n+1) = {1, 0, 1, 0, 1, 0} 435 |deltaRT(n+1)| = (1/2 + 0/1 + 1/2 + 0/1 + 1/2 + 0/1) / 6 436 |deltaRT(n+1)| = 0.25 (possibly heading to instability, but too early 437 to judge) 439 Example 4: 441 fi(n) = {56, 20, 63, 64, 0, 5} and fi(n+1) = {57, 19, 64, 65, 0, 4} 442 |deltaRT(n+1)| = (57/58 + 19/20 + 64/65 + 65/66 + 0 + 4/5) / 6 443 |deltaRT(n+1)| = 0.784 (very unstable) 445 6. Previous work on BGP and Routing system stability 447 There have been numerous studies of BGP dynamics over the years. In 448 subsequent versions of this draft, they will be summarized in this 449 section and general findings will be drawn. 451 In this version of the document, we will just outline some of the 452 findings surrounding recent studies concerned with interactions of 453 BGP with Route Flap Damping (RFD) in order to show some of the 454 complexity in understanding BGP dynamics. 456 Work began in the early 1990s on an enhancement to the BGP called 457 "Route Flap Damping" [RFC2439]. The purpose of RFD was to prevent or 458 limit sustained route oscillations that could potentially put an 459 undue processing load on BGP. At that time there was a belief that 460 the predominate cause of route oscillation was due to BGP routing 461 sessions going up and down because they were being carried on 462 circuits that were themselves persistently going up and down (see 463 [Huston07b] for a fuller discussion). This would result in a constant 464 stream of route updates and withdrawals from the affected BGP 465 sessions that could propagate through the entire network due to the 466 network's flat addressing architecture. The first draft of the RFD 467 algorithm specification appeared in October 1993, updates and 468 revisions lead to the publication of RFC 2439, BGP Route Flap 469 Damping, in November 1998 [RFC2439]. 471 Over the next several years, RIPE published three recommendations, 472 [RIPE178], [RIPE210] and [RIPE229] in an attempt to establish 473 guidelines for operators when setting RFD's user configurable 474 parameters. The ultimate goal was to make the deployment of RFD 475 consistent throughout the network because different vendors provided 476 different default values for RFD's various parameters, and this could 477 result in different damping behaviors across the network. The last of 478 these recommendations, [RIPE229], was published in October 2001. 480 In August 2002, Mao et al. [Mao02] published a paper that discussed 481 how the use of RFD, as specified in RFC 2439. They showed that RFD 482 can significantly slowdown the convergence times of relatively stable 483 routing entries. This abnormal behavior arises during route 484 withdrawal from the interaction of RFD with "BGP path exploration" 485 (in which in response to path failures or routing policy changes, 486 some BGP routers may try a sequence of transient alternate paths 487 before selecting a new path or declaring destination unreachability). 488 The NANOG 2002 presentation of Bush et al. [Bush02] succinctly 489 summarized the findings of Mao et al. [Mao02] and presented some 490 observational data to illustrate the phenomena. The overall 491 conclusion of this work was that it was best not to use RFD so that 492 the overall ability of the network to re-converge after an episode of 493 "BGP path exploration" was not needlessly slowed. In May 2006, RIPE 494 published a final set of RFD recommendations [RIPE378] that directed 495 operators to not use RFD due primarily to the findings presented in 496 [Mao02]. 498 Recently, solutions such as EPIC [Chandrashekar05], or improving BGP 499 convergence through Root Cause Notification (BGP-RCN) [Pei05] have 500 been proposed to solve the "BGP path exploration" problem; however, 501 there are several details that still require consideration. 503 BGP stability has also been reported in [RFC4984], outcome of the 504 Routing and Addressing Workshop held by the Internet Architecture 505 Board (IAB). 507 7. Security Considerations 509 TBD. 511 8. IANA Considerations 513 This document makes no requests to IANA for action. 515 9. References 517 9.1 Normative References 519 [RFC2902] S.Deering, et al., "Overview of the 1998 IAB Routing 520 Workshop", RFC 2902, August 2000. 522 [RFC2439] Villamizar, C., Chandra, R., and Govindan, R., "BGP Route 523 Flap Damping", RFC 2439, November 1998. 525 [RFC4271] Y.Rekhter, T. Li, and S.Hares, Ed., "A Border Gateway 526 Protocol 4 (BGP-4)", RFC 4271, January 2006. 528 [RFC4984] D.Meyer, Ed., L.Zhang, Ed., K.Fall, Ed., "Report from 529 the IAB Workshop on Routing and Addressing", RFC 4984, 530 September 2007. 532 9.2 Informative References 534 [Bush02] Bush, R., Griffin, T., and Mao, Z.M., "Route flap damping 535 harmful?", NANOG-26, 28 October 2002. 536 http://www.nanog.org/mtg-0210/ppt/flap.pdf 538 [Chandrashekar05] J.Chandrashekar, Z.Duan, Z.-L.Zhang, and J.Krasky, 539 Limiting path exploration in BGP, In Proc. IEEE INFOCOM 540 2005, Miami, Florida, March 2005. 542 [Huston07a] G.Huston, http://bgp.potaroo.net, 2007. 544 [Huston07b] G.Huston, "Damping BGP", June 2007, 545 http://www.potaroo.net/ispcol/2007-06/dampbgp.html 547 [Labovitz00] C.Labovitz, A.Ahuja, A.Bose, and F.Jahanian, "Delayed 548 Internet Routing Convergence," in Proceedings of ACM 549 SIGCOMM'00. 551 [Li07] T.Li, G.Huston, "BGP Stability Improvements", Internet 552 draft, work in progress, draft-li-bgp-stability-01, June 553 2007. 555 [Mao02] Z.Mao, R.Govindan, G.Varghese, and R.Katz, "Route Flap 556 Damping Exacerbates Internet Routing Convergence", ACM 557 SIGCOMM'02, August 2002. 559 [Pei05] D.Pei, M.Azuma, D.Massey, and L.Zhang, "BGP-RCN: 560 improving BGP convergence through root cause 561 notification", Computer Networks, ISDN Syst. vol. 48, no. 562 2, pp 175-194, June 2005. 564 [RIPE178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and 565 Schmitz, J., "RIPE Routing-WG Recommendations for 566 coordinated route-flap damping parameters", RIPE-178, 2 567 February 1998. 568 http://www.ripn.net:8080/nic/ripe-docs/ripe-178.txt 570 [RIPE210] Barber, T., Doran S., Karrenberg, Pangil, C., and 571 Schmitz, J., "RIPE Routing-WG Recommendation for 572 coordinated route-flap damping parameters", RIPE-210, 12 573 May 2000. http://www.ripn.net/nic/ripe-docs/ripe-210.txt 575 [RIPE229] Panigl, C., Schmitz, J., Smith, P., and Vistoli, C., 576 "RIPE Routing-WG Recommendations for Coordinated Route- 577 flap Damping Parameters", RIPE-229, 22 October 2001. 578 ftp://ftp.ripe.net/ripe/docs/ripe-229.txt 580 [RIPE378] Smith, P., and Panigl, C., "RIPE Routing Working Group 581 Recommendations on Route-flap Damping", RIPE-378, 11 May 582 2006. http://www.ripe.net/ripe/docs/ripe-378.html 584 10. Authors' Addresses 586 Dimitri Papadimitriou 587 Alcatel-Lucent 588 Copernicuslaan 50 589 B-2018 Antwerpen, Belgium 590 Phone: +32 3 2408491 591 Email: dimitri.papadimitriou@alcatel-lucent.be 593 James Lowe 594 Alcatel-Lucent 595 600 March Road 596 Ottawa, Ontario 597 Canada, K2K 2E6 598 Phone: 1-613-784-1495 599 Email: jim.lowe@alcatel-lucent.com 601 Disclaimer of Validity 603 All IETF Documents and the information contained therein are provided 604 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 605 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 606 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 607 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 608 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 609 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 610 FOR A PARTICULAR PURPOSE. 612 Full Copyright Statement 614 Copyright (c) 2009 IETF Trust and the persons identified as the 615 document authors. All rights reserved. 617 This document is subject to BCP 78 and the IETF Trust's Legal 618 Provisions Relating to IETF Documents in effect on the date of 619 publication of this document (http://trustee.ietf.org/license-info). 620 Please review these documents carefully, as they describe your 621 rights and restrictions with respect to this document. 623 This document may contain material from IETF Documents or IETF 624 Contributions published or made publicly available before November 625 10, 2008. The person(s) controlling the copyright in some of this 626 material may not have granted the IETF Trust the right to allow 627 modifications of such material outside the IETF Standards Process. 628 Without obtaining an adequate license from the person(s) 629 controlling the copyright in such materials, this document may not 630 be modified outside the IETF Standards Process, and derivative 631 works of it may not be created outside the IETF Standards Process, 632 except to format it for publication as an RFC or to translate it 633 into languages other than English. 635 Acknowledgement 637 Funding for the RFC Editor function is provided by the IETF 638 Administrative Support Activity (IASA).