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

From: "K. Sriram" <[email-masked]>
Date: Tue, 24 Apr 2007 17:54:33 -0400

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: [email-masked]
Web:  http://www.antd.nist.gov/~ksriram/
=======================================================
At 03:55 PM 4/20/2007, Tony Li wrote:
>FYI...
>Begin forwarded message:
>
>>From: <mailto:[email-masked]>[email-masked]
>>Date: April 20, 2007 12:50:01 PM PDT
>>To: <mailto:[email-masked]>[email-masked]
>>Subject: I-D ACTION:draft-irtf-rrg-design-goals-00.txt
>>Reply-To: <mailto:[email-masked]>[email-masked]
>>
>>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>http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-00.txt
>
>

---

From: [email-masked]
Date: Tue, 24 Apr 2007 18:31:01 EDT

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  
[email-masked]:

Tony:

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:

[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.

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:  [email-masked]
Web:  _http://www.antd.nist.gov/~ksriram/
_ (http://www.antd.nist.gov/~ksriram/) 
=======================================================
At  03:55 PM 4/20/2007, Tony Li wrote:

FYI...
Begin forwarded  message:

From: [email-masked] (mailto:[email-masked])   
Date: April 20, 2007 12:50:01 PM PDT
To: [email-masked] (mailto:[email-masked]) 
Subject:  I-D ACTION:draft-irtf-rrg-design-goals-00.txt 
Reply-To: [email-masked] (mailto:[email-masked])   

A URL for this Internet-Draft is:
_http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-00.txt_ 
(http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-00.txt)

---

From: "K. Sriram" <[email-masked]>
Date: Wed, 25 Apr 2007 10:07:07 -0400

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, [email-masked] wrote:
>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 [email-masked]:
>Tony:
>
>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, 
>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
>[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

---

From: [email-masked]
Date: Wed, 25 Apr 2007 12:01:41 EDT

OK, I understand.
But what kind of solutions A and B do you have in mind that have a 100 %  
stretch difference ?
 
Heiner
 
In einer eMail vom 25.04.2007 16:09:20 Westeuropäische Normalzeit schreibt  
[email-masked]:

Sriram

My Suggestion wrt.  3.1:

Heiner

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 10:13:28 -0700

On Apr 25, 2007, at 9:01 AM, [email-masked] wrote:

> OK, I understand.
> But what kind of solutions A and B do you have in mind that have a  
> 100 % stretch difference ?

Once you start tunneling (i.e., map-and-encap or TE), then you pretty  
much can concoct any amount of stretch that you might want to imagine.

Imagine an end-site that is dual homed in North America and Europe.   
For a European destination, the European locator is preferred.   
Suppose, however that when the European link to the site is down, all  
such traffic is tunneled back to the North American link.

This would trivially give you something like 200% stretch.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 10:36:28 -0700

Hi Heiner,

> Then  you have no problems with catering for 3.2 and 3.3.

Well, the only real way to "abolish" the scalability problem is to  
insist on solutions that have zero growth.  That's not necessarily  
feasible or a requirement.  After all, hardware is getting faster and  
we can reasonably take advantage of that.

However, even with a zero growth solution for 3.1, it's trivial to  
imagine a solution for TE that still results in non-scalable growth:  
for example, generate arbitrary more-specifics, down to the host level.

> 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.

The purpose of all of these design goals is to help us agree on the  
criteria that we will use to evaluate various proposals.  We are  
trying to establish the metrics that we will use to judge proposals  
on, but are also trying to leave open the possibility of using our  
judgement to make intelligent trade-offs between various metrics.   
Thus, we are trying to avoid creating arbitrary requirements on those  
metrics.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 11:48:54 -0700

Hi Sriram,

Thanks very much for your suggestions.

> 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.

Well, I'm not yet convinced that that level of detail is necessary or  
beneficial.  Our goal is to recommend a routing and addressing  
architecture, but selecting specific mechanisms is out of scope.   
Getting to comprehensive, quantitative metrics is going to be very  
hard without dealing in mechanisms and our goals really should be  
focused on architectural issues.

> 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.

Having watched those particular WGs, I don't think that we can assume  
that they will advance the state of the art in time.  ;-)

However, I do take your point that if they do so, any new  
architecture should be no worse than where the state of the art is.   
Revised text:

	  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 state of the art level of security.

> (a) "some end-sites should be allowed selectively to change  
> providers without requiring renumbering."
> or,

Would you settle for:

	It is strongly desired that a new architecture allow
	end-sites to change providers with significantly less disruption.

Tony

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Wed, 25 Apr 2007 13:47:41 -0700

> Increased path length is a trade-off for reduced table size.
This is not necessarily true. Depending on the address scheme and  
route aggregation scheme, you can achieve shorter paths (as measured  
by geographic distance) and smaller routing tables at the same time.

--Ricardo

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 14:23:44 -0700

On Apr 25, 2007, at 1:47 PM, Ricardo V. Oliveira wrote:

> route aggregation scheme, you can achieve shorter paths (as  
> measured by geographic distance) and smaller routing tables at the  
> same time.

Ricardo,

Can you please say more?  It's a long held tenet that abstraction is  
necessary for scalability and that abstraction results in sub- 
optimality.  Routing and addressing architectures that are both  
scalable and optimal would be of great interest.  Everyone would like  
to have their cake and eat it too...  ;-)

Regards,
Tony

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Thu, 26 Apr 2007 13:53:49 -0700

Tony, i meant that "table size" and "stretch" are not the only knobs  
you have to tune a routing system. For instance, the table size also  
depends on the address and aggregation schemes used.
Alternative schemes to IPv4+BGP might not only reduce the table size,  
but also decrease route length compared to BGP.

--Ricardo

> Ricardo,
>
> Can you please say more?  It's a long held tenet that abstraction  
> is necessary for scalability and that abstraction results in sub- 
> scalable and optimal would be of great interest.  Everyone would  
> like to have their cake and eat it too...  ;-)
>
> Regards,
> Tony
>
> --

---

From: Tony Li <[email-masked]>
Date: Thu, 26 Apr 2007 14:03:30 -0700

Ricardo,

On Apr 26, 2007, at 1:53 PM, Ricardo V. Oliveira wrote:

> For instance, the table size also depends on the address and  
> aggregation schemes used.
> Alternative schemes to IPv4+BGP might not only reduce the table  
> size, but also decrease route length compared to BGP.

Ok, thanks for replying.  On those points, we're in complete agreement.

Regards,
Tony

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 10 May 2007 14:34:58 -0700

I am running late but trying to catch up now.

On Apr 25, 2007, at 10:36 AM, Tony Li wrote:
> feasible or a requirement.  After all, hardware is getting faster  
> and we can reasonably take advantage of that.

I agree with Tony here.

If I try to state in a more general term, it seems to me that a good  
scalability solution does not necessarily put some absolute cap on  
the size of the system, but rather, it should have a control handle  
on the size, and can effectively adjust the size based on the  
engineering tradeoffs (which necessarily change over time)

> imagine a solution for TE that still results in non-scalable  
> growth: for example, generate arbitrary more-specifics, down to the  
> host level.
>
>
> Thus, we are trying to avoid creating arbitrary requirements on  
> those metrics.
>
> Tony

---

From: Scott W Brim <[email-masked]>
Date: Thu, 24 May 2007 19:48:08 -0400

Hi Tony.  Some late comments, for your next version.  Your text is
indented.

   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 routing plane 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 routing plane.

The last sentence is a fine end result, but carrying the state
information isn't the only problem.  What about churn?

   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.

Again I like the last sentence but not the lead-in.  If we are
defining new routing capabilities, what is "normal"?  Current?  How
about deleting the first sentence and revising the last as:

     A scalable solution for directing traffic along inter-domain
     paths according to more than just destination address is strongly
     desired.

Onward ...

   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.

"Attachment point" and "location" are used interchangeably.  They can
be derived from each other 1:1 but I suspect a location is one way to
name an attachment point, so let's not use them interchangeably.  Do
we need to say somewhere that locations refer to attachment points?

   "Stretch"

Optimality ratio?

Also, how about something about "with the queuing treatment
requested"?

   Convergence

You mention convergence but can we be more specific about what are we
after?  Convergence time that scales with log n?  ??

On 04/25/2007 14:48 PM, Tony Li allegedly wrote:
> Well, I'm not yet convinced that that level of detail is necessary
> or beneficial.  Our goal is to recommend a routing and addressing

We want some general parameters by which to judge a system, but we
don't know what they are yet.  Maybe we can get closer in the concepts
draft.

swb

---

From: Tony Li <[email-masked]>
Date: Fri, 25 May 2007 14:40:28 -0700

Hi Scott,

Thanks for your comments.  Please see inline.  I think a number of  
these questions should spark discussions.

> information isn't the only problem.  What about churn?

