tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5773

 Errata 
Historic
Pages: 51
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Analysis of Inter-Domain Routing Requirements and History

Part 1 of 2, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                            E. Davies
Request for Comments: 5773                              Folly Consulting
Category: Historic                                              A. Doria
ISSN: 2070-1721                                                      LTU
                                                           February 2010


       Analysis of Inter-Domain Routing Requirements and History

Abstract

   This document analyzes the state of the Internet domain-based routing
   system, concentrating on Inter-Domain Routing (IDR) and also
   considering the relationship between inter-domain and intra-domain
   routing.  The analysis is carried out with respect to RFC 1126 and
   other IDR requirements and design efforts looking at the routing
   system as it appeared to be in 2001 with editorial additions
   reflecting developments up to 2006.  It is the companion document to
   "A Set of Possible Requirements for a Future Routing Architecture"
   (RFC 5772), which is a discussion of requirements for the future
   routing architecture, addressing systems developments and future
   routing protocols.  This document summarizes discussions held several
   years ago by members of the IRTF Routing Research Group (IRTF RRG)
   and other interested parties.  The document is published with the
   support of the IRTF RRG as a record of the work completed at that
   time, but with the understanding that it does not necessarily
   represent either the latest technical understanding or the technical
   consensus of the research group at the date of publication.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   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 individual opinion(s) of one or
   more members 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/rfc5773.

Page 2 
Copyright Notice

   Copyright (c) 2010 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.

Top       Page 3 
Table of Contents

   1. Provenance of This Document .....................................4
   2. Introduction ....................................................5
      2.1. Background .................................................7
   3. Historical Perspective ..........................................7
      3.1. The Legacy of RFC 1126 .....................................7
           3.1.1. General Requirements ................................8
           3.1.2. "Functional Requirements" ..........................13
           3.1.3. "Non-Goals" ........................................21
      3.2. ISO OSI IDRP, BGP, and the Development of Policy Routing ..25
      3.3. Nimrod Requirements .......................................30
      3.4. PNNI ......................................................32
   4. Recent Research Work ...........................................33
      4.1. Developments in Internet Connectivity .....................33
      4.2. DARPA NewArch Project .....................................34
           4.2.1. Defending the End-to-End Principle .................35
   5. Existing Problems of BGP and the Current Inter-/Intra-Domain
      Architecture ...................................................35
      5.1. BGP and Auto-Aggregation ..................................36
      5.2. Convergence and Recovery Issues ...........................36
      5.3. Non-Locality of Effects of Instability and
           Misconfiguration ..........................................37
      5.4. Multi-Homing Issues .......................................37
      5.5. AS Number Exhaustion ......................................38
      5.6. Partitioned ASs ...........................................39
      5.7. Load Sharing ..............................................40
      5.8. Hold-Down Issues ..........................................40
      5.9. Interaction between Inter-Domain Routing and
           Intra-Domain Routing ......................................40
      5.10. Policy Issues ............................................42
      5.11. Security Issues ..........................................42
      5.12. Support of MPLS and VPNS .................................43
      5.13. IPv4/IPv6 Ships in the Night .............................43
      5.14. Existing Tools to Support Effective Deployment of
            Inter-Domain Routing .....................................44
           5.14.1. Routing Policy Specification Language RPSL
                   (RFC 2622 and RFC 2650) and RIPE NCC Database
                   (RIPE 157) ........................................44
   6. Security Considerations ........................................45
   7. Acknowledgments ................................................45
   8. Informative References .........................................46

