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