As I think we've discussed before, it's my personal contention based  
on my BGP experience that the churn is actually an artifact of the  
protocol and is not fundamental to the current routing architecture.   
I believe that the churn can be adequately addressed by some  
additional implementation sophistication within BGP, and I'm actively  
and personally working on this topic, albeit at a greatly restricted  
bandwidth.  Folks interested should stay in touch with the IDR  
mailing list or drop me a line.

That said, I do feel that this document should reflect the rough  
consensus of the research group.  If folks feel that I'm grossly  
misrepresenting the group, please step up and debate your point.

>      paths according to more than just destination address is strongly

I like the finesse, but sooner or later, we're going to have to give  
a definition for 'traffic engineering'.  It's simply too common a  
term for us to duck.  Also, the current inter-domain TE approach  
really doesn't require anything more than the destination address.   
It's just providing much more granularity than mere reachability  
would require.  We also already have policy considerations in path  
computation via BGP today.

I'm more than happy to improve the definition if you have specific  
suggestions, but on my own, I'm failing to come up with something  
that's satisfactory without referring to 'normal' or 'current' routing.

> we need to say somewhere that locations refer to attachment points?

Happy to do so, but we should provide a clear definition of each.   
Care to propose text?

> Optimality ratio?

Thanks, but 'stretch' already seems to be the accepted term in the  
literature.

> Also, how about something about "with the queuing treatment

Do we have consensus that this should be a goal?  It's the first time  
I've seen it raised in this forum.  In any case, please propose text.

> after?  Convergence time that scales with log n?  ??

Well, my personal preference would be convergence that prevents my  
TCP connections from breaking.  Do folks have other metrics that  
they'd like to propose?  I know some folks will simply say 50ms.

Tony

---

From: [email-masked]
Date: Fri, 25 May 2007 18:14:06 EDT

Scott,

By aiming for a solution which eliminates the scalability problem we  would 
get multiple improvements which you address:
no convergence time problem, no routing churn, a relaxed situation wrt  
prefix building pressure, no pressure for loc/id-split from the  scalability 
problem's point of view (loc/id-split  may have other  advantages, e.g. like 
pointing to the right direction of  research)  - and more.
 
Being of the right size: a thousand times bigger worm needs a lung rather  
than taking in oxygen by the skin.
Bestowed with a lung there are even  more advantages: You don't have  to 
expose all your skin both to the air (oxygen) AND the coldness in  winter :-)
 
Heiner

In einer eMail vom 25.05.2007 01:50:11 Westeuropäische Normalzeit  schreibt 
[email-masked]:

Onward ...

"Stretch"

Optimality ratio?

Convergence

swb

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 28 May 2007 20:55:07 -0700

catching up...

> information isn't the only problem.  What about churn?

I tend to agree with Tony here that routing table size and churn are  
two separable issues.  The former is a scaling issue; the latter is  
more of a protocol/implementation issue---one can have bad churn even  
with a small routing table size.

As the Internet gets bigger, the churn does go up, but it may have  
more to do with the scalability of cluefulness than the table size,  
though both are the result of getting big.

>      paths according to more than just destination address is strongly

Personal opinion: yes the existing statement can benefit from further  
quantification, though I feel less sure how much improvement the  
suggested alternative brings...

Splitting prefixes is a simple and effective means to achieve traffic  
engineering goals, and whoever needs to do it will do it. I believe a  
scalable solution essentially lies on the ability to effectively (re) 
aggregate prefixes.

> we need to say somewhere that locations refer to attachment points?

if the above paragraph is the only place where "Attachment point" and  
"location" are used interchangeably, it seems to me that a simple  
solution is to change the last sentence to
      Therefore,
      it is desired that a solution separate the host attachment
      point namespace from the identification namespace.

> Also, how about something about "with the queuing treatment

I am not sure what this meant...

> after?  Convergence time that scales with log n?  ??

