IRTF Routing Research Group F. Kastenholz,
Internet Draft (ed)
Document <draft-irtf-routing-reqs-groupa- Unisphere Networks
00.txt> April 2002
Category: Informational
Requirements For a Next Generation
Routing and Addressing Architecture
< draft-irtf-routing-reqs-groupa-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet- Drafts as reference material or
to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Kastenholz (ed) Informational - Expires 10/2002 1
Inter-domain Routing Requirements March 2002
Table of Contents
1 Abstract...................................................3
2 Conventions used in this document..........................3
3 Requirements...............................................4
3.1 Architecture..........................................4
3.2 Separable Components..................................5
3.3 Scalable..............................................6
3.4 Lots of Interconnectivity.............................7
3.5 Random Structure......................................8
3.6 Multi-homing..........................................9
3.7 Multi-path............................................9
3.8 Convergence..........................................10
3.9 Routing System Security..............................12
3.10 End Host Security....................................14
3.11 Rich Policy..........................................14
3.11.1 Routing Information Policies......................14
3.11.2 Traffic Control Policies..........................15
3.12 Incremental Deployment...............................16
3.13 Mobility.............................................16
3.14 Address Portability..................................17
3.15 Multi-Protocol.......................................17
3.16 Abstraction..........................................17
3.17 Simplicity...........................................18
3.18 Robustness...........................................18
3.19 Media Independence...................................19
3.20 Stand-alone..........................................19
3.21 Safety of Configuration..............................19
3.22 Renumbering..........................................19
3.23 Multi-prefix.........................................19
3.24 Cooperative Anarchy..................................19
3.25 Network Layer Protocols and Forwarding Model.........20
3.26 Routing Algorithm....................................20
3.27 Positive Benefit.....................................20
3.28 Administrative Entities and the IGP/EGP Split........20
4 Non-Requirements..........................................21
4.1 Forwarding Table Optimization........................21
4.2 Traffic Engineering..................................21
4.3 Multicast............................................22
4.4 QOS..................................................22
4.5 IP Prefix Aggregation................................22
4.6 Perfect Safety.......................................23
4.7 Dynamic Load Balancing...............................23
4.8 Renumbering of hosts and routers.....................23
4.9 Host Mobility........................................23
4.10 Clean Slate..........................................24
Kastenholz Informational -- Expires 10/2002 2
Inter-domain Routing Requirements March 2002
5 Discussion of other Inter-Domain Routing Requirements
documents....................................................24
5.1 Comments on "Architectural Requirements for Inter-Domain
Routing in the Internet"..................................24
5.2 Comments on "Future Domain Routing Requirements".....25
6 Security Considerations...................................28
7 IANA Considerations.......................................28
8 References................................................28
9 Acknowledgments...........................................28
10 Editor's Addresses........................................29
1 Abstract
This note sets requirements for a new routing and addressing
architecture for the Internet. These requirements were
developed by the IRTF's Routing Research Group.
This draft is the product of Group ~B, which is one of the
subgroups in the IRTF-Routing Research Group working on
requirements for routing solutions for the future. This
document sets out requirements that we believe are important
for a future routing architecture and routing protocols. The
IRTF Routing Research Group (RRG) does not endorse this set of
requirements or any other set of requirements as the one and
only set of requirements.
The seemingly simple requirement is to "fix routing and
addressing". However, in order to "fix" it, we also need to
understand how routing and addressing are _actually_ used
today. This is not a straightforward task. Service providers
and network administrators have many different operational and
administrative needs. Quite often, the only tool available to
meet those needs is the routing system and they have proven
amazingly crafty at using that tool in ways that were never
envisioned. Thus, one of the most important steps in
developing these requirements has been to learn what the
operational community really is doing with the routing system,
why they are doing it, and then abstracting those tasks into
requirements.
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [2].
Kastenholz Informational -- Expires 10/2002 3
Inter-domain Routing Requirements March 2002
We believe that we have captured the essential requirements for
one possible future routing and addressing architecture for the
Internet. We do not consider features, functions, or
capabilities not described in this note to be critically
important for a future routing and addressing architecture and
they should be considered optional. A specific architecture
MAY include OR exclude them without conflicting with this note.
There are many IETF documents that define specific terms. We
generally choose not to use these strict, well-crafted,
definitions. They were made with the current architecture and
protocols in mind. A goal of this work is to foster
development of new and different architectures. By using the
"old" terms we may inadvertently limit or constrain avenues of
enquiry and investigation, possibly preventing consideration of
promising architectures.
3 Requirements
This chapter presents the requirements.
The requirements presented in this section are NOT presented in
any order. A later version of this note may order the
requirements in some kind of priority.
3.1 Architecture
The new routing and addressing protocols, data structures, and
algorithms MUST be developed from a clear, well thought out,
documented, architecture.
The new routing and addressing system must have an
architectural specification which describes all of the routing
and addressing elements, their interactions, what functions the
system performs, and how it goes about performing them. The
architectural specification does not go into issues such as
protocol and data structure design.
The Architecture SHOULD be agnostic with regard to specific
algorithms and protocols.
Doing architecture before doing detailed protocol design is
good engineering practice. This allows the architecture to be
reviewed and commented upon, with changes made as necessary,
when it is still easy to do so. Also, by producing an
architecture, the eventual users of the protocols (the
operations community) will have a better understanding of how
the designers of the protocols meant them to be used.
Kastenholz Informational -- Expires 10/2002 4
Inter-domain Routing Requirements March 2002
3.2 Separable Components
The architecture MUST place different functions into separate
components.
Separating functions, capabilities, and so forth, into
individual components, and making each component "stand alone"
is generally considered by system architects to be "A Good
Thing". It allows individual elements of the system to be
designed and tuned to do their jobs "very well". It also
allows for piecemeal replacement and upgrading of elements as
new technologies and algorithms become available.
The architecture MUST have the ability to replace or upgrade
existing components, and to add new ones, without disrupting
the remaining parts of the system. Operators must be able to
roll out these changes and additions incrementally (i.e. no
"flag days"). These abilities are needed to allow the
architecture to evolve as the Internet changes.
The Architecture Specification shall define each of these
components, their jobs, and their interactions.
Some thoughts to consider along these lines are
o Making topology and addressing separate subsystems. This
may allow highly optimized topology management and
discovery without constraining the addressing structure or
physical topology in unacceptable ways.
o Separate "fault detection and healing" from basic
topology. From Mike O'Dell:
"Historically the same machinery is used for both.
While attractive for many reasons, the availability of
exogenous topology information (i.e., the intended
topology) should, it seems, make some tasks easier than
the general case of starting with zero knowledge. It
certainly helps with recovery in the case of constraint
satisfaction. In fact, the intended topology is a
powerful way to state certain kinds of policy.
o Making policy definition and application a separate
subsystem, layered overtop of the others.
The architecture should also separate topology. routing and
addressing from the application that use those components.
This implies that applications such as policy definition,
forwarding, and circuit and tunnel management are separate
subsystems layered overtop of the basic topology, routing, and
addressing systems.
Kastenholz Informational -- Expires 10/2002 5
Inter-domain Routing Requirements March 2002
3.3 Scalable
Scaling is the primary problem facing the routing and
addressing architecture today. This problem must be solved and
it must be solved for the long term.
The Architecture MUST support a large and complex network.
Ideally, it will serve our needs for the next 20 years.
Unfortunately
1. We do not know how big the Internet will grow over that
time, and
2. The architecture developed from these requirements may
change the fundamental structure of the Internet, and
therefore its growth patterns. This change makes it
difficult to predict future growth patterns of the
Internet.
As a result, we can't quantify the requirement in any
meaningful way. Using today's architectural elements as a
mechanism for describing things, we believe that the network
could grow to
1. Tens of thousands of ASes and
2. Tens to hundreds of millions of prefixes during the
lifetime of this architecture.
These sizes are given as a 'flavor' for how we expect the
Internet to grow. We fully believe that any new architecture
may eliminate some current architectural elements and introduce
new ones.
A new routing and addressing architecture designed to a
specific network size would be inappropriate. First, the cost
of routing calculations is based only in part on the number of
AS's or prefixes in the network. The number and locations of
the links in the network is also a significant factor. Second,
past predictions of Internet growth and topology patterns have
proven to be wildly inaccurate so developing an architecture to
a specific size goal would at best be shortsighted.
Therefore we will not make the scaling requirement based on a
specific network size. Instead, the new routing and addressing
architecture should have the ability to constrain the increase
in load (CPU, memory space and bandwidth, and network
bandwidth) on ANY SINGLE ROUTER to be less than these specific
functions:
1. The computational power and memory sizes required to execute
the routing protocol software and to contain the tables must
be less than the growth in hardware capabilities described
by Moore's Law, which has hardware capabilities doubling
every 18 months or so. Other observations indicate that
memory sizes double every 2 years or so.
Kastenholz Informational -- Expires 10/2002 6
Inter-domain Routing Requirements March 2002
2. Network bandwidth and latency are some key constraints on
how fast routing protocol updates can be disseminated (and
therefore how fast the routing system can adapt to changes).
Raw network bandwidth seems to quadruple every 3 years or
so. However, it seems that there are some serious physics
problems in going faster than 40gbits (OC768). We should
not expect raw network link speed to grow much beyond OC768.
In addition, for economic reasons, large swathes of the core
of the Internet will still operate at lower speeds, possibly
as slow as DS3.
Furthermore, in some sections of the Internet even lower
speed links are found. Corporate access links are often T1,
or slower. Low-speed radio links exist. Intra-domain links
may be T1 or fractional-T1 (or slower).
Therefore, the architecture MUST NOT make assumptions about
the bandwidth available.
3. The speeds of high-speed RAMS (SRAMs, used for caches and
the like) are growing, though slowly. Because of their use
in caches and other very specific applications, these RAMs
tend to be small, a few megabits, and the size of these RAMs
is not increasing very rapidly.
On the other hand, the speed of "large" memories (DRAMs) is
increasing even slower than that for the high speed RAMS.
This is because the development of these RAMs is driven by
the PC market, where size is very important, and low speed
can be made up for by better caches.
Memory access rates should not be expected to increase
significantly.
The growth in resources available to any one router will
eventually slow down. It may even stop. Even so, the network
will continue to grow. The routing and addressing architecture
must continue to scale in even this extreme condition. We
cannot continue to add more computing power to routers forever.
Other strategies must be available. Some possible strategies
are hierarchy, abstraction, and aggregation of topology
information..
3.4 Lots of Interconnectivity
The new routing and addressing architecture MUST be able to
cope with a high degree of interconnectivity in the Internet.
That is, there are large numbers of alternate paths and routes
among the various elements. Mechanisms are required to prevent
this interconnectivity (and continued growth in
interconnectivity) from causing tables, compute time, and
routing protocol traffic to grow without bound. The "cost" to
Kastenholz Informational -- Expires 10/2002 7
Inter-domain Routing Requirements March 2002
the routing system of an increase in complexity MUST be limited
in scope; sections of the network that do not see, or do not
care about, the complexity ought not pay the cost of that
complexity.
Over the past several years, the Internet has seen an increase
in interconnectivity. Individual end sites (companies,
customers, etc), ISPs, exchange points, and so on, all are
connecting up to more "other things". Company's multi-home to
multiple ISPs, ISPs peer with more ISPs, and so on. These
connections are made for many reasons, such as getting more
bandwidth, increased reliability and availability, policy, and
so on. However, this increased interconnectivity has a price.
It leads to more scaling problems as it increases the number of
AS paths in the networks.
Any new architecture must assume that the Internet will become
"meshier". It MUST NOT assume, nor can it dictate, certain
patterns or limits on how various elements of the network
interconnect.
Another facet of this requirement is that there may be multiple
valid, loop free, paths available to a destination. When there
are multiple valid, loop free, paths available, all such paths
MUST be available for forwarding traffic.
We wryly note that one of the original design goals of IP was
to support a large, heavily interconnected, network, which
would be highly survivable (such as in the face of a nuclear
war).
3.5 Random Structure
The routing and addressing architecture MUST NOT make any
constraints on or assumptions about the topology or
connectedness of the elements comprising the Internet. The
routing and addressing architecture MUST NOT presume any
particular network structure. The network does not have a
"nice" structure. In the past we used to believe that there
was this nice "backbone/tier-1/tier-2/end-site" sort of
hierarchy. This is not so. Therefore, any new Architecture
must not presume any such structure.
Some have proposed that a geographic addressing scheme be used,
requiring exchange points to be situated within each geographic
'region'. There are many reasons why we believe this to be a
bad approach, but those arguments are irrelevant. The main
issue is that the routing architecture should not presume a
specific network structure.
Kastenholz Informational -- Expires 10/2002 8
Inter-domain Routing Requirements March 2002
3.6 Multi-homing
The Architecture MUST provide multi-homing for all elements of
the Internet. That is, multihoming of hosts, subnetworks, end-
sites, "low-level" ISPs, and backbones (i.e. lots of redundant
interconnections) must be supported. Among the reasons to
multi-home are reliability, load sharing, and performance
tuning.
The term "multihoming" may be interpreted in its broadest sense
-- one "place" has multiple connections or links to another
"place".
The architecture MUST NOT limit the number of alternate paths
to a multi-homed site.
When multi-homing, it MUST be possible to use one, some (more
than one but less than all) or all of the available paths to
the multi-homed site. The multi-homed site must have the
ability to declare which path(s) are used and under what
conditions (for example, one path may be declared "primary" and
the other "backup" and to be used only when the primary fails).
A current problem in the Internet is that multihoming leads to
undue increases in the size of the BGP routing tables. The new
architecture must support multi-homing without causing undue
routing table growth.
3.7 Multi-path
As a corollary to multi-homing, the Architecture MUST allow for
multiple paths from a source to a destination to be active at
the same time. These paths need not have the same attributes.
Policies are to be used to disseminate the attributes and to
classify traffic for the different paths.
There must be a rich "language" for use in specifying the rules
for classifying the traffic and assigning classes of traffic to
different paths (or prohibiting it from certain paths). The
rules for classification should allow traffic to be classified
based on
o IPv6 FlowIDs
o TOS byte
o Source and/or Destination prefixes
o Random selections at some probability
o ...
A mechanism is needed that allows operators to plan and manage
the traffic load on the various paths. To start, this
mechanism can be semi-automatic, or even manual. Eventually it
ought to become fully automatic.
Kastenholz Informational -- Expires 10/2002 9
Inter-domain Routing Requirements March 2002
When multi-path forwarding is used, options must be available
to preserve packet ordering where appropriate (such as for
individual TCP connections).
Past experience with dynamic load-balancing and management over
multiple paths has been bad. Typically, traffic would
oscillate, first all traffic would go over one path, then it
would all be 'migrated' to a different path, and then back
again. Significant research is needed in this area.
3.8 Convergence
The speed of convergence (also called the "stabilization time")
is the time it takes for a router's routing processes to come
up with a new, stable, "solution" (i.e. forwarding information
base) after a change someplace in the network. In effect, what
happens is that the output of the routing calculations
stabilizes -- the Nth iteration of the software produces the
same results as the N-1th iteration.
The speed of convergence is generally considered to be a
function of the number of subnetworks in the network and the
amount of connections between those networks. As either number
grows, the time it takes to converge increases.
In addition, a change can "ripple" back and forth through the
system. One change can go through the system, causing some
other router to change its advertised connectivity, causing a
new change to ripple through. These oscillations can take a
while to work their way out of the network. It is also
possible that these ripples never die out. In this situation
the routing and addressing system is unstable; it never
converges.
Finally, it is more than likely that the routers comprising the
Internet never converge simply because the Internet is so large
and complex. Assume it takes S seconds for the routers to
stabilize on a solution for any one change to the network.
Also assume that changes occur, on average, every C seconds.
Because of the size and complexity of the Internet, C is now
less than S. Therefore, if a change, C1, occurs at time T, the
routing system would stabilize at time T+S, but a new change,
C2, will occur at time T+C, which is before T+S. The system
will start processing the new change before it's done with the
old.
This is not to say that all routers are constantly processing
changes. The effects of changes are like ripples in a pond.
They spread outward from where they occur. Some routers will
be processing just C1, others C2, others both C1 and C2, and
others neither.
Kastenholz Informational -- Expires 10/2002 10
Inter-domain Routing Requirements March 2002
We have two separate scopes over which we can set requirements
with respect to convergence:
1. Single Change
In this requirement a single change of any type (link
addition or deletion, router failure or restart, etc.) is
introduced into a stabilized system. No additional changes
are introduced. The system must restabilize within TBDms.
This requirement is a fairly abstract one as it would be
impossible to test in a real network.
2. System-wide
Defining a single target for maximum convergence time for
the real Internet is absurd. As we mentioned earlier, the
Internet is large enough and diverse enough so that it is
quite likely that new changes are introduced somewhere
before the system fully digests old ones.
So, the first requirement here is that there must be
mechanisms to limit the scope of any one change's visibility
and effects. The number of routers that have to perform
calculations in response to a change is kept small, as is
the settling time.
The second requirement is based on the following assumptions
- the scope of a change's visibility and impact can be
limited. That is, routers within that scope know of
the change and recalculate their tables based on the
change. Routers outside of the scope don't see it at
all.
- Within any scope, S, network changes are constantly
occurring and the average inter-change interval is Tc
seconds.
- There are Rs routers within scope S
- A subset of the destinations known to the routers in
S, Ds, are impacted by a given change.
- We can state that for Z% of the changes, within Y% of
Tc seconds after a change, C, X% of the Rs routers
have their routes to Ds settled to a useful answer
(useful meaning that packets can get to Ds, thought
perhaps not by the optimal path -- this allows some
'hunting' for the optimal solution)
X, Y, Z, ARE TBD
This requirement implies that the scopes can be kept
relatively small in order to minimize Rs and maximize Tc.
Kastenholz Informational -- Expires 10/2002 11
Inter-domain Routing Requirements March 2002
The growth rate of the convergence time MUST NOT be related to
the growth rate of the Internet as a whole. This implies that
the convergence time either
1. Not be a function of basic network elements (such as
prefixes and links/paths), and/or
2. That the Internet be continuously divisible into chunks that
limit the scope and effect of a change, thereby limiting the
number of routers, prefixes, links, and so on involved in
the new calculations.
3.9 Routing System Security
The security of the Internet's routing system is paramount. If
the routing system is compromised or attacked, the entire
Internet can fail. This is unacceptable. Any new Architecture
must be secure.
Architectures by themselves are not secure. It is the
implementation of an architecture; its protocols, algorithms,
and data structures, that are secure. These requirements apply
primarily to the implementation. The architecture MUST provide
the elements that the implementation needs to meet these
security requirements. Also, the architecture MUST NOT prevent
these security requirements from being met.
Security means different things to different people. In order
for this requirement to be useful, we must define what we mean
by security. We do this by identifying the attackers and
threats we wish to protect against. They are:
Masquerading
The system, including its protocols, MUST be secure against
intruders adopting the identity of other known, trusted,
elements of the routing system and then using that position
of trust for carrying out other attacks. Protocols MUST use
cryptographically strong authentication.
DOS Attacks
The architecture and protocols SHOULD be secure against DOS
attacks directed at the routers.
The new architecture and protocols SHOULD provide as much
information as it can to allow administrators to track down
sources of DOS and DDOS attacks.
No Bad Data
Any new architecture and protocols must provide protection
against the introduction of bad, bogus, or misleading, data
by attackers. Of particular importance, an attacker must
not be able to redirect traffic flows, with the intent of
Kastenholz Informational -- Expires 10/2002 12
Inter-domain Routing Requirements March 2002
o Directing legitimate traffic away from a target, causing
a denial-of-service attack by preventing legitimate data
from reaching its destination,
o Directing additional traffic (going to other
destinations which are 'innocent bystanders') to a
target, causing the target to be overloaded, or
o Directing traffic addressed to the target to a place
where the attacker can copy, snoop, alter, or otherwise
affect the traffic.
Topology Hiding
Any new architecture and protocols must provide mechanisms
to allow network owners to hide the details of their
internal topologies, yet maintaining the desired levels of
service connectivity and reachability.
Privacy
By "privacy" we mean privacy of the routing protocol
exchanges between routers. In the past this has not been
considered important for routing protocols.
When the routers are on point-to-point links, with routers
at each end, there is no need to encrypt the routing
protocol traffic; there is no possibility of a third party
intercepting the traffic, and if one of the two routers are
compromised then it doesn't matter. This is not sufficient.
We believe that it is important to have the ability to
protect routing protocol traffic in two cases:
1. When the routers are on a shared network it is possible
that there are hosts on the network that have been
compromised. These hosts could surreptitiously monitor
the protocol traffic.
2. When two routers are exchanging information "at a
distance" (over intervening routers and, possibly,
administrative domains). In this case, the security of
the intervening routers, links, and so on, cannot be
assured. Thus, the ability to encrypt this traffic is
important.
Therefore, we believe that the option to encrypt routing
protocol traffic is required.
Data Consistency
A router should be able to detect and recover from any data
that is received from other routers which is inconsistent.
That is, it MUST NOT be possible for data from multiple
routers, none of which is malicious, to "break" another
router.
Where security mechanisms are provided, they must use methods
that are considered to be cryptographically secure (e.g. using
cryptographically strong encryption and signatures -- no clear
text passwords!).
Kastenholz Informational -- Expires 10/2002 13
Inter-domain Routing Requirements March 2002
Use of security features SHOULD NOT be optional (except as
required above). This may be "social engineering" on our part,
but we believe it to be necessary. If a security feature is
optional, the implementation of the feature MUST default to the
"secure" setting.
3.10 End Host Security
The Architecture MUST NOT prevent individual host-to-host
communications sessions from being secured (i.e. it cannot
interfere with things like IPSEC).
3.11 Rich Policy
Before setting out Policy requirements, we need to define the
term. Like "security", "policy" means many things to many
people. For our purposes, we define policy as
Policy is the set of administrative influences that alter
the path determination and next-hop selection procedures of
the routing software.
The main motivators for influencing path and next-hop selection
seem to be transit rules, business decisions and load
management.
The new Architecture must support rich policy mechanisms.
Furthermore, the policy definition and dissemination
mechanismsshould be separated from the network topology and
connectivity dissemination mechanisms. Policy provides input
to and controls the generation of the forwarding table and the
abstraction, filtering, aggregation, and dissemination of
topology information.
Note that if the architecture is properly divided into
subsystems then at a later time, new policy subsystems that
include new features and capabilities could be developed and
installed as needed.
We divide the general area of policy into two sub-categories,
routing information and traffic control. Routing Information
Policies control what routing information is disseminated or
accepted, how it is disseminated, and how routers determine
paths and next-hops from the received information. Traffic
Control Policies determine how traffic is classified and
assigned to routes.
3.11.1 Routing Information Policies
There must be mechanisms to allow network administrators,
operators, and designers to control receipt and dissemination
Kastenholz Informational -- Expires 10/2002 14
Inter-domain Routing Requirements March 2002
of routing information. These controls include, but are not
limited to:
- Selecting to which others routing information will be
transmitted.
- Specifying the "granularity" and type of transmitted
information. The length of IPv4 prefixes is an example of
"granularity".
- Selection and filtering of topology and service information
that is transmitted. This gives different 'views' of
internal structure and topology to different peers.
- Selecting the level of security and authenticity for
transmitted information
- Being able to cause the level of detail that is visible for
some portion of the network to reduce the farther you get
from that part of the network.
- Selecting from whom routing information will be accepted.
This control should be "provisional" in the sense of "accept
routes from "foo" only if there are no others available".
- Accepting or rejecting routing information based on the path
the information traveled (using the current system as an
example, this would be filtering routes based on an AS
appearing anywhere in the AS path). This control should be
"provisional" in the sense of "accept routes that traverse
"foo" only if there are no others available".
- Selecting the desired level of "granularity" for received
routing information (this would include, but is not limited
to, things similar in nature to the prefix-length filters
widely used in the current routing and addressing system).
- Selecting the level of security and authenticity of received
information in order for that information to be accepted.
- Determining the treatment of received routing information
based on attributes supplied with the information.
- Applying attributes to routing information that is to be
transmitted and then determining treatment of information
(eg, sending it "here" but not "there") based on those tags.
- Selection and filtering of topology and service information
that is received.
3.11.2 Traffic Control Policies
The architecture SHOULD provide mechanisms that allow network
operators to manage and control the flow of traffic. The
traffic controls should include, but are not limited to:
- The ability to detect and eliminate congestion points in the
network (by re-directing traffic around those points) .
- The ability to develop multiple paths through the network
with different attributes and then assign traffic to those
paths based on some discriminators within the packets
(discriminators include, but are not limited to, IP Addresses
or prefixes, DSCP values, and MPLS labels) .
Kastenholz Informational -- Expires 10/2002 15
Inter-domain Routing Requirements March 2002
- The ability to to find and use multiple, equivalent, paths
through the network (i.e. they would have the "same"
attributes) and allocate traffic across the paths.
- The ability to accept or refuse traffic based on some traffic
classification (providing, in effect, transit policies).
Traffic classification must at least include the source and
destination IP addresses (prefixes) and the DSCP value. Other
fields may be supported, such as
o Protocol and port based functions,
o TOS/QOS tuple (such as ports)
o Per-host operations (i.e. /32s for IPv4 and /128s for
IPv6),
o Traffic matrices (e.g., traffic from prefix X and to
prefix Y).
3.12 Incremental Deployment
The reality of the Internet is that there can be no Internet-
wide cutover from one architecture and protocol to another.
This means that any new architecture and protocol MUST be
incrementally deployable; ISPs must be able to set up small
sections of the new architecture, check it out, and then slowly
grow the sections. Eventually, these sections will "touch" and
"squeeze out" the old architecture.
The protocols that implement the Architecture MUST be able to
interoperate at "production levels" with currently existing
routing protocols. Furthermore, the protocol specifications
MUST define how the interoperability is done.
We also believe that sections of the Internet will never
convert over to the new architecture. Thus, it is important
that the new architecture and its protocols be able to
interoperate with "old architecture" regions of the network
indefinitely.
The architecture's addressing system MUST NOT force existing
address allocations to be redone: no renumbering!
3.13 Mobility
There are two kinds of mobility; host mobility and network
mobility. Host mobility is when an individual host moves from
where it was to where it is. Network mobility is when an
entire network (or subnetwork) moves.
The architecture MUST support network level mobility.
Kastenholz Informational -- Expires 10/2002 16
Inter-domain Routing Requirements March 2002
3.14 Address Portability
One of the big "hot items" in the current Internet political
climate is portability of IP addresses (both V4 and V6). The
short explanation is that people do not like to renumber and do
not trust automated renumbering tools.
The Architecture MUST provide complete address portability.
3.15 Multi-Protocol
The Internet is expected to be "multi-protocol" for at least
the next several years. IPv4 and IPv6 will co-exist in many
different ways during a transition period. The architecture
MUST be able to handle both IPv4 and IPv6 addresses.
Furthermore, protocols that supplant IPv4 and IPv6 may be
developed and deployed during the lifetime of the architecture.
The architecture MUST be flexible and extensible enough to
handle new protocols as they arise.
Furthermore, the architecture MUST NOT assume any given
relationships between a topological element's IPv4 address and
its IPv6 address. The architecture MUST NOT assume that all
topological elements have IPv4 addresses/prefixes, nor can it
assume that they have IPv6 addresses/prefixes.
The architecture SHOULD allow different paths to the same
destination to be used for different protocols, even if all
paths can carry all protocols.
In addition to the addressing technology, the architecture need
not be restricted to only packet based
multiplexing/demultiplexing technology (such as IP); support
for other multiplexing/ demultiplexing technologies MAY be
added.
3.16 Abstraction
The architecture must provide mechanisms to for network
designers and operators to
o Group elements together for administrative control
purposes,
o Hide the internal structure and topology of those
groupings for administrative and security reasons,
o Limit the amount of topology information that is exported
from the groupings in order to control the load placed on
external routers,
o Define rules for traffic transiting or terminating in the
grouping.
The architecture MUST allow the current Autonomous System
structure to be mapped into any new abstraction schemes.
Kastenholz Informational -- Expires 10/2002 17
Inter-domain Routing Requirements March 2002
Mapping mechanisms, algorithms, and techniques MUST be
specified.
3.17 Simplicity
The architecture MUST be simple enough so that Radia Perlman
can explain all the important concepts in less than an hour.
The requirement is that the routing architecture be kept as
simple as possible. This requires careful evaluation of
possible features and functions with a merciless weeding out of
those that "might be nice".
By keeping the architecture simple, the protocols and software
used to implement the architecture are simpler. This
simplicity in turn leads to:
1. Faster implementation of the protocols. If there are fewer
bells and whistles, then there are fewer things that need to
be implemented.
2. More reliable implementations. With fewer components, there
is less code, reducing bug counts, and fewer interactions
between components that could lead to unforeseen and
incorrect behavior.
3.18 Robustness
The architecture, and the protocols implementing it, should be
robust. Robustness comes in many different flavors. Some
considerations with regard to robustness include (but are not
limited to):
o Defective (even malicious) trusted routers.
o Network failures. Whenever possible, valid alternate
paths are to be found and used.
o Failures must be localized. That is, the architecture
must limit the "spread" of any adverse effects of a
misconfiguration or failure. Badness must not spread.
Of course, the general robustness principle of being liberal in
what's accepted and conservative in what's sent must also be
applied.
EDITOR'S NOTE:
Some of the contributors to this note have argued that
robustness is an aspect of Security. I have exercised
editor's discretion by making it a separate section.
The reason for this is that to too many people
"security" means "protection from breakins" and
"authenticating and encrypting data". This requirement
goes beyond those views.
Kastenholz Informational -- Expires 10/2002 18
Inter-domain Routing Requirements March 2002
3.19 Media Independence
While it is an article of faith that IP operates over a wide
variety of media (such as Ethernet, X.25, ATM, and so on), IP
routing must take an agnostic view towards any "routing" or
"topology" services that are offered by the medium over which
IP is operating. That is, the new architecture MUST NOT be
designed to integrate with any media-specific topology
management or routing scheme.
The routing architecture must assume, and must work over, the
simplest possible media.
The routing and addressing architecture can certainly make use
of lower-layer information and services, when and where
available, and to the extent that IP routing wishes.
3.20 Stand-alone
The routing architecture and protocols MUST NOT rely on other
components of the Internet (such as DNS) for their correct
operation. Routing is the fundamental process by which data
"finds its way around the Internet" and most, if not all, of
those other components rely on routing to properly forward
their data. Thus, Routing cannot rely on any Internet systems,
services or capabilities that in turn rely on Routing. If it
did, a dependency loop would result.
3.21 Safety of Configuration
The architecture, protocols, and standard implementation
defaults must be such that a router installed "out of the box"
with no configuration/etc by the operators will not cause "bad
things" to happen to the rest of the routing system (no dialup
customers advertising routes to 18/8!)
3.22 Renumbering
The routing system MUST allow topological entities to be
renumbered.
3.23 Multi-prefix
The architecture MUST allow topological entities to have
multiple prefixes (or the equivalent under the new
architecture).
3.24 Cooperative Anarchy
As RFC1726[5] said:
Kastenholz Informational -- Expires 10/2002 19
Inter-domain Routing Requirements March 2002
A major contributor to the Internet's success is the fact
that there is no single, centralized, point of control or
promulgator of policy for the entire network. This allows
individual constituents of the network to tailor their own
networks, environments, and policies to suit their own needs.
The individual constituents must cooperate only to the degree
necessary to ensure that they interoperate.
This decentralization, called "cooperative anarchy", is still a
key feature of the Internet today. The new routing
architecture MUST retain this feature. There can be no
centralized point of control or promulgator of policy for the
entire Internet.
3.25 Network Layer Protocols and Forwarding Model
For the purposes of backward compatibility, any new routing and
addressing architecture and protocols MUST work with IPv4 and
IPv6 using the traditional "hop by hop" forwarding and packet-
based multiplex/demultiplex models. However, the architecture
need not be restricted to these models. Additional forwarding
and multiplex/demultiplex models MAY be added.
3.26 Routing Algorithm
The architecture SHOULD NOT require a particular routing
algorithm family. That is to say, the architecture should be
agnostic with regard to using link-state, distance-vector, or
path-vector routing algorithms.
3.27 Positive Benefit
Finally, the architecture must show benefits, in terms of
increased stability, decreased operational costs, and increased
functionality and lifetime over the current schemes. This
benefit must remain even after the inevitable costs of
developing and debugging the new protocols, enduring the
inevitable instabilities as things get shaken out, and so on.
3.28 Administrative Entities and the IGP/EGP Split
We explicitly recognize that the Internet consists of resources
under control of multiple administrative entities. Each entity
MUST be able to manage its own portion of the Internet as it
sees fit. Moreover, the constraints that can be imposed on
routing and addressing on the portion of the Internet under the
control of one administration may not be feasibly extended to
cover multiple administrations. Therefore, we recognize a
natural and inevitable split between routing and addressing
that is under a single administrative control and routing and
addressing that involves multiple administrative entities.
Moreover, while there may be multiple administrative
Kastenholz Informational -- Expires 10/2002 20
Inter-domain Routing Requirements March 2002
authorities, the administrative authority boundaries may be
complex and overlapping, rather than being a strict hierarchy.
Furthermore, there may be multiple levels of administration,
each with its own level of policy and control. For example, a
large network might have "continental-level" administrations
covering its European and Asian operations, respectively.
There would also be that network's "inter-continental"
administration covering the Europe-to-Asia links. Finally,
there would be the "Internet" level in the administrative
structure (analogous to the "exterior" concept in the current
routing architecture).
Thus, we believe that the administrative structure of the
Internet must be extensible to many levels (more than the two
provided by the current IGP/EGP split). The interior/exterior
property is not absolute. The interior/exterior property of
any point in the network is relative; a point on the network is
interior with respect to some points on the network and
exterior with respect to others.
Administrative entities may not trust each other; some may be
almost actively hostile towards each other. The architecture
MUST accommodate these models. Furthermore, the architecture
MUST NOT require any particular level of trust among
administrative entities.
4 Non-Requirements
The following are not required or are non-goals. This should
not be taken to mean that these issues must not be addressed by
a new architecture. Rather, addressing these issues or not is
purely a matter for the architects.
4.1 Forwarding Table Optimization
We believe that it is not necessary for the architecture to
minimize the size of the forwarding tables (FIBS). Current
memory sizes, speeds, and prices, along with processor and ASIC
capabilities allow forwarding tables to be very large, O(E6),
and fast (100M lookups/second) tables to be built with little
difficulty.
4.2 Traffic Engineering
Traffic Engineering is one of those terms that has become
terribly overloaded. If you ask N people what traffic
engineering is, you get something like N! disjoint answers.
Therefore, we elect not to require "traffic engineering", per
se. Instead, we have endeavored to determine what the ultimate
Kastenholz Informational -- Expires 10/2002 21
Inter-domain Routing Requirements March 2002
intent is when operators "traffic engineer" their networks and
then make those capabilities an inherent part of the system.
4.3 Multicast
The new architecture is not designed explicitly to be an inter-
domain multicast routing architecture. However, given the
notable lack of a viable, robust, and widely deployed inter-
domain multicast routing architecture, the architecture should
not hinder the development and deployment of inter-domain
multicast routing without adverse effect on meeting the other
requirements.
We do note however that one respected network sage has said
(roughly)
When you see a bunch of engineers standing around
congratulating themselves for solving some particularly
ugly problem in networking, go up to them, whisper
"multicast", jump back, and watch the fun begin...
4.4 QOS
The Architecture concerns itself primarily with disseminating
network topology information so that routers may select paths
to destinations and build appropriate forwarding tables. QOS
is not a part of this function and we make no requirements with
respect to QOS.
However, QOS is an area of great and evolving interest. It is
reasonable to expect that in the not too distant future,
sophisticated QOS facilities will be deployed in the Internet.
Any new architecture and protocols should be developed with an
eye towards these future evolutions. Extensibility mechanisms,
allowing future QOS routing and signaling protocols to "piggy-
back" on top of the basic routing system are desired.
We do require the ability to assign attributes to entities and
then do path generation and selection based on those
attributes. Some may call this QOS.
4.5 IP Prefix Aggregation
There is no specific requirement that CIDR-style IP Prefix
aggregation be done by the new architecture. Address
allocation policies, societal pressure, and the random growth
and structure of the Internet have all conspired to make prefix
aggregation extraordinarily difficult, if not impossible. This
means that large numbers of prefixes will be sloshing about in
the routing system and that forwarding tables will grow quite
big. This is a cost that we believe must be borne.
Kastenholz Informational -- Expires 10/2002 22
Inter-domain Routing Requirements March 2002
Nothing in this non-requirement should be interpreted as saying
that prefix aggregation is explicitly prohibited. CIDR-style
IP Prefix aggregation might be used as a mechanism to meet
other requirements, such as scaling.
4.6 Perfect Safety
Making the system impossible to misconfigure is, we believe,
not required. The checking, constraints, and controls
necessary to achieve this could, we believe, prevent operators
from performing necessary tasks in the face of unforeseen
circumstances.
However, safety is always a "good thing", and any results from
research in this area should certainly be taken into
consideration and, where practical, incorporated into the new
routing architecture.
4.7 Dynamic Load Balancing
Past history has shown that using the routing system to perform
highly dynamic load balancing among multiple more-or-less-equal
paths usually ends up causing all kinds of instability, etc, in
the network. Thus, we do not require such a capability.
However, this is an area that is ripe for additional research,
and some believe that the capability will be necessary in the
future. Thus, the architecture and protocols should be
"malleable" enough to allow development and deployment of
dynamic load balancing capabilities, should we ever figure out
how to do it.
4.8 Renumbering of hosts and routers
We believe that the routing system is not required to "do
renumbering" of hosts and routers. That's an IP issue.
Of course, the routing and addressing architecture must be able
to deal with renumbering when it happens.
4.9 Host Mobility
In the Internet Architecture, host-mobility is handled on a
per-host basis by a dedicated, Mobile-IP protocol [6]. Traffic
destined for a mobile-host is explicitly forwarded by dedicated
relay agents. Mobile-IP [6] adequately solves the host-
mobility problem and we do not see a need for any additional
requirements in this area. Of course, the new architecture
MUST NOT impede or conflict with Mobile-IP.
Kastenholz Informational -- Expires 10/2002 23
Inter-domain Routing Requirements March 2002
4.10 Clean Slate
For the purposes of development of the architecture, we assume
that there is a 'clean slate'. Unless specified in section 3,
we have no explicit requirements that elements, concepts or
mechanisms of the current routing architecture are carried
forward into the new one.
5 Discussion of other Inter-Domain Routing Requirements documents
Recently, two other Internet Drafts have been published that
set out some requirements for a new Inter-Domain routing
architecture. These drafts are "Future Domain Routing
Requirements" by Elwyn Davies, et al [3], and "Architectural
Requirements for Inter-Domain Routing in the Internet" by Geoff
Huston [4].
Rather than use these documents, we decided to develop our own
set of requirements for a future inter-domain routing
architecture. The reasons are
1. There are requirements in [3] and [4] with which we do not
agree, plus we have additional requirements that are not
in those documents.
2. We do not agree with the methodology in [3] and [4]. In
particular, [3]'s list of requirements seems to us like an
exhaustive list of things, falling dangerously close to
the "My Layer MUST solve all of networking's problems"
disease. One of the hardest parts of setting requirements
is to determine what problems will NOT be solved.
[3] and [4] each provide excellent historical background
information. Rather than repeat the information here, readers
are encouraged to consult those documents.
Discussions and commentary on each internet-draft follow.
5.1 Comments on "Architectural Requirements for Inter-Domain
Routing in the Internet"
The IAB have developed an internet-draft titled "Architectural
Requirements for Inter-Domain Routing in the Internet" [4].
Rather than using [4], we have produced our own document.
A good part of [4] is a detailed explanation of the current
problems in routing and addressing. This work is valuable. We
chose not to replicate it in this note.
The main reason we decided not to use [4] is that it is too
rooted in the current BGP/AS model. We believe that the
Kastenholz Informational -- Expires 10/2002 24
Inter-domain Routing Requirements March 2002
charter for the Routing Research Group is to work on longer-
term futures, including the possibility of replacing that
model. We wish to develop our requirements in a forward-
looking manner and using requirements rooted in the old model
may cause us to unwittingly constrain our thinking.
[4] Enumerates four requirements for a new routing
architecture. These requirements are fairly broad and loose.
They are:
Scalability
We agree. The new architecture must be scalable. We have
included a requirement for scalability.
Stability and Predictability
Yes, the routing and addressing architecture should be
stable and predictable. However, we are not sure that
overall this is possible.
Convergence
Fast convergence would be nice. However, the size and
complexity of the Internet are such that we do not believe
that the entire net can ever converge. Changes with global
impact will always be happening and their effects will be
constantly propagating through the network. We expect that
any routing system will, at best, be able to converge
incrementally. That is, in any one place, convergence with
respect to one change can occur, but before the entire net
converges, another change will occur, requiring a new set
of calculations and a "new" convergence.
We prefer to believe that convergence at any single point
and after any single change must occur quickly. Also,
since we expect that the network will constantly by (re-
converging, so the load of those attempts must be minimal.
Routing Overhead
Routing overhead should be minimized. True.
5.2 Comments on "Future Domain Routing Requirements"
A separate group is developing a document titled "Future Domain
Routing Requirements" [3].
Rather than using [3], we have produced our own document. As
with [4] we believe that this document is too rooted in the
current BGP/AS model, which is not a useful context for
developing long-term future architectures.
We have a number of observations on [3], in no particular
order:
Kastenholz Informational -- Expires 10/2002 25
Inter-domain Routing Requirements March 2002
1. The introductory/historical/background is fine. In fact,
that material should be considered "required reading" to
understand the background and current problems of Internet
Routing. We commend the authors of [3] for putting this
material together.
2. The "goals" section (1.2) seems to be heavily oriented to
specific issues and tasks that network designers and
administrators face today. Our charter calls for us to
consider the very long term. Thus, it is hard to say what
specific tasks the operations community needs to perform.
Therefore, we prefer to take a broader view of what
routing should do and have written our document
accordingly.
3. [3] Seems still wedded to the old BGP/AS model of doing
inter-domain routing. That may well be an adequate model.
However, the Routing Research Group's charter is to
consider and develop long-term future directions in
routing. We prefer to develop our own document, trying to
avoid falling into the "traps" of the past.
4. The document seems to be an exhaustive wish list of
things. The hardest part of doing requirements is to
figure out what not to require. Coincident with that
observation, there were a couple of "would be nice" and
"might be needed" sorts of things. The fear is that they
fell into the trap of "All problems must be solved in our
layer", which leads to very poor architectures and
designs.
5. They call for "support for NATs and other mid-boxes". If
the Routing and Addressing architecture is "right" then
there is no need for them, at least as far as Routing and
Addressing are concerned.
Also, we are confused as to what "support for NATs..."
actually means.
6. The authors of [3] talk a fair bit about some low-level
things they want. Our opinion is that we are looking "too
far out" to talk about detailed, low-level requirements.
We don't know what the operators of 2007 will want.
Besides solving the basic problem of getting topological
and addressing information "around", we need to think more
about how to keep the architecture (and design and
implementation) flexible and open so that in 2006 when
someone says "We need a gonkulator!" we can say "Easy, it
gets plugged in here..."
7. Multicast/Anycast
We do not believe that multicast routing is a part of our
charter.
Kastenholz Informational -- Expires 10/2002 26
Inter-domain Routing Requirements March 2002
Anycast is a fairly nebulous technology. To require that
routing "support" it at this stage in its development is
premature. To require that routing support anycast means,
in effect, that we first define what it is.
8. Support for renumbering
We take this to mean either that
o The routing-and-addressing system actually does the
renumbering, to which we reply "Is this really
something for routing to do?", or
o The routing-and-addressing system must continue to
operate when elements of the network are renumbered.
We have a requirement for this
9. Statistics support
This seems to us to be a low-level protocol issue. Yes
the protocol needs a MIB. But we do not believe that this
is an architectural or requirements issue.
This also indicates to us that [3] is more concerned with
lower-level protocol and implementation issues rather than
taking the proverbial "step back" to look at "the big
picture".
10. There were some comments about convergence that
seemed to indicate that the authors of [3] are thinking of
global convergence. We have observed that global
convergence is probably not doable anymore. We believe
that "permanent change" is the order of the day...
11. One of their open-issues indicates that the
authors of [3] are thinking about whether the EGP/IGP
split is good or not. It's good they are thinking about
it. It's bad that they consider it open. We consider
this split to be A Bad Thing -- there should be no such
split in the architecture.
12. One example of the too fine a level of detail they
are getting into is that in 7.2.2 they talk about having a
number of specific path attributes. But, if say in 2007
we discover a need for a gonkulation attribute, it's not
in the list in [3]. Perhaps we are taking their document
too literally, but someone taking [3] and designing to it
would maybe make attributes TLV's and leave it at that.
They wouldn't consider the effects of unconsidered new
attributes. We prefer to think of things in the reverse
order:
We know we need attributes, but we don't know what they
all are. Therefore the attribute mechanism must be
flexible and allow growth in weird new directions
without causing problems on the rest of the system --
so how do we do that.
Kastenholz Informational -- Expires 10/2002 27
Inter-domain Routing Requirements March 2002
6 Security Considerations
We address security issues in the individual requirements. We
do require that the Architecture and protocols developed
against this set of requirements be "secure".
7 IANA Considerations
This document is a set of requirements from which a new routing
and addressing architecture will be developed. From that
architecture, a new protocol, or set of protocols, may be
developed.
While this note poses no new tasks for IANA, the architecture
and protocols developed from this document probably will have
issues to be dealt with by IANA.
8 References
[1] Bradner, S., "The Internet Standards Process û Revision 3",
BCP9, RFC2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14 RFC 2119, March 1997.
[3] Davies, E., et al, "Future Domain Routing Requirements",
draft-davies-fdr-reqs-01.txt, July 2001, Work In Progress.
[4] Huston, G., "Architectural Requirements for Inter-Domain
Routing in the Internet" draft-iab-bgparch-01.txt, May
2001, Work In Progress.
[5] Partridge, C., and F. Kastenholz, "Technical Criteria for
Choosing IP The Next Generation (IPng)", RFC 1726. December
1994.
[6] Perkins, C., "IP Mobility Support." RFC2002, October 1996.
9 Acknowledgments
This originated in the IRTF Routing Research GroupÆs sub-group
on Inter-domain routing requirements. The members of the group
are
Abha Ahuja Danny McPherson
J. Noel Chiappa David Meyer
Sean Doran Mike OÆDell
JJ Garcia-Luna-Aceves Andrew Partan
Susan Hares Radia Perlman
Kastenholz Informational -- Expires 10/2002 28
Inter-domain Routing Requirements March 2002
Geoff Huston Yakov Rehkter
Frank Kastenholz John Scudder
Dave Katz Curtis Villamizar
Tony Li Dave Ward
We also appreciate the comments and review received from Ran
Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery
Haas, Dmitri Krioukov, Russ White, and Alex Zinin. Special
thanks to Yakov Rehkter for contributing text and to Noel
Chiappa.
10 Editor's Addresses
Frank Kastenholz
Unisphere Networks
10 Technology Park
Westford, MA, 01886, USA
Phone: +1 978 589 0286
Email: fkastenholz@unispherenetworks.com
Kastenholz Informational -- Expires 10/2002 29
Inter-domain Routing Requirements March 2002
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Kastenholz Informational -- Expires 10/2002 30
Datatracker
Report a datatracker bug
draft-irtf-routing-reqs-groupa-00
None
| Document | Document type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Author |
Frank Kastenholz
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats |