Subject: Re: [RRG] Re: FYI -- Informal LISP BOF scheduled for lunch time on Thursday

From: [email-masked] (Noel Chiappa)
Date: Thu, 6 Dec 2007 00:29:40 -0500 (EST)

> From: Robert Raszuk <[email-masked]>

    > Till now even looking ten years ahead no one can show the significant
    > proof that "routing is about to collapse".
    > ...
    > there are number of vendors with deployed platforms which are today
    > carrying ten fold number of routes what today's internet carry for some
    > other applications.

The issue is not just how many routes any box (or set of them) can hold
(although that is a significant concern, because there is installed base all
over the world, and not all the component organizations have budget to
replace/upgrade it all freely).

The thing is that today's routing architecture is a giant distributed
computation, one which doesn't 'run to completion', but is always running,
responding to changes in the world-wide physical connectivity. A change
happens, and things respond, and eventually affected paths settle down and
stabilize after some time Ts. Needless to say, it's not really feasible to
really completely model the global system's behaviour in any kind of smaller
network and/or test lab.

My impression is that most people who are worried about the "routing [being]
about to collapse" are worried about a number of things, one of which is about
that giant distributed computation going unstable (e.g. Ts going over some
kind of knee). A good analogy is the various breakdowns in the North American
power grid over the last couple of decades, all of which included various
poorly-understood large-scale 'system effects', complex interactions that
didn't show up in small-scale systems.

Maybe it's not a problem, and we don't need to worry about it, but the thing
is that it's so complex, and so little studied/understood, that it's hard to
be sure there's no problem lurking out there.

	Noel

_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 5 Dec 2007 23:39:34 -0800

On Dec 5, 2007, at 9:29 PM, Noel Chiappa wrote:
> kind of knee).
...
> be sure there's no problem lurking out there.

Of course, it's hard to prove a negative, especially about large  
complex distributed systems.  OTOH, there's some argument to be made  
(and I've made it before) that there's no obvious knee in the BGP  
performance curve.  I'm not aware of a persuasive argument to the  
contrary.

No dispute whatsoever regarding your point about the lack of study of  
large scale Internet routing dynamics (and implicitly, the need for  
same).

--John

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Dec 2007 00:13:52 -0800

On Dec 5, 2007, at 11:39 PM, John G. Scudder wrote:

> complex distributed systems.  OTOH, there's some argument to be  
> made (and I've made it before) that there's no obvious knee in the  
> BGP performance curve.
>

Strictly speaking John is, of course, correct.  We should continue to  
see linear degradation in performance as the table grows.

However, some speculate that we will see a knee in the number of  
prefixes that are carried in the DFZ.  In these scenarios, as a  
market for v4 prefixes is established, it will become easier for  
organizations to acquire PI prefixes and inject them.  Further,  
existing space holders will tend to de-aggregate them so as to  
maximize their market positions.  This combination could possibly  
lead to a knee in the size of the overall table and a resulting knee  
in overall Internet convergence time.

I should stress that this is all speculative at this point and we  
will simply have to see how it all plays out.

We live in interesting times.

Tony

---

From: "Miya Kohno" <[email-masked]>
Date: Thu, 6 Dec 2007 22:22:19 +0800

This reminds me of Gödel's Incompleteness Theorem :)  "Any precise mathematical system must contain some statements that are neither provable nor disprovable by the means allowed within the system".  (1931) 

Since we are within the system, we cannot prove or disprove. 

Maybe the options are: 

 - daily evolution with feedback
 - destruction and reconstruction (by those who are outside of the system??)

Miya

> > performance curve.
> Strictly speaking John is, of course, correct.  We should 
> continue to see linear degradation in performance as the table grows.
> 
> However, some speculate that we will see a knee in the number 
> of prefixes that are carried in the DFZ.  In these scenarios, 
> as a market for v4 prefixes is established, it will become 
> easier for organizations to acquire PI prefixes and inject 
> them.  Further, existing space holders will tend to 
> de-aggregate them so as to maximize their market positions.  
> This combination could possibly lead to a knee in the size of 
> the overall table and a resulting knee in overall Internet 
> convergence time.
> 
> I should stress that this is all speculative at this point 
> and we will simply have to see how it all plays out.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 06 Dec 2007 08:02:23 -0800

Noel,

> replace/upgrade it all freely).

I am not suggesting massive worldwide upgrade :) I am convinced that 
currently deployed routers in the Internet core would do just fine with 
the help of just control plane changes. Contrary currently proposed 
schemes do require hardware changes/additions for interdomain tunneling.

> stabilize after some time Ts. 

That is true and the possible upcoming impact of knee effect of IPv4 
addresses should not be dismissed. But my observation lead me to believe 
  that various proposals here are building a Titanic solutions where 
what is needed to be on the safer side is just a new operational mode to 
the current boat.

In particular to increase overall system stability and Internet safety 
margin I would recommend to consider a very simple approach ...

To separate in current today's BGP prefixes from next hop. To converge 
next hops aggressively while increasing the timers for prefixes. Very 
simple and IMHO quite effective way to reduce the product of "# of 
prefixes * change rate".

And such separation could be just new SAFI for next hops. Easy to 
gradually deploy, does not require new mapping layers, can be user with 
intra or inter domain tunneling (but this is not a must) ....

To summarize I am not convinced .. why we are jumping into the ocean 
while there is plenty of room in the current pool to swim.

Cheers,
R.

---

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 6 Dec 2007 09:33:35 -0800

> intra or inter domain tunneling (but this is not a must) ....

Good point(s). And work like this should continue independent of
whether others are working on new architecture approaches. The
discussion about whether or not there is a larger problem that needs
solving will never come to a conclusion until/unless the problem
reveals itself in some unfortunate way.

> while there is plenty of room in the current pool to swim.

But wouldn't it be great if when you finally find yourself with no
more room in the pool, to find someone has already prepared the way
for you to make your move over to the ocean?

Greg