this comment raised a good point: there are probably a few open  
issues embedded herein
- in literature there are schemes that can converge in constant step
   (for example, "BGP-RCN: Improving BGPConvergence through Root  
Cause Notification"
   http://www.research.att.com/~peidan/bgp-rcn.pdf)
- but there is a cost associated with such solutions.
   So convergence speed cannot be a goal on its own, one has to  
consider the cost.
- Tony's reply hits an important issue: convergence itself is not the
   ultimate goal, data delivery is.
   If data can be successfully delivered *during* convergence,
   then a stringent limit on convergence delay may not be necessary?

if anyone is interested in literature along this line, see
* "A Study of Packet Delivery Performance during Routing Convergence"
IEEE DSN 2002, http://www.research.att.com/~peidan/peid_packet.pdf
* "A Measurement Study on the Impact of Routing Events on End-to-End  
Internet Path Performance"
SIGCOMM 2006, http://www.eecs.umich.edu/~zmao/Papers/mhBeacon.pdf
* "Achieving Convergence-Free Routing using Failure-Carrying Packets"
to appear in SIGCOMM 2007
http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-28.html

Lixia

---

From: [email-masked]
Date: Tue, 29 May 2007 05:25:25 EDT

In einer eMail vom 29.05.2007 05:57:14 Westeuropäische Normalzeit schreibt  
[email-masked]:

...or, just the opposite as I believe, on a design that removes the  pressure 
for doing prefix aggregation totally.
 
  Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 29 May 2007 18:04:37 -0400 (EDT)

> From: Scott W Brim <[email-masked]>

    > Some late comments

Ditto - sorry 'bout the delay, but life has been busy. (And basically all of
this I know you know already, but I put this text in for others, and perhaps
also you can use some of it.)

    > Your text is indented.
    >   global BGP routing table is continuing to grow rapidly ...
    >   ... the first required goal is to provide significant improvement
    >   to the scalability of the routing plane.
    >

This is related something that I noticed when I read the draft, which is that
it talks a lot about growth, but in general terms, and I'd like to see this
scalability point broken down into more detail.

Specifically, the overhead of the routing has historically been measured by
its use of three disparate resources: memory, transmission bandwidth, and
computing power. Early work characterized routing algorithms by equations
which described how they used all of these; these days, the picture is
simultaneously less and more complicated.

Less, because bandwidth isn't really an issue any more. AFAICT, the time
required to send data to neighbours, even in the worst cases, is a miniscule
percentage of the link bandwidths we have these days. (Although we do still
have plenty of slow-speed links in the network, which architects must
remember, I'm not sure there are very many in the DFZ.)

More, because there are two kinds of memory now: RIB and FIB (and because of
the way routers are designed now, there probably always will be this
distinction). Particularly with BGP, the usage of the two has different
equations of growth. Growth of the RIB is also important because it's a
stand-in for something else that's important, which is the time needed to
cold-start a router; I gather that many current routers can take quite a
while to load the full DFZ routing table from their neighbour. The issue
here, I gather, isn't really bandwidth, but rather computing power, 

There's also a fourth "resource" which is being consumed, and it's one that
Scott's comment alluded to, which is real-time, a critical component of
stability and stabilization-time issues. A lot of comment swirls around the
FIB size, but to me, that's not really the important thing; I'm much more
concerned about stability/stabilization-time issues (I'll explain why in a
bit).

The real-time that's being used comes from two source: propogation delays
(about which we can do nothing), but my impression is that the far larger
source of delays is when updates are serialized. I.e. with one processor, if
updates A and B arrive back-to-back from a neighbour, update B can't be
processed, and forwarded on to other neighbours, until update A has been
fully handled. So this turns back into processing-power (again).

The consumption of real-time has two consequences: bad and worse. The bad one
is that after a major topology change, it can take the routing "a while" to
recover. The Renesys NANOG presentaion Taiwan quake seemed to indicate that
"a while" is on the order of an hour or so. (However, it's not clear if that
was the time it took BGP to recover, or the time needed to reroute some
circuits. The Rensys presentation also covers much longer-term outages, but
those were caused by the need to set up new business relationships - not
really a routing problem!) But even if it was partially circuit
reconfiguration, still, I notice that whenever something on the East Coast
changes, my SSH connection from Virginia to MIT inevitably times out before
the routing stabilizes again, and it would be nice if adjusted faster than
that - there's no reason it should be taking so long.

The worse one is that if the line for "time to adapt to a topology change"
(which goes up as the network gets bigger) crosses the "average inter-event
time for topology changes" line (which goes down as the network gets bigger)
you can get serious instability.

So we need to characterize use of these resources (memory, processing power,
etc) not just for the static case (when the net is stable), but *especially*
for the dynamic case (when something changes), because that's what *really*
stresses the routing.

Which is a good place to stop and point out that FIB size, in the static
case, is a problem, but it's an easy one to i) understand (which is no doubt
a good part of why it generats so much commentary), and ii) solve - because
the solutions are *local* - i.e. inside each router, with no consideration to
what's going on with its neighbours.

Stability and stabilization-time are *system* problems, where no one node can
really do anything about them - and, if we *do* run into problems, it will be
difficult, and slow, to deploy an effective fix. So that's why I think the
dynamic case (i.e. response to topology changes) is much more important to
look at.

	Noel