Re: [RRG] Comments on the Design Goals I-D

["K. Sriram" <ksriram@nist.gov>]

Increased path length is a trade-off for reduced table size.
So any proposed solution would be expected to have
a stretch (or path inflation) greater than 100% (relative to the SP
case). 
But if Solution A has 200% stretch while Solution B has 300% stretch,
while each provides the same reduction in table size under the same 
set of conditions (e.g., topology, policy, etc.), then A would be
considered
to have better routing quality in terms of this
trade-off.

Sriram

   

At 06:31 PM 4/24/2007, HeinerHummel@aol.com wrote:

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