Top      ToC       Page 4 
1.  Provenance of This Document

   In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha
   Ahuja and Sean Doran, decided to establish a sub-group to look at
   requirements for inter-domain routing (IDR).  A group of well-known
   routing experts was assembled to develop requirements for a new
   routing architecture.  Their mandate was to approach the problem
   starting from a blank slate.  This group was free to take any
   approach, including a revolutionary approach, in developing
   requirements for solving the problems they saw in inter-domain
   routing.  Their eventual approach documented requirements for a
   complete future routing and addressing architecture rather than just
   the requirements for IDR.

   Simultaneously, an independent effort was started in Sweden with a
   similar goal.  A team, calling itself Babylon, with participation
   from vendors, service providers, and academia, assembled to
   understand the history of inter-domain routing, to research the
   problems seen by the service providers, and to develop a proposal of
   requirements for a follow-on to the current routing architecture.
   This group's approach required an evolutionary approach starting from
   current routing architecture and practice.  In other words, the group
   limited itself to developing an evolutionary strategy and
   consequently assumed that the architecture would probably remain
   domain-based.  The Babylon group was later folded into the IRTF RRG
   as Sub-Group B to distinguish it from the original RRG Sub-Group A.

   This document, which was a part of Sub-Group B's output, provides a
   snapshot of the state of Inter-Domain Routing (IDR) at the time of
   original writing (2001) with some minor updates to take into account
   developments since that date, bringing it up to date in 2006.  The
   development of the new requirements set was then motivated by an
   analysis of the problems that IDR has been encountering in the recent
   past.  This document is intended as a counterpart to the Routing
   Requirements document ("A Set of Possible Requirements for a Future
   Routing Architecture"), which documents the requirements for future
   routing systems as captured separately by the IRTF RRG Sub-Groups A
   and B [RFC5772].

   The IRTF RRG supported publication of this document as a historical
   record of the work completed on the understanding that it does not
   necessarily represent either the latest technical understanding or
   the technical consensus of the research group at the time of
   publication.  The document has had substantial review by members of
   the Babylon team, members of the IRTF RRG, and others over the years.

Top      ToC       Page 5 
2.  Introduction

   For the greater part of its existence, the Internet has used a
   domain-oriented routing system whereby the routers and other nodes
   making up the infrastructure are partitioned into a set of
   administrative domains, primarily along ownership lines.  Individual
   routing domains (also known as Autonomous Systems (ASs)), which maybe
   a subset of an administrative domain, are made up of a finite,
   connected set of nodes (at least in normal operation).  Each routing
   domain is subject to a coherent set of routing and other policies
   managed by a single administrative authority.  The domains are
   interlinked to form the greater Internet, producing a very large
   network: in practice, we have to treat this network as if it were
   infinite in extent as there is no central knowledge about the whole
   network of domains.  An early presentation of the concept of routing
   domains can be found in Paul Francis' OSI routing architecture paper
   from 1987 [Tsuchiya87] (Paul Francis was formerly known as Paul
   Tsuchiya).

   The domain concept and domain-oriented routing has become so
   fundamental to Internet-routing thinking that it is generally taken
   as an axiom these days and not even defined again (cf., [NewArch03]).
   The issues discussed in the present document notwithstanding, it has
   proved to be a robust and successful architectural concept that
   brings with it the possibility of using different routing mechanisms
   and protocols within the domains (intra-domain) and between the
   domains (inter-domain).  This is an attractive division, because
   intra-domain protocols can exploit the well-known finite scope of the
   domain and the mutual trust engendered by shared ownership to give a
   high degree of control to the domain administrators, whereas inter-
   domain routing lives in an essentially infinite region featuring a
   climate of distrust built on a multitude of competitive commercial
   agreements and driven by less-than-fully-public policies from each
   component domain.  Of course, like any other assumption that has been
   around for a very long time, the domain concept should be reevaluated
   to make sure that it is still helping!

   It is generally accepted that there are major shortcomings in the
   inter-domain routing of the Internet today and that these may result
   in severe routing problems within an unspecified period of time.
   Remedying these shortcomings will require extensive research to tie
   down the exact failure modes that lead to these shortcomings and
   identify the best techniques to remedy the situation.  Comparatively,
   intra-domain routing works satisfactorily, and issues with intra-
   domain routing are mainly associated with the interface between
   intra- and inter-domain routing.

Top      ToC       Page 6 
      Reviewer's Note: Even in 2001, there was a wide difference of
      opinion across the community regarding the shortcomings of inter-
      domain routing.  In the years between writing and publication,
      further analysis, changes in operational practice, alterations to
      the demands made on inter-domain routing, modifications made to
      BGP and a recognition of the difficulty of finding a replacement
      may have altered the views of some members of the community.

   Changes in the nature and quality of the services that users want
   from the Internet are difficult to provide within the current
   framework, as they impose requirements never foreseen by the original
   architects of the Internet routing system.

   The kind of radical changes that have to be accommodated are
   epitomized by the advent of IPv6 and the application of IP mechanisms
   to private commercial networks that offer specific service guarantees
   beyond the best-effort services of the public Internet.  Major
   changes to the inter-domain routing system are inevitable to provide
   an efficient underpinning for the radically changed and increasingly
   commercially-based networks that rely on the IP protocol suite.

   Current practice stresses the need to separate the concerns of the
   control plane and the forwarding plane in a router: this document
   will follow this practice, but we still use the term "routing" as a
   global portmanteau to cover all aspects of the system.

   This document provides a historical perspective on the current state
   of inter-domain routing and its relationship to intra-domain routing
   in Section 3 by revisiting the previous IETF requirements document
   intended to steer the development of a future routing system.  These
   requirements, which informed the design of the Border Gateway
   Protocol (BGP) in 1989, are contained in RFC 1126 -- "Goals and
   Functional Requirements for Inter-Autonomous System Routing"
   [RFC1126].

   Section 3 also looks at some other work on requirements for domain-
   based routing that was carried out before and after RFC 1126 was
   published.  This work fleshes out the historical perspective and
   provides some additional insights into alternative approaches that
   may be instructive when building a new set of requirements.

   The motivation for change and the inspiration for some of the
   requirements for new routing architectures derive from the problems
   attributable to the current domain-based routing system that are
   being experienced in the Internet today.  These will be discussed in
   Section 5.

Top      ToC       Page 7 
2.1.  Background

   Today's Internet uses an addressing and routing structure that has
   developed in an ad hoc, more or less upwards-compatible fashion.  The
   structure has progressed from supporting a non-commercial Internet
   with a single administrative domain to a solution that is able to
   control today's multi-domain, federated Internet, carrying traffic
   between the networks of commercial, governmental, and not-for-profit
   participants.  This is not achieved without a great deal of 24/7
   vigilance and operational activity by network operators: Internet
   routing often appears to be running close to the limits of stability.
   As well as directing traffic to its intended endpoint, inter-domain
   routing mechanisms are expected to implement a host of domain-
   specific routing policies for competing, communicating domains.  The
   result is not ideal, particularly as regards inter-domain routing
   mechanisms, but it does a pretty fair job at its primary goal of
   providing any-to-any connectivity to many millions of computers.

   Based on a large body of anecdotal evidence, but also on a growing
   body of experimental evidence [Labovitz02] and analytic work on the
   stability of BGP under certain policy specifications [Griffin99], the
   main Internet inter-domain routing protocol, BGP version 4 (BGP-4),
   appears to have a number of problems.  These problems are discussed
   in more detail in Section 5.  Additionally, the hierarchical nature
   of the inter-domain routing problem appears to be changing as the
   connectivity between domains becomes increasingly meshed [RFC3221],
   which alters some of the scaling and structuring assumptions on which
   BGP-4 is built.  Patches and fix-ups may relieve some of these
   problems, but others may require a new architecture and new
   protocols.

3.  Historical Perspective

3.1.  The Legacy of RFC 1126

   RFC 1126 [RFC1126] outlined a set of requirements that were intended
   to guide the development of BGP.

      Editors' Note: When this document was reviewed by Yakov Rekhter,
      one of the designers of BGP, his view was that "While some people
      expected a set of requirements outlined in RFC 1126 to guide the
      development of BGP, in reality the development of BGP happened
      completely independently of RFC 1126.  In other words, from the
      point of view of the development of BGP, RFC 1126 turned out to be
      totally irrelevant".  On the other hand, it appears that BGP, as
      currently implemented, has met a large proportion of these
      requirements, especially for unicast traffic.

Top      ToC       Page 8 
   While the network is demonstrably different from what it was in 1989,
   having:

   o  moved from single to multiple administrative control,

   o  increased in size by several orders of magnitude, and

   o  migrated from a fairly tree-like connectivity graph to a meshier
      style

   many of the same requirements remain.  As a first step in setting
   requirements for the future, we need to understand the requirements
   that were originally set for the current protocols.  In charting a
   future architecture, we must first be sure to do no harm.  This means
   a future domain-based routing system has to support, as its base
   requirement, the level of function that is available today.

   The following sections each relate to a requirement, or non-
   requirement listed in RFC 1126.  In fact, the section names are
   direct quotes from the document.  The discussion of these
   requirements covers the following areas:

   Explanation:       Optional interpretation for today's audience of
                      the original intent of the requirement.

   Relevance:         Is the requirement of RFC 1126 still relevant, and
                      to what degree?  Should it be understood
                      differently in today's environment?

   Current practice:  How well is the requirement met by current
                      protocols and practice?

3.1.1.  General Requirements

3.1.1.1.  "Route to Destination"

   Timely routing to all reachable destinations, including multi-homing
   and multicast.

   Relevance:         Valid, but requirements for multi-homing need
                      further discussion and elucidation.  The
                      requirement should include multiple-source
                      multicast routing.

Top      ToC       Page 9 
   Current practice:  Multi-homing is not efficient, and the proposed
                      inter-domain multicast protocol Border Gateway
                      Multicast Protocol (BGMP) [RFC3913] is an add-on
                      to BGP following many of the same strategies but
                      not integrated into the BGP framework.

                         Editors' Note: Multicast routing has moved on
                         again since this was originally written.  By
                         2006, BGMP had been effectively superseded.
                         Multicast routing now uses Multi-protocol BGP
                         [RFC4760], the Multicast Source Discovery
                         Protocol (MSDP) [RFC3618], and Protocol
                         Independent Multicast - Sparse Mode (PIM-SM)
                         [RFC2362], [RFC4601], especially the Source
                         Specific Multicast (SSM) subset.

3.1.1.2.  "Routing is Assured"

   This requires that a user be notified within a reasonable time period
   after persistent attempts, about inability to provide a service.

   Relevance:         Valid.

   Current practice:  There are ICMP messages for this; but, in many
                      cases, they are not used, either because of fears
                      about creating message storms or uncertainty about
                      whether the end system can do anything useful with
                      the resulting information.  IPv6 implementations
                      may be able to make better use of the information
                      as they may have alternative addresses that could
                      be used to exploit an alternative routing.

3.1.1.3.  "Large System"

   The architecture was designed to accommodate the growth of the
   Internet.

   Relevance:         Valid.  Properties of Internet topology might be
                      an issue for future scalability (topology varies
                      from very sparse to quite dense at present).
                      Instead of setting out to accommodate growth in a
                      specific time period, indefinite growth should be
                      accommodated.  On the other hand, such growth has
                      to be accommodated without making the protocols
                      too expensive -- trade-offs may be necessary.

Top      ToC       Page 10 
   Current practice:  Scalability of the current protocols will not be
                      sufficient under the current rate of growth.
                      There are problems with BGP convergence for large
                      dense topologies, problems with the slow speed of
                      routing information propagation between routers in
                      transit domains through the intra-domain protocol,
                      for example, when a failure requires traffic to be
                      redirected to an alternative exit point from the
                      domain (see Section 5.9), limited support for
                      hierarchy, etc.

3.1.1.4.  "Autonomous Operation"

   This requirement encapsulates the need for administrative domains
   ("Autonomous Systems" - AS) to be able to operate autonomously as
   regards setting routing policy:

   Relevance:         Valid.  There may need to be additional
                      requirements for adjusting policy decisions to the
                      global functionality and for avoiding
                      contradictory policies.  This would decrease the
                      possibility of unstable routing behavior.

                      There is a need for handling various degrees of
                      trust in autonomous operations, ranging from no
                      trust (e.g., between separate ISPs) to very high
                      trust where the domains have a common goal of
                      optimizing their mutual policies.

                      Policies for intra-domain operations should, in
                      some cases, be revealed, using suitable
                      abstractions.

   Current practice:  Policy management is in the control of network
                      managers, as required, but there is little support
                      for handling policies at an abstract level for a
                      domain.

                      Cooperating administrative entities decide about
                      the extent of cooperation independently.  This can
                      lead to inconsistent, and potentially incompatible
                      routing policies being applied in notionally
                      cooperating domains.  As discussed in Sections
                      5.2, 5.3, and 5.10, lack of coordination combined
                      with global range of effects of BGP policies
                      results in occasional disruption of Internet
                      routing over an area far wider than the domains
                      that are not cooperating effectively.

Top      ToC       Page 11 
3.1.1.5.  "Distributed System"

   The routing environment is a distributed system.  The distributed
   routing environment supports redundancy and diversity of nodes and
   links.  Both the controlling rule sets, which implement the routing
   policies, and the places where operational control is applied,
   through decisions on path selection, are distributed (primarily in
   the routers).

   Relevance:         Valid.  RFC 1126 is very clear that we should not
                      be using centralized solutions, but maybe we need
                      a discussion on trade-offs between common
                      knowledge and distribution (i.e., to allow for
                      uniform policy routing, e.g., Global System for
                      Mobile Communications (GSM) systems are in a sense
                      centralized, but with hierarchies).

   Current practice:  Routing is very distributed, but lacking the
                      ability to consider optimization over several hops
                      or domains.

                         Editors' Note: Also, coordinating the
                         implementation of a set of routing policies
                         across a large domain with many routers running
                         BGP is difficult.  The policies have to be
                         turned into BGP rules and applied individually
                         to each router, giving opportunities for
                         mismatch and error.

3.1.1.6.  "Provide A Credible Environment"

   The routing environment and services should be based upon mechanisms
   and information that exhibit both integrity and security.  That is,
   the routers should always be working with credible data derived
   through the reliable operation of protocols.  Security from unwanted
   modification and influence is required.

   Relevance:         Valid.

   Current practice:  BGP provides a limited mechanism for
                      authentication and security of peering sessions,
                      but this does not guarantee the authenticity or
                      validity of the routing information that is
                      exchanged.

Top      ToC       Page 12 
                      There are certainly security problems with the
                      current practice.  The Routing Protocol Security
                      Requirements (rpsec) working group has been
                      struggling to agree on a set of requirements for
                      BGP security since early 2002.

                         Editors' Note: Proposals for authenticating BGP
                         routing information using certificates were
                         under development by the Secure Inter-Domain
                         Routing (sidr) working group from 2006 through
                         2008.

3.1.1.7.  "Be A Managed Entity"

   This requires that the routing system provides adequate information
   on the state of the network to allow resource, problem, and fault
   management to be carried out effectively and expeditiously.  The
   system must also provide controls that allow managers to use this
   information to make informed decisions and use it to control the
   operation of the routing system.

   Relevance:         The requirement is reasonable, but we might need
                      to be more specific on what information should be
                      available, e.g., to prevent routing oscillations.

   Current practice:  All policies are determined locally, where they
                      may appear reasonable but there is limited global
                      coordination through the routing policy databases
                      operated by the Internet registries (AfriNIC,
                      APNIC, ARIN, LACNIC, RIPE, etc.).

                      Operators are not required to register their
                      policies; even when policies are registered, it is
                      difficult to check that the actual policies in use
                      in other domains match the declared policies.
                      Therefore, a manager cannot guarantee to design
                      and implement policies that will interoperate with
                      those of other domains to provide stable routing.

                         Editors' Note: Operators report that management
                         of BGP-based routing remains a function that
                         needs highly-skilled operators and continual
                         attention.

Top      ToC       Page 13 
3.1.1.8.  "Minimize Required Resources"

   Relevance:         Valid.  However, the paragraph states that
                      assumptions on significant upgrades shouldn't be
                      made.  Although this is reasonable, a new
                      architecture should perhaps be prepared to use
                      upgrades when they occur.

   Current practice:  Most bandwidth is consumed by the exchange of the
                      Network Layer Reachability Information (NLRI).
                      Usage of processing cycles ("Central Processor
                      Usage" - CPU) depends on the stability of the
                      Internet.  Both phenomena have a local nature, so
                      there are not scaling problems with bandwidth and
                      CPU usage.  Instability of routing increases the
                      consumption of resources in any case.  The number
                      of networks in the Internet dominates memory
                      requirements -- this is a scaling problem.

3.1.2.  "Functional Requirements"

3.1.2.1.  "Route Synthesis Requirements"

3.1.2.1.1.  "Route around failures dynamically"

   Relevance:         Valid.  Should perhaps be stronger.  Only
                      providing a best-effort attempt may not be enough
                      if real-time services are to be provided for.
                      Detection of failures may need to be faster than
                      100 ms to avoid being noticed by end-users.

   Current practice:  Latency of fail-over is too high; sometimes
                      minutes or longer.

3.1.2.1.2.  "Provide loop free paths"

   Relevance:         Valid.  Loops should occur only with negligible
                      probability and duration.

   Current practice:  Both link-state intra-domain routing and BGP
                      inter-domain routing (if correctly configured) are
                      forwarding-loop-free after having converged.
                      However, convergence time for BGP can be very
                      long, and poorly designed routing policies may
                      result in a number of BGP speakers engaging in a
                      cyclic pattern of advertisements and withdrawals
                      that never converges to a stable result [RFC3345].
                      Part of the reason for long convergence times is

Top      ToC       Page 14 
                      the non-locality of the effects of changes in BGP
                      advertisements (see Section 5.3).  Modifying the
                      inter-domain routing protocol to make the effects
                      of changes less global, and convergence a more
                      local condition, might improve performance,
                      assuming a suitable modification could be
                      developed.

3.1.2.1.3.  "Know when a path or destination is unavailable"

   Relevance:         Valid to some extent, but there is a trade-off
                      between aggregation and immediate knowledge of
                      reachability.  It requires that routing tables
                      contain enough information to determine that the
                      destination is unknown or a path cannot be
                      constructed to reach it.

   Current practice:  Knowledge about lost reachability propagates
                      slowly through the networks due to slow
                      convergence for route withdrawals.

3.1.2.1.4.  "Provide paths sensitive to administrative policies"

   Relevance:         Valid.  Policy control of routing has become
                      increasingly important as the Internet has turned
                      into a business.

   Current practice:  Supported to some extent.  Policies can only be
                      applied locally in an AS and not globally.  Policy
                      information supplied has a very small probability
                      of affecting policies in other ASs.  Furthermore,
                      only static policies are supported; between static
                      policies and policies dependent upon volatile
                      events of great celerity, there should exist
                      events of which routing should be aware.  Lastly,
                      there is no support for policies other than route-
                      properties (such as AS-origin, AS-path,
                      destination prefix, Multi-Exit Discriminator-
                      values (MED-values), etc).

                         Editors' Note: Subsequent to the original issue
                         of this document, mechanisms that acknowledge
                         the business relationships of operators have
                         been developed such as the NOPEER community
                         attribute [RFC3765].  However, the level of
                         usage of this attribute is apparently not very
                         great.

Top      ToC       Page 15 
3.1.2.1.5.  "Provide paths sensitive to user policies"

   Relevance:         Valid to some extent, as they may conflict with
                      the policies of the network administrator.  It is
                      likely that this requirement will be met by means
                      of different bit-transport services offered by an
                      operator, but at the cost of adequate
                      provisioning, authentication, and policing when
                      utilizing the service.

   Current practice:  Not supported in normal routing.  Can be
                      accomplished to some extent with loose source
                      routing, resulting in inefficient forwarding in
                      the routers.  The various attempts to introduce
                      Quality of Service (QoS -- e.g., Integrated
                      Services and Differentiated Services (Diffserv))
                      can also be seen as means to support this
                      requirement, but they have met with limited
                      success in terms of providing alternate routes as
                      opposed to providing improved service on the
                      standard route.

                         Editors' Note: From the standpoint of a later
                         time, it would probably be more appropriate to
                         say "total failure" rather than "limited
                         success".

3.1.2.1.6.  "Provide paths which characterize user quality-of-service
            requirements"

   Relevance:         Valid to some extent, as they may conflict with
                      the policies of the operator.  It is likely that
                      this requirement will be met by means of different
                      bit-transport services offered by an operator, but
                      at the cost of adequate provisioning,
                      authentication, and policing when utilizing the
                      service.  It has become clear that offering to
                      provide a particular QoS to any arbitrary
                      destination from a particular source is generally
                      impossible: QoS, except in very "soft" forms such
                      as overall long-term average packet delay, is
                      generally associated with connection-oriented
                      routing.

   Current practice:  Creating routes with specified QoS is not
                      generally possible at present.

Top      ToC       Page 16 
3.1.2.1.7.  "Provide autonomy between inter- and intra-autonomous system
            route synthesis"

   Relevance:         Inter- and intra-domain routing should stay
                      independent, but one should notice that this, to
                      some extent, contradicts the previous three
                      requirements.  There is a trade-off between
                      abstraction and optimality.

   Current practice:  Inter-domain routing is performed independently of
                      intra-domain routing.  Intra-domain routing is
                      however, especially in transit domains, very
                      interrelated with inter-domain routing.

3.1.2.2.  "Forwarding Requirements"

3.1.2.2.1.  "Decouple inter- and intra-autonomous system forwarding
            decisions"

   Relevance:         Valid.

   Current practice:  As explained in Section 3.1.2.1.7, intra-domain
                      forwarding in transit domains is dependent on
                      inter-domain forwarding decisions.

3.1.2.2.2.  "Do not forward datagrams deemed administratively
            inappropriate"

   Relevance:         Valid, and increasingly important in the context
                      of enforcing policies correctly expressed through
                      routing advertisements but flouted by rogue peers
                      that send traffic for which a route has not been
                      advertised.  On the other hand, packets that have
                      been misrouted due to transient routing problems
                      perhaps should be forwarded to reach the
                      destination, although along an unexpected path.

   Current practice:  At stub domains (i.e., domains that do not provide
                      any transit service for any other domains but that
                      connect directly to one or more transit domains),
                      there is packet filtering, e.g., to catch source
                      address spoofing on outgoing traffic or to filter
                      out unwanted incoming traffic.  Filtering can in
                      particular reject traffic (such as unauthorized
                      transit traffic) that has been sent to a domain
                      even when it has not advertised a route for such
                      traffic on a given interface.  The growing class
                      of "middleboxes" (midboxes, e.g., Network Address

Top      ToC       Page 17 
                      Translators -- NATs) is quite likely to apply
                      administrative rules that will prevent the
                      forwarding of packets.  Note that security
                      policies may deliberately hide administrative
                      denials.  In the backbone, intentional packet
                      dropping based on policies is not common.

3.1.2.2.3.  "Do not forward datagrams to failed resources"

   Relevance:         Unclear, although it is clearly desirable to
                      minimize the waste of forwarding resources by
                      discarding datagrams that cannot be delivered at
                      the earliest opportunity.  There is a trade-off
                      between scalability and keeping track of
                      unreachable resources.  The requirement
                      effectively imposes a requirement on adjacent
                      nodes to monitor for failures and take steps to
                      cause rerouting at the earliest opportunity, if a
                      failure is detected.  However, packets that are
                      already in-flight or queued on a failed link
                      cannot generally be rescued.

   Current practice:  Routing protocols use both internal adjacency
                      management sub-protocols (e.g., "hello" protocols)
                      and information from equipment and lower-layer
                      link watchdogs to keep track of failures in
                      routers and connecting links.  Failures will
                      eventually result in the routing protocol
                      reconfiguring the routing to avoid (if possible) a
                      failed resource, but this is generally very slow
                      (30s or more).  In the meantime, datagrams may
                      well be forwarded to failed resources.  In general
                      terms, end hosts and some non-router middleboxes
                      do not participate in these notifications, and
                      failures of such boxes will not affect the routing
                      system.

3.1.2.2.4.  "Forward datagram according to its characteristics"

   Relevance:         Valid.  This is necessary in enabling
                      differentiation in the network, based on QoS,
                      precedence, policy or security.

   Current practice:  Ingress and egress filtering can be done based on
                      policy.  Some networks discriminate on the basis
                      of requested QoS.

Top      ToC       Page 18 
3.1.2.3.  "Information Requirements"

3.1.2.3.1.  "Provide a distributed and descriptive information base"

   Relevance:         Valid.  However, an alternative arrangement of
                      information bases, possibly with an element of
                      centralization for the domain (as mentioned in
                      Section 3.1.1.5) might offer some advantages
                      through the ability to optimize across the domain
                      and respond more quickly to changes and failures.

   Current practice:  The information base is distributed, but it is
                      unclear whether it supports all necessary routing
                      functionality.

3.1.2.3.2.  "Determine resource availability"

   Relevance:         Valid.  It should be possible to determine the
                      availability and levels of availability of any
                      resource (such as bandwidth) needed to carry out
                      routing.  This prevents needing to discover
                      unavailability through failure.  Resource location
                      and discovery is arguably a separate concern that
                      could be addressed outside the core routing
                      requirements.

   Current practice:  Resource availability is predominantly handled
                      outside of the routing system.

3.1.2.3.3.  "Restrain transmission utilization"

   Relevance:         Valid.  However, certain requirements in the
                      control plane, such as fast detection of faults
                      may be worth consumption of more resources.
                      Similarly, simplicity of implementation may make
                      it cheaper to "back haul" traffic to central
                      locations to minimize the cost of routing if
                      bandwidth is cheaper than processing.

   Current practice:  BGP messages probably do not ordinarily consume
                      excessive resources, but might during erroneous
                      conditions.  In the data plane, the nearly
                      universal adoption of shortest-path protocols
                      could be considered to result in minimization of
                      transmission utilization.

Top      ToC       Page 19 
3.1.2.3.4.  "Allow limited information exchange"

   Relevance:         Valid.  But perhaps routing could be improved if
                      certain information (especially policies) could be
                      available either globally or at least for a wider-
                      defined locality.

                         Editors' Note: Limited information exchange
                         would be potentially compatible with a more
                         local form of convergence than BGP tries to
                         achieve today.  Limited information exchange is
                         potentially incompatible with global
                         convergence.

   Current practice:  Policies are used to determine which reachability
                      information is exported, but neighbors receiving
                      the information are not generally aware of the
                      policies that resulted in this export.

3.1.2.4.  "Environmental Requirements"

3.1.2.4.1.  "Support a packet-switching environment"

   Relevance:         Valid, but routing system should, perhaps, not be
                      limited to this exclusively.

   Current practice:  Supported.

3.1.2.4.2.  "Accommodate a connection-less oriented user transport
            service"

   Relevance:         Valid, but routing system should, perhaps, not be
                      limited to this exclusively.

   Current practice:  Accommodated.

3.1.2.4.3.  "Accommodate 10K autonomous systems and 100K networks"

   Relevance:         No longer valid.  Needs to be increased --
                      potentially indefinitely.  It is extremely
                      difficult to foresee the future size expansion of
                      the Internet, so the Utopian solution would be to
                      achieve an Internet whose architecture is scale
                      invariant.  Regrettably, this may not be
                      achievable without introducing undesirable
                      complexity and a suitable trade-off between
                      complexity and scalability is likely to be
                      necessary.

Top      ToC       Page 20 
   Current Practice:  Supported, but perhaps reaching its limit.  Since
                      the original version of this document was written
                      in 2001, the number of ASs advertised has grown
                      from around 8000 to 20000, and almost 35000 AS
                      numbers have been allocated by the regional
                      registries [Huston05].  If this growth continues,
                      the original 16-bit AS space in BGP-4 will be
                      exhausted in less than 5 years.  Planning for an
                      extended AS space is now an urgent requirement.

                         Editors' Note: At the time of publication, 32-
                         bit AS numbers have been introduced and are
                         being deployed.

3.1.2.4.4.  "Allow for arbitrary interconnection of autonomous systems"

   Relevance:         Valid.  However, perhaps not all interconnections
                      should be accessible globally.

   Current practice:  BGP-4 allows for arbitrary interconnections.

3.1.2.5.  "General Objectives"

3.1.2.5.1.  "Provide routing services in a timely manner"

   Relevance:         Valid, as stated before.  It might be acceptable
                      for a more complex service to take longer to
                      deliver, but it still has to meet the
                      application's requirements -- routing has to be at
                      the service of the end-to-end principle.

                         Editors' Note: Delays in setting up connections
                         due to network functions such as NAT boxes are
                         becoming increasingly problematic.  The routing
                         system should try to keep any routing delay to
                         a minimum.

   Current practice:  More or less, with the exception of convergence
                      and fault robustness.

3.1.2.5.2.  "Minimize constraints on systems with limited resources"

   Relevance:         Valid.

   Current practice:  Systems with limited resources are typically stub
                      domains that advertise very little information.

Top      ToC       Page 21 
3.1.2.5.3.  "Minimize impact of dissimilarities between autonomous
            systems"

   Relevance:         Important.  This requirement is critical to a
                      future architecture.  In a domain-based routing
                      environment where the internal properties of
                      domains may differ radically, it will be important
                      to be sure that these dissimilarities are
                      minimized at the borders.

   Current: practice: For the most part, this capability is not really
                      required in today's networks since the intra-
                      domain attributes are broadly similar across
                      domains.

3.1.2.5.4.  "Accommodate the addressing schemes and protocol mechanisms
            of the autonomous systems"

   Relevance:         Important, probably more so than when RFC 1126 was
                      originally developed because of the potential
                      deployment of IPv6, wider usage of MPLS, and the
                      increasing usage of VPNs.

   Current practice:  Only one global addressing scheme is supported in
                      most autonomous systems, but the availability of
                      IPv6 services is steadily increasing.  Some global
                      backbones support IPv6 routing and forwarding.

3.1.2.5.5.  "Must be implementable by network vendors"

   Relevance:         Valid, but note that what can be implemented today
                      is different from what was possible when RFC 1126
                      was written: a future domain-based routing
                      architecture should not be unreasonably
                      constrained by past limitations.

   Current practice:  BGP was implemented and meets a large proportion
                      of the original requirements.

3.1.3.  "Non-Goals"

   RFC 1126 also included a section discussing non-goals.  This section
   discusses the extent to which these are still non-goals.  It also
   considers whether the fact that they were non-goals adversely affects
   today's IDR system.

Top      ToC       Page 22 
3.1.3.1.  "Ubiquity"

   The authors of RFC 1126 were explicitly saying that IP and its inter-
   domain routing system need not be deployed in every AS, and a
   participant should not necessarily expect to be able to reach a given
   AS, possibly because of routing policies.  In a sense, this "non-
   goal" has effectively been achieved by the Internet and IP protocols.
   This requirement reflects a different worldview where there was
   serious competition for network protocols, which is really no longer
   the case.  Ubiquitous deployment of inter-domain routing in
   particular has been achieved and must not be undone by any proposed
   future domain-based routing architecture.  On the other hand:

   o  ubiquitous connectivity cannot be reached in a policy-sensitive
      environment and should not be an aim.

         Editors' Note: It has been pointed out that this statement
         could be interpreted as being contrary to the Internet mission
         of providing universal connectivity.  The fact that limits to
         connectivity will be added as operational requirements in a
         policy-sensitive environment should not imply that a future
         domain-based routing architecture contains intrinsic limits on
         connectivity.

   o  it must not be required that the same routing mechanisms are used
      throughout, provided that they can interoperate appropriately.

   o  the information needed to control routing in a part of the network
      should not necessarily be ubiquitously available, and it must be
      possible for an operator to hide commercially sensitive
      information that is not needed outside a domain.

   o  the introduction of IPv6 reintroduces an element of diversity into
      the world of network protocols, but the similarities of IPv4 and
      IPv6 as regards routing and forwarding make this event less likely
      to drive an immediate diversification in routing systems.  The
      potential for further growth in the size of the network enabled by
      IPv6 is very likely to require changes in the future: whether this
      results in the replacement of one de facto ubiquitous system with
      another remains to be seen but cannot be a requirement -- it will
      have to interoperate with BGP during the transition.

   Relevance:         De facto essential for a future domain-based
                      routing architecture, but what is required is
                      ubiquity of the routing system rather than
                      ubiquity of connectivity and it must be capable of
                      a gradual takeover through interoperation with the
                      existing system.

Top      ToC       Page 23 
   Current practice:  De facto ubiquity achieved.

3.1.3.2.  "Congestion control"

   Relevance:         It is not clear if this non-goal was to be applied
                      to routing or forwarding.  It is definitely a non-
                      goal to adapt the choice of route when there is
                      transient congestion.  However, to add support for
                      congestion avoidance (e.g., Explicit Congestion
                      Notification (ECN) and ICMP messages) in the
                      forwarding process would be a useful addition.
                      There is also extensive work going on in traffic
                      engineering that should result in congestion
                      avoidance through routing as well as in
                      forwarding.

   Current practice:  Some ICMP messages (e.g., source quench) exist to
                      deal with congestion control, but these are not
                      generally used as they either make the problem
                      worse or there is no mechanism to reflect the
                      message into the application that is providing the
                      source.

3.1.3.3.  "Load splitting"

   Relevance:         This should neither be a non-goal nor an explicit
                      goal.  It might be desirable in some cases and
                      should be considered as an optional architectural
                      feature.

   Current practice:  Can be implemented by exporting different prefixes
                      on different links, but this requires manual
                      configuration and does not consider actual load.

                         Editors' Note: This configuration is carried
                         out extensively as of 2006 and has been a
                         significant factor in routing table bloat.  If
                         this need is a real operational requirement, as
                         it seems to be for multi-homed or otherwise
                         richly connected sites, it will be necessary to
                         reclassify this as a real and important goal.

Top      ToC       Page 24 
3.1.3.4.  "Maximizing the utilization of resources"

   Relevance:         Valid.  Cost-efficiency should be striven for; we
                      note that maximizing resource utilization does not
                      always lead to the greatest cost-efficiency.

   Current practice:  Not currently part of the system, though often a
                      "hacked in" feature done with manual
                      configuration.

3.1.3.5.  "Schedule to deadline service"

   This non-goal was put in place to ensure that the IDR did not have to
   meet real-time deadline goals such as might apply to Constant Bit
   Rate (CBR) real-time services in ATM.

   Relevance:         The hard form of deadline services is still a non-
                      goal for the future domain-based routing
                      architecture, but overall delay bounds are much
                      more of the essence than was the case when RFC
                      1126 was written.

   Current practice:  Service providers are now offering overall
                      probabilistic delay bounds on traffic contracts.
                      To implement these contracts, there is a
                      requirement for a rather looser form of delay
                      sensitive routing.

3.1.3.6.  "Non-interference policies of resource utilization"

   The requirement in RFC 1126 is somewhat opaque, but appears to imply
   that what we would today call QoS routing is a non-goal and that
   routing would not seek to control the elastic characteristics of
   Internet traffic whereby a TCP connection can seek to utilize all the
   spare bandwidth on a route, possibly to the detriment of other
   connections sharing the route or crossing it.

   Relevance:         Open Issue.  It is not clear whether dynamic QoS
                      routing can or should be implemented.  Such a
                      system would seek to control the admission and
                      routing of traffic depending on current or recent
                      resource utilization.  This would be particularly
                      problematic where traffic crosses an ownership
                      boundary because of the need for potentially
                      commercially sensitive information to be made
                      available outside the ownership boundary.

Top      ToC       Page 25 
   Current practice:  Routing does not consider dynamic resource
                      availability.  Forwarding can support service
                      differentiation.



(page 25 continued on part 2)

Next RFC Part