idnits 2.17.1 draft-irtf-rrg-design-goals-01.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 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 349. 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 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 8, 2007) is 6127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force T. Li, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational July 8, 2007 5 Expires: January 9, 2008 7 Design Goals for Scalable Internet Routing 8 draft-irtf-rrg-design-goals-01 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 January 9, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 It is commonly recognized that the Internet routing and addressing 42 architecture is facing challenges in scalability, mobility, multi- 43 homing, and inter-domain traffic engineering. The RRG is designing 44 an alternate architecture to meet these challenges. This document 45 consists of a prioritized list of design goals for the architecture. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 51 1.2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. General Design Goals Collected from Past . . . . . . . . . . . 3 53 3. Design Goals for A New Routing Architecture . . . . . . . . . . 4 54 3.1. Improved routing scalability . . . . . . . . . . . . . . . 4 55 3.2. Scalable support for traffic engineering . . . . . . . . . 4 56 3.3. Scalable support for multi-homing . . . . . . . . . . . . . 4 57 3.4. Scalable support for mobility . . . . . . . . . . . . . . . 4 58 3.5. Simplified renumbering . . . . . . . . . . . . . . . . . . 5 59 3.6. Decoupling location and identification . . . . . . . . . . 5 60 3.7. First-class elements . . . . . . . . . . . . . . . . . . . 6 61 3.8. Routing quality . . . . . . . . . . . . . . . . . . . . . . 6 62 3.9. Routing security . . . . . . . . . . . . . . . . . . . . . 6 63 3.10. Deployability . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 It is commonly recognized that the Internet routing and addressing 75 architecture is facing challenges in scalability, mobility, multi- 76 homing, and inter-domain traffic engineering. The Routing Research 77 Group aims to design an alternate architecture to meet these 78 challenges. This document presents a prioritized list of design 79 goals for the architecture. 81 These goals should be taken as guidelines for evaluating possible 82 architectural solutions. The expectation is that these goals will be 83 applied with good judgment. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 1.2. Priorities 93 Each design goal in this document has been assigned a priority, which 94 is one of 'required', 'strongly desired', 'desired', and 'optional'. 96 Required: The solution is REQUIRED to support this goal. 98 Strongly desired: The solution SHOULD support this goal unless there 99 exist compelling reasons showing it is unachievable, 100 extremely inefficient, or impractical. 102 Desired: The solution SHOULD support this goal. 104 Optional: The solution MAY support this goal. 106 It is possible that two design goals at the same priority level may 107 be found to be in conflict with one another. If and when this 108 happens, one of them may be subsequently re-prioritized to have the 109 two in different priority levels. 111 2. General Design Goals Collected from Past 113 RFC 1958 [RFC1958] provides an excellent list of the original 114 architectural principles of the Internet. We incorporate them here 115 by reference, as part of our desired design goals. 117 3. Design Goals for A New Routing Architecture 119 3.1. Improved routing scalability 121 Long experience with inter-domain routing has shown us that the 122 global BGP routing table is continuing to grow rapidly [BGPGrowth]. 123 Carrying this large amount of state in the control plane is expensive 124 and places undue cost burdens on network participants that do not 125 necessarily get value from the increases in the routing table size. 126 Thus, the first required goal is to provide significant improvement 127 to the scalability of the control plane. It is strongly desired to 128 make the control plane scale independently from the growth of the 129 Internet user population. 131 3.2. Scalable support for traffic engineering 133 Traffic engineering is the capability of directing traffic along 134 paths other than those that would be computed by normal IGP/EGP 135 routing. Inter-domain traffic engineering today is frequently 136 accomplished by injecting more-specific prefixes into the global 137 routing table, which results in a negative impact on routing 138 scalability. A scalable solution for inter-domain traffic 139 engineering is strongly desired. 141 3.3. Scalable support for multi-homing 143 Multi-homing is the capability of an organization to be connected to 144 the Internet via more than one other organization. The current 145 mechanism for supporting multi-homing is to let the organization 146 advertise one or multiple prefixes into the global routing system, 147 again resulting in a negative impact on routing scalability. More 148 scalable solutions for multi-homing are strongly desired. 150 3.4. Scalable support for mobility 152 Mobility is the capability of a host, network, or organization to 153 change its topological connectivity with respect to the remainder of 154 the Internet, while continuing to receive packets from the Internet. 155 Existing mechanisms to provide mobility support include (1) 156 renumbering the mobile entity as it changes its topological 157 attachment point(s) to the Internet; (2) renumbering and creating a 158 tunnel from the entity's new topological location back to its 159 original location; and (3) letting the mobile entity announce its 160 prefixes from its new attachment point(s). The first approach alone 161 is considered unsatisfactory as the change of IP address may break 162 existing transport or higher level connections for those protocols 163 using IP addresses as identifiers. The second requires the 164 deployment of a 'home agent' to keep track of the mobile entity's 165 current location and adds overhead to the routers involved, as well 166 as adding stretch to the path of inbound packet. Neither of the 167 first two approaches impacts the routing scalability. The third 168 approach, however, injects dynamic updates into the global routing 169 system as the mobile entity moves. Mechanisms that help to provide 170 more efficient and scalable mobility support are desired, especially 171 when they can be coupled with security and support topological 172 changes at a high-rate. 174 3.5. Simplified renumbering 176 Today many of the end-sites receive their IP address assignments from 177 their Internet Service Providers (ISP). When such a site changes 178 providers, for routing to scale, the site must renumber into a new 179 address block assigned by its new ISP. This can be costly, error- 180 prone and painful. Automated tools, once developed, are expected to 181 provide significant help in reducing the renumbering pain. It is not 182 expected that renumbering will be wholly automated, as some manual 183 reconfiguration is likely to be necessary for changing the last-mile 184 link. However, the overall cost of this transition should be 185 drastically lowered. 187 In addition to being configured into hosts and routers, where 188 automated renumbering tools can help, IP addresses are also often 189 used for other purposes such as access control lists. They are also 190 sometimes hard-coded into applications used in environments where 191 failure of the DNS could be catastrophic (e.g. certain remote 192 monitoring applications). Although renumbering may be considered a 193 mild inconvenience for some sites, and guidelines have been developed 194 for renumbering a network without a flag day [RFC4192], for others, 195 the necessary changes are sufficiently difficult so as to make 196 renumbering effectively impossible. It is strongly desired that a 197 new architecture allow end-sites to change providers with 198 significantly less disruption. 200 3.6. Decoupling location and identification 202 Numerous sources have noted that an IPv4 address embodies both host 203 attachment point information and identification information. This 204 overloading has caused numerous semantic collisions that have limited 205 the flexibility of the Internet architecture. Therefore, it is 206 desired that a solution separate the host location information 207 namespace from the identification namespace. 209 Caution must be taken here to clearly distinguish the decoupling of 210 host location and identification information, and the decoupling of 211 end-site addresses from globally routable prefixes; the latter has 212 been proposed as one of the approaches to a scalable routing 213 architecture. Solutions to both problems, i.e. (1) the decoupling of 214 host location and identification information and (2) a scalable 215 global routing system (whose solution may, or may not, depend on the 216 second decoupling) are required and it is required that their 217 solutions are compatible with each other. 219 3.7. First-class elements 221 If a solution makes use of a mechanism, it is strongly desired that 222 the mechanism be a first-class element in the architecture 223 [FirstClass]. More specifically, if a tunneling mechanism is used to 224 provide network layering, connectivity virtualization, or a 225 connection-oriented mode, then it is strongly desired that the 226 tunneling mechanism be a first-class element in the architecture. 228 3.8. Routing quality 230 The routing subsystem is responsible for computing a path from any 231 point on the Internet to any other point in the Internet. The 232 quality of the routes that are computed can be measured by a number 233 of metrics, such as convergence, stability, and stretch. 235 The stretch of a routing scheme is the ratio of the maximum length 236 of the routing path, on which a packet is delivered, to the length 237 of the shortest path from the source to the destination node, over 238 all source destination pairs. 240 [Editor's Note: A better definition of stretch, or a better 241 reference would be much appreciated. This definition is derived 242 from [PODC06].] 244 A solution is strongly desired to provide routing quality equivalent 245 to what is available today or better. 247 3.9. Routing security 249 Currently, the routing subsystem is secured through a number of 250 protocol specific mechanisms of varying strength and applicability. 251 Any new architecture is required to provide at least the same level 252 of security as is deployed as of when the new architecture is 253 deployed. 255 3.10. Deployability 257 Since solutions that are not deployable are simply academic 258 exercises, solutions are required to be deployable from a technical 259 perspective. Furthermore, given the extensive deployed base of 260 today's Internet, a solution is required to be incrementally 261 deployable. 263 4. IANA Considerations 265 This memo includes no requests to IANA. 267 5. Security Considerations 269 All solutions are required to provide security that is at least as 270 strong as the existing Internet routing and addressing architecture. 272 6. References 274 6.1. Normative References 276 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 277 RFC 1958, June 1996. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 283 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 284 September 2005. 286 6.2. Informative References 288 [BGPGrowth] 289 Huston, G., "BGP Routing Table Analysis Reports", 290 . 292 [FirstClass] 293 "First-class object", 294 . 296 [PODC06] Konjevod, G., Andrea, R., and D. Xia, "Optimal-Stretch 297 Name-Independent Compact Routing in Doubling Metrics", 298 . 300 Author's Address 302 Tony Li (editor) 303 Cisco Systems, Inc. 304 425 East Tasman Dr. 305 San Jose, CA 95134 306 USA 308 Phone: +1 408 853 1494 309 Email: tli@cisco.com 311 Full Copyright Statement 313 Copyright (C) The IETF Trust (2007). 315 This document is subject to the rights, licenses and restrictions 316 contained in BCP 78, and except as set forth therein, the authors 317 retain all their rights. 319 This document and the information contained herein are provided on an 320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 322 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 323 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 324 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 327 Intellectual Property 329 The IETF takes no position regarding the validity or scope of any 330 Intellectual Property Rights or other rights that might be claimed to 331 pertain to the implementation or use of the technology described in 332 this document or the extent to which any license under such rights 333 might or might not be available; nor does it represent that it has 334 made any independent effort to identify any such rights. Information 335 on the procedures with respect to rights in RFC documents can be 336 found in BCP 78 and BCP 79. 338 Copies of IPR disclosures made to the IETF Secretariat and any 339 assurances of licenses to be made available, or the result of an 340 attempt made to obtain a general license or permission for the use of 341 such proprietary rights by implementers or users of this 342 specification can be obtained from the IETF on-line IPR repository at 343 http://www.ietf.org/ipr. 345 The IETF invites any interested party to bring to its attention any 346 copyrights, patents or patent applications, or other proprietary 347 rights that may cover technology that may be required to implement 348 this standard. Please address the information to the IETF at 349 ietf-ipr@ietf.org. 351 Acknowledgment 353 Funding for the RFC Editor function is provided by the IETF 354 Administrative Support Activity (IASA).