RFC 5773
Analysis of Inter-Domain Routing Requirements and History
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 HistoryAbstract
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
Current practice: Routing does not consider dynamic resource
availability. Forwarding can support service
differentiation.
(page 25 continued on part 2)
