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

From: Robert Raszuk <[email-masked]>
Date: Wed, 05 Dec 2007 19:32:33 -0800

Hi David,

So today at the Routing Area Open Meeting you have explicitly expressed 
the concern that "routing is about to collapse".

I found this statement very interesting.

I have been following and discussing with various folks this new wave of 
fixing the routing. In fact I have my own set of ideas which are in fact 
very very close to what Lixia was already proposing. Till now even 
looking ten years ahead no one can show the significant proof that 
"routing is about to collapse".

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

So I think perhaps it is late before the BOF ... do you have data 
references which would lead you to believe that routing is about to 
really collapse ?

Cheers,
R.

PS. Said all of the above I think there are many other benefits for 
introducing the hierarchy in the inter domain routing .. hence I am very 
much supporting this as individual. I am just trying to make sure we 
focus on the correct problem not the imaginary/non-existent ones :).

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

---

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:

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

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: 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: David Meyer <[email-masked]>
Date: Thu, 6 Dec 2007 09:42:49 -0800

On Wed, Dec 05, 2007 at 07:32:33PM -0800, Robert Raszuk wrote:
> Hi David,
>
> So today at the Routing Area Open Meeting you have explicitly expressed the 
> concern that "routing is about to collapse".
>

	I'm not sure what I said exactly, but if I said that, I
	probably misspoke (one of the dangers of speaking on the
	fly, I suppose). But in any event, there is stress on the
	routing system. And BTW, I'm sure one can find ISPs that
	will tell you, "nah, its not a problem", because they have
	the latest and great router [or whatever], but there are
	plenty of folks feeling the pain. If you dispute that,
	search, say, [email-masked] (or just the archives of the
	last meeting). Convolve with the pressure the RIR system 
	is feeling (for example; there many factors here) and one
	can see storm clouds on the (near) horizion. 

	So what we are facing is not as unidimensional as being
	able to build a bigger router. We have plenty of
	existence proofs that we can do that. 
 
> very very close to what Lixia was already proposing. Till now even looking 
> ten years ahead no one can show the significant proof that "routing is 
> about to collapse".

	Well, "about to collapse" probably isn't the way to frame
	it up. Its a complex problem, involving physics
	(dynamical systems), technology (what we are ostensibly
	working on here), economics, public policy (and
	associated regulatory environment), market dynamics,
	etc. I've done a bit of work on what the convolution of
	these various factors might mean, but this is still very
	much more an art than a science. See e.g.,  
	http://www.1-4-5.net/~dmm/talks/NANOG41/perfect_storm.pdf
	for some thinking along these lines.
	
> today carrying ten fold number of routes what today's internet carry for 

	We all know that we vendors say that. We can always build
	something bigger; that is simply not the point. IMO we
	can dispense with this. Its kind of a red herring (I do
	seem to recall someone saying "with enough thrust..." and
	yeah, I know it was Milo). So again, that one can build a
	bigger router is not the point.

	And BTW, as you know, precise models of how the routing
	system works (as a dynamical system) are not available,
	and while although we've done significant reverse
	engineering, to some exent we're all guessing about the
	properties of the system. But 

	we can say a few simple things, such as (i). the DFZ is
	growing, (ii). as the DFZ grows, more of the dynamics of
	the network are exposed in the core (simple computability
	arguments here), and (iii). the widespread deployment of
	IPv6 is a wildcard (O(2^32) >> O(2^128)). 

> much supporting this as individual. I am just trying to make sure we focus 
> on the correct problem not the imaginary/non-existent ones :).

	That seems only prudent, and I'm sure everyone feels the
	same way.

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 6 Dec 2007 09:52:33 -0800

Greg,

On Thu, Dec 06, 2007 at 09:50:05AM -0800, Greg Shepherd wrote:
> Robert,
> 
> Just another thought..
> 
> Yes, we vendors can continue to make larger routers. I wonder if there
> is a tangible power savings by a new routing architecture over just
> building and deploying bigger routers.
> 

	Good point. Power (and associated HVAC) is part of
	the "physics" I was alluding to.

	Dave

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 06 Dec 2007 09:59:38 -0800

Greg,

But I don't see any difference in power consumption when prefixes are 
carried in new fancy mapping scheme, when routers get some routes with 
on demand caching  or if they are carried in a new instance of BGP.

Intra-domain the problem is solved today. Core P routers do not need to 
keep any routes other then routes to next hops when any form of 
tunneling is used. And this is deployed today in many networks. 
Inter-domain can be addressed in very same way.

Cheers,
R.

> Greg
> On Dec 5, 2007 7:32 PM, Robert Raszuk <[email-masked]> wrote:
>  > Hi David,
>  >
>  > _______________________________________________
>  > rtgwg mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/rtgwg
>  >
>

---

From: David Meyer <[email-masked]>
Date: Thu, 6 Dec 2007 10:02:30 -0800

> 	IPv6 is a wildcard (O(2^32) >> O(2^128)). 

	Oophs, make that O(2^32) << O(2^128), but I'm sure you
	take my point.

	Dave