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
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
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.
Table of Contents
1. Provenance of This Document .....................................42. Introduction ....................................................52.1. Background .................................................73. Historical Perspective ..........................................73.1. The Legacy of RFC 1126 .....................................73.1.1. General Requirements ................................83.1.2. "Functional Requirements" ..........................133.1.3. "Non-Goals" ........................................213.2. ISO OSI IDRP, BGP, and the Development of Policy Routing ..253.3. Nimrod Requirements .......................................303.4. PNNI ......................................................324. Recent Research Work ...........................................334.1. Developments in Internet Connectivity .....................334.2. DARPA NewArch Project .....................................344.2.1. Defending the End-to-End Principle .................355. Existing Problems of BGP and the Current Inter-/Intra-Domain
Architecture ...................................................355.1. BGP and Auto-Aggregation ..................................365.2. Convergence and Recovery Issues ...........................365.3. Non-Locality of Effects of Instability and
Misconfiguration ..........................................375.4. Multi-Homing Issues .......................................375.5. AS Number Exhaustion ......................................385.6. Partitioned ASs ...........................................395.7. Load Sharing ..............................................405.8. Hold-Down Issues ..........................................405.9. Interaction between Inter-Domain Routing and
Intra-Domain Routing ......................................405.10. Policy Issues ............................................425.11. Security Issues ..........................................425.12. Support of MPLS and VPNS .................................435.13. IPv4/IPv6 Ships in the Night .............................435.14. Existing Tools to Support Effective Deployment of
Inter-Domain Routing .....................................445.14.1. Routing Policy Specification Language RPSL
(RFC 2622 and RFC 2650) and RIPE NCC Database
(RIPE 157) ........................................446. Security Considerations ........................................457. Acknowledgments ................................................458. Informative References .........................................46
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.
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
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.
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"
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
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
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.
While the network is demonstrably different from what it was in 1989,
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
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
220.127.116.11. "Route to Destination"
Timely routing to all reachable destinations, including multi-homing
Relevance: Valid, but requirements for multi-homing need
further discussion and elucidation. The
requirement should include multiple-source
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.
18.104.22.168. "Routing is Assured"
This requires that a user be notified within a reasonable time period
after persistent attempts, about inability to provide a service.
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.
22.214.171.124. "Large System"
The architecture was designed to accommodate the growth of the
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.
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
126.96.36.199. "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
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
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.
188.8.131.52. "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
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
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.
184.108.40.206. "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.
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
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
220.127.116.11. "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
18.104.22.168. "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"
22.214.171.124. "Route Synthesis Requirements"
126.96.36.199.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.
188.8.131.52.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
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
184.108.40.206.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.
220.127.116.11.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
18.104.22.168.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
Editors' Note: From the standpoint of a later
time, it would probably be more appropriate to
say "total failure" rather than "limited
22.214.171.124.6. "Provide paths which characterize user quality-of-service
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
Current practice: Creating routes with specified QoS is not
generally possible at present.
126.96.36.199.7. "Provide autonomy between inter- and intra-autonomous system
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.
188.8.131.52. "Forwarding Requirements"
184.108.40.206.1. "Decouple inter- and intra-autonomous system forwarding
Current practice: As explained in Section 220.127.116.11.7, intra-domain
forwarding in transit domains is dependent on
inter-domain forwarding decisions.
18.104.22.168.2. "Do not forward datagrams deemed administratively
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
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.
22.214.171.124.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
126.96.36.199.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.
188.8.131.52. "Information Requirements"
184.108.40.206.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 220.127.116.11) 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
18.104.22.168.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
Current practice: Resource availability is predominantly handled
outside of the routing system.
22.214.171.124.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
126.96.36.199.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-
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
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.
188.8.131.52. "Environmental Requirements"
184.108.40.206.1. "Support a packet-switching environment"
Relevance: Valid, but routing system should, perhaps, not be
limited to this exclusively.
Current practice: Supported.
220.127.116.11.2. "Accommodate a connection-less oriented user transport
Relevance: Valid, but routing system should, perhaps, not be
limited to this exclusively.
Current practice: Accommodated.
18.104.22.168.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
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
22.214.171.124.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.
126.96.36.199. "General Objectives"
188.8.131.52.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
Current practice: More or less, with the exception of convergence
and fault robustness.
184.108.40.206.2. "Minimize constraints on systems with limited resources"
Current practice: Systems with limited resources are typically stub
domains that advertise very little information.
220.127.116.11.3. "Minimize impact of dissimilarities between autonomous
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
18.104.22.168.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.
22.214.171.124.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.
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.
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
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
Current practice: De facto ubiquity achieved.
126.96.36.199. "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
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
188.8.131.52. "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
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.
184.108.40.206. "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
220.127.116.11. "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
18.104.22.168. "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.