From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6227.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6227.txt (limited to 'doc/rfc/rfc6227.txt') diff --git a/doc/rfc/rfc6227.txt b/doc/rfc/rfc6227.txt new file mode 100644 index 0000000..6782478 --- /dev/null +++ b/doc/rfc/rfc6227.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Research Task Force (IRTF) T. Li, Ed. +Request for Comments: 6227 Cisco Systems, Inc. +Category: Informational May 2011 +ISSN: 2070-1721 + + + Design Goals for Scalable Internet Routing + +Abstract + + It is commonly recognized that the Internet routing and addressing + architecture is facing challenges in scalability, mobility, multi- + homing, and inter-domain traffic engineering. The Routing Research + Group is investigating an alternate architecture to meet these + challenges. This document consists of a prioritized list of design + goals for the target architecture. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Routing + Research Group of the Internet Research Task Force (IRTF). Documents + approved for publication by the IRSG are not a candidate for any + level of Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6227. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + +Li Informational [Page 1] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Language ......................................3 + 1.2. Priorities .................................................3 + 2. General Design Goals Collected from the Past ....................3 + 3. Design Goals for a New Routing Architecture .....................3 + 3.1. Improved Routing Scalability ...............................3 + 3.2. Scalable Support for Traffic Engineering ...................4 + 3.3. Scalable Support for Multi-Homing ..........................4 + 3.4. Decoupling Location and Identification .....................4 + 3.5. Scalable Support for Mobility ..............................5 + 3.6. Simplified Renumbering .....................................5 + 3.7. Modularity, Composability, and Seamlessness ................6 + 3.8. Routing Quality ............................................6 + 3.9. Routing Security ...........................................7 + 3.10. Deployability .............................................7 + 3.11. Summary of Priorities .....................................7 + 4. Security Considerations .........................................7 + 5. References ......................................................8 + 5.1. Normative References .......................................8 + 5.2. Informative References .....................................8 + +1. Introduction + + It is commonly recognized that the Internet routing and addressing + architecture is facing challenges in inter-domain scalability, + mobility, multi-homing, and inter-domain traffic engineering + [RFC4984]. The Routing Research Group (RRG) aims to design an + alternate architecture to meet these challenges. This document + presents a prioritized list of design goals for the target + architecture. + + These goals should be taken as guidelines for the design and + evaluation of possible architectural solutions. The expectation is + that these goals will be applied with good judgment. + + The goals presented here were initially presented and discussed at + the start of the RRG work on a revised routing architecture, and were + revisited and finalized after the work on that architecture was + complete. As such, this represents both the goals that the RRG + started with, and revisions to those goals based on our increased + understanding of the space. + + + + + + + + +Li Informational [Page 2] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.2. Priorities + + Each design goal in this document has been assigned a priority, which + is one of the following: 'required', 'strongly desired', or + 'desired'. + + Required: + The solution is REQUIRED to support this goal. + + Strongly desired: + The solution SHOULD support this goal, unless there exist + compelling reasons showing that it is unachievable, extremely + inefficient, or impractical. + + Desired: + The solution SHOULD support this goal. + +2. General Design Goals Collected from the Past + + [RFC1958] provides a list of the original architectural principles of + the Internet. We incorporate them here by reference, as part of our + desired design goals. + +3. Design Goals for a New Routing Architecture + +3.1. Improved Routing Scalability + + Long experience with inter-domain routing has shown that the global + BGP routing table is continuing to grow rapidly [BGPGrowth]. + Carrying this large amount of state in the inter-domain routing + protocols is expensive and places undue cost burdens on network + participants that do not necessarily get value from the increases in + the routing table size. Thus, the first required goal is to provide + significant improvement to the scalability of the inter-domain + routing subsystem. It is strongly desired to make the routing + subsystem scale independently from the growth of the Internet user + population. If there is a coupling between the size of the user base + and the scale of the routing subsystem, then it will be very + difficult to retain any semblance of scalability. If a solution + includes support for alternative routes to support faster + convergence, the alternative routes should also factor into routing + subsystem scalability. + + + +Li Informational [Page 3] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +3.2. Scalable Support for Traffic Engineering + + Traffic engineering is the capability of directing traffic along + paths other than those that would be computed by normal IGP/EGP + routing. Inter-domain traffic engineering today is frequently + accomplished by injecting more-specific prefixes into the global + routing table, which results in a negative impact on routing + scalability. The additional prefixes injected to enable traffic + engineering place an added burden on the scalability of the routing + architecture. At the same time, the need for traffic engineering + capabilities is essential to network operations. Thus, a scalable + solution for inter-domain traffic engineering is strongly desired. + +3.3. Scalable Support for Multi-Homing + + Multi-homing is the capability of an organization to be connected to + the Internet via more than one other organization. The current + mechanism for supporting multi-homing is to let the organization + advertise one prefix or multiple prefixes into the global routing + system, again resulting in a negative impact on routing scalability. + More scalable solutions for multi-homing are strongly desired. + +3.4. Decoupling Location and Identification + + Numerous sources have noted that an IP address embodies both host + attachment point information and identification information [IEN1]. + This overloading has caused numerous semantic collisions that have + limited the flexibility of the Internet architecture. Therefore, it + is desired that a solution separate the host location information + namespace from the identification namespace. + + Caution must be taken here to clearly distinguish the decoupling of + host location and identification information, and the decoupling of + end-site addresses from globally routable prefixes; the latter has + been proposed as one of the approaches to a scalable routing + architecture. Solutions to both problems, i.e., (1) the decoupling + of host location and identification information and (2) a scalable + global routing system (whose solution may, or may not, depend on the + second decoupling) are required, and it is required that their + solutions are compatible with each other. + + + + + + + + + + + +Li Informational [Page 4] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +3.5. Scalable Support for Mobility + + Mobility is the capability of a host, network, or organization to + change its topological connectivity with respect to the remainder of + the Internet, while continuing to receive packets from the Internet. + Existing mechanisms to provide mobility support include + + 1. renumbering the mobile entity as it changes its topological + attachment point(s) to the Internet; + + 2. renumbering and creating a tunnel from the entity's new + topological location back to its original location; and + + 3. letting the mobile entity announce its prefixes from its new + attachment point(s). + + The first approach alone is considered unsatisfactory, as the change + of IP address may break existing transport or higher-level + connections for those protocols using IP addresses as identifiers. + The second requires the deployment of a 'home agent' to keep track of + the mobile entity's current location and adds overhead to the routers + involved, as well as adding stretch to the path of an inbound packet. + Neither of the first two approaches impacts the routing scalability. + The third approach, however, injects dynamic updates into the global + routing system as the mobile entity moves. Mechanisms that help to + provide more efficient and scalable mobility support are desired, + especially when they can be coupled with security -- especially + privacy -- and support topological changes at a high rate. Ideally, + such mechanisms should completely decouple mobility from routing. + +3.6. Simplified Renumbering + + Today, many of the end-sites receive their IP address assignments + from their Internet Service Providers (ISPs). When such a site + changes providers, for routing to scale, the site must renumber into + a new address block assigned by its new ISP. This can be costly, + error-prone, and painful [RFC5887]. Automated tools, once developed, + are expected to provide significant help in reducing the renumbering + pain. It is not expected that renumbering will be wholly automated, + as some manual reconfiguration is likely to be necessary for changing + the last-mile link. However, the overall cost of renumbering should + be drastically lowered. + + In addition to being configured into hosts and routers, where + automated renumbering tools can help, IP addresses are also often + used for other purposes, such as access control lists. They are also + sometimes hard-coded into applications used in environments where + failure of the DNS could be catastrophic (e.g., certain remote + + + +Li Informational [Page 5] + +RFC 6227 Scalable Routing Design Goals May 2011 + + + monitoring applications). Although renumbering may be considered a + mild inconvenience for some sites, and guidelines have been developed + for renumbering a network without a flag day [RFC4192], for others, + the necessary changes are sufficiently difficult so as to make + renumbering effectively impossible. It is strongly desired that a + new architecture allow end-sites to renumber their network with + significantly less disruption, or, if renumbering can be eliminated, + the new architecture must demonstrate how the topology can be + economically morphed to fit the addressing. + +3.7. Modularity, Composability, and Seamlessness + + A new routing architecture should be modular: it should subdivide + into multiple composable, extensible, and orthogonal subsystems. The + interfaces between modules should be natural and seamless, without + special cases or restrictions. Similarly, the primitives and + abstractions in the architecture should be suitably general, with + operations equally applicable to abstractions and concrete entities, + and without deleterious side-effects that might hinder communication + between endpoints in the Internet. These properties are strongly + desired in a solution. + + As an example, if tunneling were used as a part of a solution, + tunneling should be completely transparent to both of the endpoints, + without requiring new mechanisms for determining the correct maximum + datagram size. + + The resulting network should always fully approximate the current + best-effort Internet connectivity model, and it should also + anticipate changes to that model, e.g., for multiple differentiated + and/or guaranteed levels of service in the future. + +3.8. Routing Quality + + The routing subsystem is responsible for computing a path from any + point in the Internet to any other point in the Internet. The + quality of the routes that are computed can be measured by a number + of metrics, such as convergence, stability, and stretch. + + The stretch factor is the maximum ratio between the length of a + route computed by the routing scheme and that of a shortest path + connecting the same pair of nodes [JACM89]. + + A solution is strongly desired to provide routing quality equivalent + to what is available today, or better. + + + + + + +Li Informational [Page 6] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +3.9. Routing Security + + Currently, the routing subsystem is secured through a number of + protocol-specific mechanisms of varying strength and applicability. + Any new architecture is required to provide at least the same level + of security as is deployed as of when the new architecture is + deployed. + +3.10. Deployability + + A viable solution is required to be deployable from a technical + perspective. Furthermore, given the extensive deployed base of + today's Internet, a solution is required to be incrementally + deployable. This implies that a solution must continue to support + those functions in today's routing subsystem that are actually used. + This includes, but is not limited to, the ability to control routing + based on policy. + +3.11. Summary of Priorities + + The following table summarizes the priorities of the design goals + discussed above. + + +------------------------+------------------+ + | Design goal | Priority | + +------------------------+------------------+ + | Scalability | Strongly desired | + | Traffic engineering | Strongly desired | + | Multi-homing | Strongly desired | + | Loc/id separation | Desired | + | Mobility | Desired | + | Simplified renumbering | Strongly desired | + | Modularity | Strongly desired | + | Routing quality | Strongly desired | + | Routing security | Required | + | Deployability | Required | + +------------------------+------------------+ + +4. Security Considerations + + All solutions are required to provide security that is at least as + strong as the existing Internet routing and addressing architecture. + This document does not suggest any default architecture or protocol, + and thus this document introduces no new security issues. + + + + + + + +Li Informational [Page 7] + +RFC 6227 Scalable Routing Design Goals May 2011 + + +5. References + +5.1. Normative References + + [RFC1958] Carpenter, B., Ed., "Architectural Principles of the + Internet", RFC 1958, June 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", + RFC 4192, September 2005. + + [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., + "Report from the IAB Workshop on Routing and + Addressing", RFC 4984, September 2007. + + [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering + Still Needs Work", RFC 5887, May 2010. + +5.2. Informative References + + [BGPGrowth] Huston, G., "BGP Routing Table Analysis Reports", + . + + [IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the + Interconnection of Datagram Networks", Internet + Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, + July 1977, . + + [JACM89] Peleg, D. and E. Upfal, "A trade-off between space and + efficiency for routing tables", Journal of the + ACM Volume 36, Issue 3, July 1989, + . + +Author's Address + + Tony Li (editor) + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA + + Phone: +1 408 853 9317 + EMail: tli@cisco.com + + + + + +Li Informational [Page 8] + -- cgit v1.2.3