idnits 2.17.00 (12 Aug 2021) /tmp/idnits3231/draft-irtf-rrg-design-goals-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (January 3, 2011) is 4149 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 January 3, 2011 5 Expires: July 7, 2011 7 Design Goals for Scalable Internet Routing 8 draft-irtf-rrg-design-goals-06 10 Abstract 12 It is commonly recognized that the Internet routing and addressing 13 architecture is facing challenges in scalability, mobility, multi- 14 homing, and inter-domain traffic engineering. The Routing Research 15 Group is investigating an alternate architecture to meet these 16 challenges. This document consists of a prioritized list of design 17 goals for the target architecture. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 7, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 55 1.2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. General Design Goals Collected from Past . . . . . . . . . . . 3 57 3. Design Goals for A New Routing Architecture . . . . . . . . . . 4 58 3.1. Improved routing scalability . . . . . . . . . . . . . . . 4 59 3.2. Scalable support for traffic engineering . . . . . . . . . 4 60 3.3. Scalable support for multi-homing . . . . . . . . . . . . . 4 61 3.4. Decoupling location and identification . . . . . . . . . . 4 62 3.5. Scalable support for mobility . . . . . . . . . . . . . . . 5 63 3.6. Simplified renumbering . . . . . . . . . . . . . . . . . . 5 64 3.7. Modularity, composability, and seamlessness . . . . . . . . 6 65 3.8. Routing quality . . . . . . . . . . . . . . . . . . . . . . 7 66 3.9. Routing security . . . . . . . . . . . . . . . . . . . . . 7 67 3.10. Deployability . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.11. Summary of priorities . . . . . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 It is commonly recognized that the Internet routing and addressing 79 architecture is facing challenges in inter-domain scalability, 80 mobility, multi-homing, and inter-domain traffic engineering. 81 [RFC4984] The Routing Research Group (RRG) aims to design an 82 alternate architecture to meet these challenges. This document 83 presents a prioritized list of design goals for the target 84 architecture. 86 These goals should be taken as guidelines for the design and 87 evaluation of possible architectural solutions. The expectation is 88 that these goals will be applied with good judgment. 90 The goals presented here were initially presented and discussed at 91 the start of the RRG work on a revised routing architecture, and were 92 revisited and finalized after the work on that architecture was 93 complete. As such, this represents both the goals that the RG 94 started with, plus revisions to those goals based on our increased 95 understanding of the space. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 1.2. Priorities 105 Each design goal in this document has been assigned a priority, which 106 is one of 'required', 'strongly desired', and 'desired'. 108 Required: The solution is REQUIRED to support this goal. 110 Strongly desired: The solution SHOULD support this goal unless there 111 exist compelling reasons showing it is unachievable, 112 extremely inefficient, or impractical. 114 Desired: The solution SHOULD support this goal. 116 2. General Design Goals Collected from Past 118 [RFC1958] provides a list of the original architectural principles of 119 the Internet. We incorporate them here by reference, as part of our 120 desired design goals. 122 3. Design Goals for A New Routing Architecture 124 3.1. Improved routing scalability 126 Long experience with inter-domain routing has shown that the global 127 BGP routing table is continuing to grow rapidly [BGPGrowth]. 128 Carrying this large amount of state in the inter-domain routing 129 protocols is expensive and places undue cost burdens on network 130 participants that do not necessarily get value from the increases in 131 the routing table size. Thus, the first required goal is to provide 132 significant improvement to the scalability of the inter-domain 133 routing subsystem. It is strongly desired to make the routing 134 subsystem scale independently from the growth of the Internet user 135 population. If there is a coupling between the size of the user base 136 and the scale of the routing subsystem, then it will be very 137 difficult to retain any semblance of scalability. If a solution 138 includes support for alternative routes to support faster 139 convergence, the alternative routes should also factor into routing 140 subsystem scalability. 142 3.2. Scalable support for traffic engineering 144 Traffic engineering is the capability of directing traffic along 145 paths other than those that would be computed by normal IGP/EGP 146 routing. Inter-domain traffic engineering today is frequently 147 accomplished by injecting more-specific prefixes into the global 148 routing table, which results in a negative impact on routing 149 scalability. The additional prefixes injected to enable traffic 150 engineering place added burden on the scalability of the routing 151 architecture. At the same time, the need for traffic engineering 152 capabilities is essential to network operations. Thus, a scalable 153 solution for inter-domain traffic engineering is strongly desired. 155 3.3. Scalable support for multi-homing 157 Multi-homing is the capability of an organization to be connected to 158 the Internet via more than one other organization. The current 159 mechanism for supporting multi-homing is to let the organization 160 advertise one or multiple prefixes into the global routing system, 161 again resulting in a negative impact on routing scalability. More 162 scalable solutions for multi-homing are strongly desired. 164 3.4. Decoupling location and identification 166 Numerous sources have noted that an IP address embodies both host 167 attachment point information and identification information. [IEN1] 168 This overloading has caused numerous semantic collisions that have 169 limited the flexibility of the Internet architecture. Therefore, it 170 is desired that a solution separate the host location information 171 namespace from the identification namespace. 173 Caution must be taken here to clearly distinguish the decoupling of 174 host location and identification information, and the decoupling of 175 end-site addresses from globally routable prefixes; the latter has 176 been proposed as one of the approaches to a scalable routing 177 architecture. Solutions to both problems, i.e. (1) the decoupling of 178 host location and identification information and (2) a scalable 179 global routing system (whose solution may, or may not, depend on the 180 second decoupling) are required and it is required that their 181 solutions are compatible with each other. 183 3.5. Scalable support for mobility 185 Mobility is the capability of a host, network, or organization to 186 change its topological connectivity with respect to the remainder of 187 the Internet, while continuing to receive packets from the Internet. 188 Existing mechanisms to provide mobility support include 190 1. renumbering the mobile entity as it changes its topological 191 attachment point(s) to the Internet; 193 2. renumbering and creating a tunnel from the entity's new 194 topological location back to its original location; and 196 3. letting the mobile entity announce its prefixes from its new 197 attachment point(s). 199 The first approach alone is considered unsatisfactory as the change 200 of IP address may break existing transport or higher level 201 connections for those protocols using IP addresses as identifiers. 202 The second requires the deployment of a 'home agent' to keep track of 203 the mobile entity's current location and adds overhead to the routers 204 involved, as well as adding stretch to the path of inbound packet. 205 Neither of the first two approaches impacts the routing scalability. 206 The third approach, however, injects dynamic updates into the global 207 routing system as the mobile entity moves. Mechanisms that help to 208 provide more efficient and scalable mobility support are desired, 209 especially when they can be coupled with security, especially 210 privacy, and support topological changes at a high rate. Ideally, 211 such mechanisms should completely decouple mobility from routing. 213 3.6. Simplified renumbering 215 Today many of the end-sites receive their IP address assignments from 216 their Internet Service Providers (ISP). When such a site changes 217 providers, for routing to scale, the site must renumber into a new 218 address block assigned by its new ISP. This can be costly, error- 219 prone and painful [RFC5887]. Automated tools, once developed, are 220 expected to provide significant help in reducing the renumbering 221 pain. It is not expected that renumbering will be wholly automated, 222 as some manual reconfiguration is likely to be necessary for changing 223 the last-mile link. However, the overall cost of renumbering should 224 be drastically lowered. 226 In addition to being configured into hosts and routers, where 227 automated renumbering tools can help, IP addresses are also often 228 used for other purposes such as access control lists. They are also 229 sometimes hard-coded into applications used in environments where 230 failure of the DNS could be catastrophic (e.g. certain remote 231 monitoring applications). Although renumbering may be considered a 232 mild inconvenience for some sites, and guidelines have been developed 233 for renumbering a network without a flag day [RFC4192], for others, 234 the necessary changes are sufficiently difficult so as to make 235 renumbering effectively impossible. It is strongly desired that a 236 new architecture allow end-sites to renumber their network with 237 significantly less disruption, or, if renumbering can be eliminated, 238 the new architecture must demonstrate how the topology can be 239 economically morphed to fit the addressing. 241 3.7. Modularity, composability, and seamlessness 243 A new routing architecture should be modular: it should subdivide 244 into multiple composable, extensible, and orthogonal subsystems. The 245 interfaces between modules should be natural and seamless, without 246 special cases or restrictions. Similarly, the primitives and 247 abstractions in the architecture should be suitably general, with 248 operations equally applicable to abstractions and concrete entities, 249 and without deleterious side-effects that might hinder communication 250 between endpoints in the Internet. These properties are strongly 251 desired in a solution. 253 As an example, if tunneling were used as a part of a solution, 254 tunneling should be completely transparent to both of the endpoints, 255 without requiring new mechanisms for determining the correct maximum 256 datagram size. 258 The resulting network should always fully approximate the current 259 best-effort Internet connectivity model, and it should also 260 anticipate changes to that model e.g. for multiple differentiated 261 and/or guaranteed upon levels of service in the future. 263 3.8. Routing quality 265 The routing subsystem is responsible for computing a path from any 266 point on the Internet to any other point in the Internet. The 267 quality of the routes that are computed can be measured by a number 268 of metrics, such as convergence, stability, and stretch. 270 The stretch factor is the maximum ratio between the length of a 271 route computed by the scheme and that of a shortest path 272 connecting the same pair of nodes. [JACM89] 274 A solution is strongly desired to provide routing quality equivalent 275 to what is available today or better. 277 3.9. Routing security 279 Currently, the routing subsystem is secured through a number of 280 protocol specific mechanisms of varying strength and applicability. 281 Any new architecture is required to provide at least the same level 282 of security as is deployed as of when the new architecture is 283 deployed. 285 3.10. Deployability 287 A viable solution is required to be deployable from a technical 288 perspective. Furthermore, given the extensive deployed base of 289 today's Internet, a solution is required to be incrementally 290 deployable. This implies that a solution must continue to support 291 the functions in today's routing subsystem that are actually used. 292 This includes but is not limited to the ability to control routing 293 based on policy. 295 3.11. Summary of priorities 297 The following table summarizes the priorities of the design goals 298 discussed above. 300 +------------------------+------------------+ 301 | Design goal | Priority | 302 +------------------------+------------------+ 303 | Scalability | Strongly desired | 304 | Traffic engineering | Strongly desired | 305 | Multi-homing | Strongly desired | 306 | Loc/id separation | Desired | 307 | Mobility | Desired | 308 | Simplified renumbering | Strongly desired | 309 | Modularity | Strongly desired | 310 | Routing quality | Strongly desired | 311 | Routing security | Required | 312 | Deployability | Required | 313 +------------------------+------------------+ 315 4. IANA Considerations 317 This memo includes no requests to IANA. 319 5. Security Considerations 321 All solutions are required to provide security that is at least as 322 strong as the existing Internet routing and addressing architecture. 323 This document does not default any architecture or any protocol, and 324 thus this document introduces no new security issues. 326 6. References 328 6.1. Normative References 330 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 331 RFC 1958, June 1996. 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 337 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 338 September 2005. 340 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 341 Workshop on Routing and Addressing", RFC 4984, 342 September 2007. 344 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 345 Still Needs Work", RFC 5887, May 2010. 347 6.2. Informative References 349 [BGPGrowth] 350 Huston, G., "BGP Routing Table Analysis Reports", 351 . 353 [IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the 354 Interconnection of Datagram Networks", Internet Experiment 355 Note (IEN) 1, INDRA Note 637, PSPWN 76, July 1977, 356 . 358 [JACM89] Peleg, D. and E. Upfal, "A trade-off between space and 359 efficiency for routing tables", Journal of the ACM Volume 360 36, Issue 3, July 1989, 361 . 363 Author's Address 365 Tony Li (editor) 366 Cisco Systems, Inc. 367 170 W. Tasman Dr. 368 San Jose, CA 95134 369 USA 371 Phone: +1 408 853 9317 372 Email: tli@cisco.com