Design Goals for Scalable Internet Routing
draft-irtf-rrg-design-goals-06

Internet Research Task Force                                  T. Li, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                           January 3, 2011
Expires: July 7, 2011

               Design Goals for Scalable Internet Routing
                     draft-irtf-rrg-design-goals-06

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 7, 2011.

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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as

Li                        Expires July 7, 2011                  [Page 1]
Internet-Draft        Scalable Routing Design Goals         January 2011

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
     1.2.  Priorities  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  General Design Goals Collected from Past  . . . . . . . . . . . 3
   3.  Design Goals for A New Routing Architecture . . . . . . . . . . 4
     3.1.  Improved routing scalability  . . . . . . . . . . . . . . . 4
     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 . . . . . . . . . . . . . . . . . . . . . . 7
     3.9.  Routing security  . . . . . . . . . . . . . . . . . . . . . 7
     3.10. Deployability . . . . . . . . . . . . . . . . . . . . . . . 7
     3.11. Summary of priorities . . . . . . . . . . . . . . . . . . . 7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Li                        Expires July 7, 2011                  [Page 2]
Internet-Draft        Scalable Routing Design Goals         January 2011

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 RG
   started with, plus revisions to those goals based on our increased
   understanding of the space.

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 'required', 'strongly desired', and 'desired'.

   Required:  The solution is REQUIRED to support this goal.

   Strongly desired:  The solution SHOULD support this goal unless there
           exist compelling reasons showing it is unachievable,
           extremely inefficient, or impractical.

   Desired:  The solution SHOULD support this goal.

2.  General Design Goals Collected from 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.

Li                        Expires July 7, 2011                  [Page 3]
Internet-Draft        Scalable Routing Design Goals         January 2011

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.

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 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 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

Li                        Expires July 7, 2011                  [Page 4]
Internet-Draft        Scalable Routing Design Goals         January 2011

   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.

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 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 (ISP).  When such a site changes
   providers, for routing to scale, the site must renumber into a new

Li                        Expires July 7, 2011                  [Page 5]
Internet-Draft        Scalable Routing Design Goals         January 2011

   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
   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 upon levels of service in the future.

Li                        Expires July 7, 2011                  [Page 6]
Internet-Draft        Scalable Routing Design Goals         January 2011

3.8.  Routing quality

   The routing subsystem is responsible for computing a path from any
   point on 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 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.

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
   the 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.

Li                        Expires July 7, 2011                  [Page 7]
Internet-Draft        Scalable Routing Design Goals         January 2011

               +------------------------+------------------+
               | 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.  IANA Considerations

   This memo includes no requests to IANA.

5.  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 default any architecture or any protocol, and
   thus this document introduces no new security issues.

6.  References

6.1.  Normative References

   [RFC1958]  Carpenter, B., "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., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering

Li                        Expires July 7, 2011                  [Page 8]
Internet-Draft        Scalable Routing Design Goals         January 2011

              Still Needs Work", RFC 5887, May 2010.

6.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                        Expires July 7, 2011                  [Page 9]