doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

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",
+                <http://bgp.potaroo.net/>.
+
+   [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, <http://www.postel.org/ien/pdf/ien001.pdf>.
+
+   [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,
+                <http://portal.acm.org/citation.cfm?id=65953>.
+
+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]
+