My Suggestion wrt. 3.1:
Provide an architecture which "abolishes the scalability problem"
Then you have no problems with catering for 3.2 and 3.3.
I mentioned it in Prague: What shall this stretch-philosophy be all
about?
Is it to discredit particular solutions ? What is the gain of it ?
Obviously, it cannot discredit a detour per se. The path of a detour is
longer than the shortest path -this is well-known by everybody and not a
secret.
Heiner
In einer eMail vom 24.04.2007 23:56:07 Westeuropäische Normalzeit schreibt
ksriram@nist.gov:
Tony:
I have marked my suggested changes in your I-D;
please
see the attached word document with highlighted text (in red).
I am also
copying the suggested changes here below as in-line text.
In Section
3.8:
My suggestion in Section 3.8 is to replace the top two
paragraphs with the following four, which are inclusive of the content of
original paragraphs:
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. A comprehensive list of performance matrices and evaluation scenarios
is needed and can be perhaps fully addressed in a companion I-D or annex to
this document. Broadly the performance criteria would include metrics such as
route quality and stability, robustness, scaling, control-plane load,
inter-domain mobility optimization, etc.
Just to stimulate further
thinking, we mention here some metrics that seem to be obvious for the problem
space that is in consideration. These are table-size reduction ratio (TSRR),
convergence time, and stretch (of path length). To evaluate the metrics, a
reference AS-level topology should be defined together with appropriate
service provider policies (see [JSAC-NS06] for example). The baseline
performance metrics would be those for the current BGP routing over the
reference topology. The TSRR is the ratio of the size of the routing table for
a proposed architecture over that of the current BGP routing (for the
reference topology). Comparisons can be made for all the metrics of interest
between new addressing/routing architectures and those for the baseline
case.
The stretch of a routing scheme is the maximum ratio of
the length of the routing path, on which a packet is delivered, to the length
of the shortest path from the source to the destination node, over all
source-destination pairs [PODC06]. Besides the maximum ratio, it would also be
of interest to compute the average and the CDF of the ratio that characterizes
the stretch. The CDF of the ratio would be in the form of the percentage of
source-destination pairs that experience stretch less or equal to x% (x = 0%
to 100% in increments of 10%).
To estimate the convergence time,
a suitable reference perturbation from the steady state of the routing state
can be defined. The perturbation can be in the form of restarts of some
selected routers or perhaps some TCP resets that would induce BGP resets on
selected peering links. The routing state re-convergence time should be
measured for each of the proposed addressing/routing architectures over the
reference topology under the reference perturbation condition.
In
Section 3.9:
My suggestion in Section 3.9 is to replace the
paragraph there with the following (includes the content of the original
paragraph):
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 current level of
security. Given that working groups such as RPSEC and SIDR have already
identified systemic security weaknesses in the current system, the routing
security for any proposed new architectures should extend beyond the current
level. It should be noted that the current state of the art in routing
protocol security would advance by the time of deployment of a new solution
for addressing/routing. For example, the security solutions from SIDR WG
efforts in the IETF will likely progress to RFCs and could be already in
deployment in this time frame.
In Section 3.5:
Comment:
At the end of this section, "without this painful event" sounds subjective.
To clarify, please replace "end-sites to change providers without this
painful event." with either
(a) "some end-sites should be allowed
selectively to change providers without requiring renumbering."
or,
(b) "end-sites should be allowed to change providers (with
renumbering) but consideration should be
given to minimizing the
disruptive impact of the transition."
In Section
6.2:
Please add the following informative reference:
[JSAC-NS06] K. Sriram, D. Montgomery, O. Borchert, O. Kim, and
D.R. Kuhn, "Study of BGP Peering Session Attacks and Their Impacts on Routing
Performance," IEEE Journal on Selected Areas in Communications: Special issue
on High-Speed Network Security, Vol. 24, No. 10, October 2006, pp.
1901-1915.
I hope this is helpful. Thank you.
Sriram
K.
Sriram, Ph.D.
Advanced Network Technologies Division
National Institute
of Standards and Technology
100 Bureau Drive, Stop 8920
Gaithersburg,
MD 20899-8920
Phone: (301) 975-3973
E-Mail:
ksriram@nist.gov
Web: http://www.antd.nist.gov/~ksriram/
=======================================================
At
03:55 PM 4/20/2007, Tony Li wrote:
FYI...
Begin forwarded
message:
From: Internet-Drafts@ietf.org
Date: April 20, 2007 12:50:01 PM PDT
To: i-d-announce@ietf.org
Subject:
I-D ACTION:draft-irtf-rrg-design-goals-00.txt
Reply-To: internet-drafts@ietf.org
A New Internet-Draft is available from the on-line
Internet-Drafts
directories.
Title: Design Goals for Scalable
Internet Routing
Author(s): T. Li
Filename:
draft-irtf-rrg-design-goals-00.txt
Pages: 9
Date:
2007-4-20
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.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-00.txt
|