Hi all,
I'm attaching a further update to the design goals document to reflect changes
that Hannu requested and some other text that Sampo motivated.
As draft submission is in blackout right now, I'm attaching the document and a
set of diffs.
As this is still churning significantly, I'd like to extend the last call until
a week after this note.
Thanks,
Tony
Title: wdiff draft-irtf-design-goals-03.txt draft-irtf-design-goals-04.txt
Internet Research Task Force T. Li, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Informational October 21, 2010
Expires: April 24, 2011
Design Goals for Scalable Internet Routing
draft-irtf-rrg-design-goals-03
draft-irtf-rrg-design-goals-04
Abstract
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, mobility, multi-
homing, and inter-domain traffic engineering. The RRG is designing
an alternate architecture to meet these challenges. This document
consists of a prioritized list of design goals for the architecture.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2011.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Design Goals Collected from Past . . . . . . . . . . . 3
3. Design Goals for A New Routing Architecture . . . . . . . . . . 4
3.1. Improved routing scalability . . . . . . . . . . . . . . . 4
3.2. Scalable support for traffic engineering . . . . . . . . . 4
3.3. Scalable support for multi-homing . . . . . . . . . . . . . 4
3.4. Scalable support for mobility . . . . . . . . . . . . . . . 4
3.5. Simplified renumbering . . . . . . . . . . . . . . . . . . 5
3.6. Decoupling location and identification . . . . . . . . . . 5
3.7. First-class elements . . . . . . . . . . . Modularity, composability, and seamlessness . . . . . . . . 6
3.8. Routing quality . . . . . . . . . . . . . . . . . . . . . . 6
3.9. Routing security . . . . . . . . . . . . . . . . . . . . . 6 7
3.10. Deployability . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in inter-domain scalability,
mobility, multi-
homing, multi-homing, and inter-domain traffic engineering. The
Routing Research Group aims to design an alternate architecture to
meet these challenges. This document presents a prioritized list of
design goals for the architecture.
These goals should be taken as guidelines for evaluating possible
architectural solutions. The expectation is that these goals will be
applied with good judgment.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Priorities
Each design goal in this document has been assigned a priority, which
is one of 'required', 'strongly desired', 'desired', and 'optional'.
Required: The solution is REQUIRED to support this goal.
Strongly desired: The solution SHOULD support this goal unless there
exist compelling reasons showing it is unachievable,
extremely inefficient, or impractical.
Desired: The solution SHOULD support this goal.
Optional: The solution MAY support this goal.
It is possible that two design goals at the same priority level may
be found to be in conflict with one another. If and when this
happens, one of them may be subsequently re-prioritized to have the
two in different priority levels.
2. General Design Goals Collected from Past
RFC 1958 [RFC1958] provides an excellent list of the original
architectural principles of the Internet. We incorporate them here
by reference, as part of our desired design goals.
3. Design Goals for A New Routing Architecture
3.1. Improved routing scalability
Long experience with inter-domain routing has shown us that the
global BGP routing table is continuing to grow rapidly [BGPGrowth].
Carrying this large amount of state in the control plane inter-domain routing
protocols is expensive and places undue cost burdens on network
participants that do not necessarily get value from the increases in
the routing table size. Thus, the first required goal is to provide
significant improvement to the scalability of the control plane. inter-domain
routing subsystem. It is strongly desired to make the control plane routing
subsystem scale independently from the growth of the Internet user
population. If a solution includes support for alternative routes to
support faster convergence, the alternative routes should also factor
into control plane routing subsystem scalability.
3.2. Scalable support for traffic engineering
Traffic engineering is the capability of directing traffic along
paths other than those that would be computed by normal IGP/EGP
routing. Inter-domain traffic engineering today is frequently
accomplished by injecting more-specific prefixes into the global
routing table, which results in a negative impact on routing
scalability. A scalable solution for inter-domain traffic
engineering is strongly desired.
3.3. Scalable support for multi-homing
Multi-homing is the capability of an organization to be connected to
the Internet via more than one other organization. The current
mechanism for supporting multi-homing is to let the organization
advertise one or multiple prefixes into the global routing system,
again resulting in a negative impact on routing scalability. More
scalable solutions for multi-homing are strongly desired.
3.4. Scalable support for mobility
Mobility is the capability of a host, network, or organization to
change its topological connectivity with respect to the remainder of
the Internet, while continuing to receive packets from the Internet.
Existing mechanisms to provide mobility support include (1)
renumbering the mobile entity as it changes its topological
attachment point(s) to the Internet; (2) renumbering and creating a
tunnel from the entity's new topological location back to its
original location; and (3) letting the mobile entity announce its
prefixes from its new attachment point(s). The first approach alone
is considered unsatisfactory as the change of IP address may break
existing transport or higher level connections for those protocols
using IP addresses as identifiers. The second requires the
deployment of a 'home agent' to keep track of the mobile entity's
current location and adds overhead to the routers involved, as well
as adding stretch to the path of inbound packet. Neither of the
first two approaches impacts the routing scalability. The third
approach, however, injects dynamic updates into the global routing
system as the mobile entity moves. Mechanisms that help to provide
more efficient and scalable mobility support are desired, especially
when they can be coupled with security, especially privacy, and
support topological changes at a high-rate. Ideally, such mechanisms
should completely decouple mobility from routing.
3.5. Simplified renumbering
Today many of the end-sites receive their IP address assignments from
their Internet Service Providers (ISP). When such a site changes
providers, for routing to scale, the site must renumber into a new
address block assigned by its new ISP. This can be costly, error-
prone and painful. Automated tools, once developed, are expected to
provide significant help in reducing the renumbering pain. It is not
expected that renumbering will be wholly automated, as some manual
reconfiguration is likely to be necessary for changing the last-mile
link. However, the overall cost of this transition should be
drastically lowered.
In addition to being configured into hosts and routers, where
automated renumbering tools can help, IP addresses are also often
used for other purposes such as access control lists. They are also
sometimes hard-coded into applications used in environments where
failure of the DNS could be catastrophic (e.g. certain remote
monitoring applications). Although renumbering may be considered a
mild inconvenience for some sites, and guidelines have been developed
for renumbering a network without a flag day [RFC4192], for others,
the necessary changes are sufficiently difficult so as to make
renumbering effectively impossible. It is strongly desired that a
new architecture allow end-sites to renumber their network with
significantly less disruption, or, if renumbering can be eliminated,
the new architecture must demonstrate how the topology can be
economically morphed to fit the addressing.
3.6. Decoupling location and identification
Numerous sources have noted that an IPv4 address embodies both host
attachment point information and identification information. This
overloading has caused numerous semantic collisions that have limited
the flexibility of the Internet architecture. Therefore, it is
desired that a solution separate the host location information
namespace from the identification namespace.
Caution must be taken here to clearly distinguish the decoupling of
host location and identification information, and the decoupling of
end-site addresses from globally routable prefixes; the latter has
been proposed as one of the approaches to a scalable routing
architecture. Solutions to both problems, i.e. (1) the decoupling of
host location and identification information and (2) a scalable
global routing system (whose solution may, or may not, depend on the
second decoupling) are required and it is required that their
solutions are compatible with each other.
3.7. First-class elements
In the branch of computer science that is devoted to programming
language design, there is an explicit notion of a "first-class
element" in the design. These are language elements that are fully
integrated Modularity, composability, and seamlessness
A new routing architecure should be modular: it should subdivide into the language, with clear, consistent, logical
multiple composable, extensible, and orthogonal subsystems. The
intefaces between modules should be natural semantics and obvious interactions with all of seamless, without
special cases or restrictions. Similarly, the other
elements primitives and
abstractions in the language [FirstClass].
For our architectural purposes, it is strongly desired architecture should be suitably general, with
operations equally applicable to abstractions and concrete entities,
and without deleterious side-effects that the
primary mechanisms might hinger communication
between endpoints in the Internet.
As an architecture all be first-class elements.
More specifically, example, if a tunneling mechanism is tunnelling was used as a part of a solution, it
should be completely transparent to provide both of the endpoints, without
requiring new mechanisms for determining the correct maximum datagram
size.
The resulting network layering, should always fully approximate the current
best-effort Internet connectivity virtualization, or a connection-
oriented mode, then model, and it is strongly desired should also
anticipate changes to that the tunneling
mechanism be a first-class element model e.g. for multiple differentiated
and/or guaranteed upon levels of service in the architecture. This
requires that the issues of path MTU, reachability, and recursion be
addressed. future.
3.8. Routing quality
The routing subsystem is responsible for computing a path from any
point on the Internet to any other point in the Internet. The
quality of the routes that are computed can be measured by a number
of metrics, such as convergence, stability, and stretch.
The stretch factor is the maximum ratio between the length of a
route computed by the scheme and that of a shortest path
connecting the same pair of nodes. [JACM89]
A solution is strongly desired to provide routing quality equivalent
to what is available today or better.
3.9. Routing security
Currently, the routing subsystem is secured through a number of
protocol specific mechanisms of varying strength and applicability.
Any new architecture is required to provide at least the same level
of security as is deployed as of when the new architecture is
deployed.
3.10. Deployability
Since solutions that are not deployable are simply academic
exercises, solutions are required to be deployable from a technical
perspective. Furthermore, given the extensive deployed base of
today's Internet, a solution is required to be incrementally
deployable. This implies that a solution must continue to support
the functionality provided by today's routing subsystem. This
includes but is not limited to the ability to control routing based
on policy.
4. IANA Considerations
This memo includes no requests to IANA.
5. Security Considerations
All solutions are required to provide security that is at least as
strong as the existing Internet routing and addressing architecture.
6. References
6.1. Normative References
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
6.2. Informative References
[BGPGrowth]
Huston, G., "BGP Routing Table Analysis Reports",
<http://bgp.potaroo.net/>.
[FirstClass]
"First-class object",
<http://en.wikipedia.org/wiki/First-class_object>.
[JACM89] Peleg, D. and E. Upfal, "A trade-off between space and
efficiency for routing tables", Journal of the ACM Volume
36, Issue 3, July 1989,
<http://portal.acm.org/citation.cfm?id=65953>.
Author's Address
Tony Li (editor)
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853 9317
Email: [email protected]
Internet Research Task Force T. Li, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Informational October 21, 2010
Expires: April 24, 2011
Design Goals for Scalable Internet Routing
draft-irtf-rrg-design-goals-04
Abstract
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in scalability, mobility, multi-
homing, and inter-domain traffic engineering. The RRG is designing
an alternate architecture to meet these challenges. This document
consists of a prioritized list of design goals for the architecture.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2011.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Li Expires April 24, 2011 [Page 1]
Internet-Draft Design Goals October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Design Goals Collected from Past . . . . . . . . . . . 3
3. Design Goals for A New Routing Architecture . . . . . . . . . . 4
3.1. Improved routing scalability . . . . . . . . . . . . . . . 4
3.2. Scalable support for traffic engineering . . . . . . . . . 4
3.3. Scalable support for multi-homing . . . . . . . . . . . . . 4
3.4. Scalable support for mobility . . . . . . . . . . . . . . . 4
3.5. Simplified renumbering . . . . . . . . . . . . . . . . . . 5
3.6. Decoupling location and identification . . . . . . . . . . 5
3.7. Modularity, composability, and seamlessness . . . . . . . . 6
3.8. Routing quality . . . . . . . . . . . . . . . . . . . . . . 6
3.9. Routing security . . . . . . . . . . . . . . . . . . . . . 7
3.10. Deployability . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Li Expires April 24, 2011 [Page 2]
Internet-Draft Design Goals October 2010
1. Introduction
It is commonly recognized that the Internet routing and addressing
architecture is facing challenges in inter-domain scalability,
mobility, multi-homing, and inter-domain traffic engineering. The
Routing Research Group aims to design an alternate architecture to
meet these challenges. This document presents a prioritized list of
design goals for the architecture.
These goals should be taken as guidelines for evaluating possible
architectural solutions. The expectation is that these goals will be
applied with good judgment.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Priorities
Each design goal in this document has been assigned a priority, which
is one of 'required', 'strongly desired', 'desired', and 'optional'.
Required: The solution is REQUIRED to support this goal.
Strongly desired: The solution SHOULD support this goal unless there
exist compelling reasons showing it is unachievable,
extremely inefficient, or impractical.
Desired: The solution SHOULD support this goal.
Optional: The solution MAY support this goal.
It is possible that two design goals at the same priority level may
be found to be in conflict with one another. If and when this
happens, one of them may be subsequently re-prioritized to have the
two in different priority levels.
2. General Design Goals Collected from Past
RFC 1958 [RFC1958] provides an excellent list of the original
architectural principles of the Internet. We incorporate them here
by reference, as part of our desired design goals.
Li Expires April 24, 2011 [Page 3]
Internet-Draft Design Goals October 2010
3. Design Goals for A New Routing Architecture
3.1. Improved routing scalability
Long experience with inter-domain routing has shown us that the
global BGP routing table is continuing to grow rapidly [BGPGrowth].
Carrying this large amount of state in the inter-domain routing
protocols is expensive and places undue cost burdens on network
participants that do not necessarily get value from the increases in
the routing table size. Thus, the first required goal is to provide
significant improvement to the scalability of the inter-domain
routing subsystem. It is strongly desired to make the routing
subsystem scale independently from the growth of the Internet user
population. If a solution includes support for alternative routes to
support faster convergence, the alternative routes should also factor
into routing subsystem scalability.
3.2. Scalable support for traffic engineering
Traffic engineering is the capability of directing traffic along
paths other than those that would be computed by normal IGP/EGP
routing. Inter-domain traffic engineering today is frequently
accomplished by injecting more-specific prefixes into the global
routing table, which results in a negative impact on routing
scalability. A scalable solution for inter-domain traffic
engineering is strongly desired.
3.3. Scalable support for multi-homing
Multi-homing is the capability of an organization to be connected to
the Internet via more than one other organization. The current
mechanism for supporting multi-homing is to let the organization
advertise one or multiple prefixes into the global routing system,
again resulting in a negative impact on routing scalability. More
scalable solutions for multi-homing are strongly desired.
3.4. Scalable support for mobility
Mobility is the capability of a host, network, or organization to
change its topological connectivity with respect to the remainder of
the Internet, while continuing to receive packets from the Internet.
Existing mechanisms to provide mobility support include (1)
renumbering the mobile entity as it changes its topological
attachment point(s) to the Internet; (2) renumbering and creating a
tunnel from the entity's new topological location back to its
original location; and (3) letting the mobile entity announce its
prefixes from its new attachment point(s). The first approach alone
is considered unsatisfactory as the change of IP address may break
Li Expires April 24, 2011 [Page 4]
Internet-Draft Design Goals October 2010
existing transport or higher level connections for those protocols
using IP addresses as identifiers. The second requires the
deployment of a 'home agent' to keep track of the mobile entity's
current location and adds overhead to the routers involved, as well
as adding stretch to the path of inbound packet. Neither of the
first two approaches impacts the routing scalability. The third
approach, however, injects dynamic updates into the global routing
system as the mobile entity moves. Mechanisms that help to provide
more efficient and scalable mobility support are desired, especially
when they can be coupled with security, especially privacy, and
support topological changes at a high-rate. Ideally, such mechanisms
should completely decouple mobility from routing.
3.5. Simplified renumbering
Today many of the end-sites receive their IP address assignments from
their Internet Service Providers (ISP). When such a site changes
providers, for routing to scale, the site must renumber into a new
address block assigned by its new ISP. This can be costly, error-
prone and painful. Automated tools, once developed, are expected to
provide significant help in reducing the renumbering pain. It is not
expected that renumbering will be wholly automated, as some manual
reconfiguration is likely to be necessary for changing the last-mile
link. However, the overall cost of this transition should be
drastically lowered.
In addition to being configured into hosts and routers, where
automated renumbering tools can help, IP addresses are also often
used for other purposes such as access control lists. They are also
sometimes hard-coded into applications used in environments where
failure of the DNS could be catastrophic (e.g. certain remote
monitoring applications). Although renumbering may be considered a
mild inconvenience for some sites, and guidelines have been developed
for renumbering a network without a flag day [RFC4192], for others,
the necessary changes are sufficiently difficult so as to make
renumbering effectively impossible. It is strongly desired that a
new architecture allow end-sites to renumber their network with
significantly less disruption, or, if renumbering can be eliminated,
the new architecture must demonstrate how the topology can be
economically morphed to fit the addressing.
3.6. Decoupling location and identification
Numerous sources have noted that an IPv4 address embodies both host
attachment point information and identification information. This
overloading has caused numerous semantic collisions that have limited
the flexibility of the Internet architecture. Therefore, it is
desired that a solution separate the host location information
Li Expires April 24, 2011 [Page 5]
Internet-Draft Design Goals October 2010
namespace from the identification namespace.
Caution must be taken here to clearly distinguish the decoupling of
host location and identification information, and the decoupling of
end-site addresses from globally routable prefixes; the latter has
been proposed as one of the approaches to a scalable routing
architecture. Solutions to both problems, i.e. (1) the decoupling of
host location and identification information and (2) a scalable
global routing system (whose solution may, or may not, depend on the
second decoupling) are required and it is required that their
solutions are compatible with each other.
3.7. Modularity, composability, and seamlessness
A new routing architecure should be modular: it should subdivide into
multiple composable, extensible, and orthogonal subsystems. The
intefaces between modules should be natural and seamless, without
special cases or restrictions. Similarly, the primitives and
abstractions in the architecture should be suitably general, with
operations equally applicable to abstractions and concrete entities,
and without deleterious side-effects that might hinger communication
between endpoints in the Internet.
As an example, if tunnelling was used as a part of a solution, it
should be completely transparent to both of the endpoints, without
requiring new mechanisms for determining the correct maximum datagram
size.
The resulting network should always fully approximate the current
best-effort Internet connectivity model, and it should also
anticipate changes to that model e.g. for multiple differentiated
and/or guaranteed upon levels of service in the future.
3.8. Routing quality
The routing subsystem is responsible for computing a path from any
point on the Internet to any other point in the Internet. The
quality of the routes that are computed can be measured by a number
of metrics, such as convergence, stability, and stretch.
The stretch factor is the maximum ratio between the length of a
route computed by the scheme and that of a shortest path
connecting the same pair of nodes. [JACM89]
A solution is strongly desired to provide routing quality equivalent
to what is available today or better.
Li Expires April 24, 2011 [Page 6]
Internet-Draft Design Goals October 2010
3.9. Routing security
Currently, the routing subsystem is secured through a number of
protocol specific mechanisms of varying strength and applicability.
Any new architecture is required to provide at least the same level
of security as is deployed as of when the new architecture is
deployed.
3.10. Deployability
Since solutions that are not deployable are simply academic
exercises, solutions are required to be deployable from a technical
perspective. Furthermore, given the extensive deployed base of
today's Internet, a solution is required to be incrementally
deployable. This implies that a solution must continue to support
the functionality provided by today's routing subsystem. This
includes but is not limited to the ability to control routing based
on policy.
4. IANA Considerations
This memo includes no requests to IANA.
5. Security Considerations
All solutions are required to provide security that is at least as
strong as the existing Internet routing and addressing architecture.
6. References
6.1. Normative References
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
Li Expires April 24, 2011 [Page 7]
Internet-Draft Design Goals October 2010
6.2. Informative References
[BGPGrowth]
Huston, G., "BGP Routing Table Analysis Reports",
<http://bgp.potaroo.net/>.
[JACM89] Peleg, D. and E. Upfal, "A trade-off between space and
efficiency for routing tables", Journal of the ACM Volume
36, Issue 3, July 1989,
<http://portal.acm.org/citation.cfm?id=65953>.
Author's Address
Tony Li (editor)
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853 9317
Email: [email protected]
Li Expires April 24, 2011 [Page 8]
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
