Weekly Routing Table Report

Joe Provo nanog-post at rsuc.gweep.net
Sun Jan 9 14:09:38 UTC 2005

On Fri, Jan 07, 2005 at 03:47:08PM -0500, Jared Mauch wrote:
> 	I think that's a matter that seems to be already decided.  
> People want multihoming, redudnancy and such and are willing 
> to put the burden on the global routing table as a result.

The matter was not strictly (not even primarily) multihoming 
when the last serious look at the data was made, and it doesn't 
appear to be the matter today.  CAIDA's older data matches my
current anecdotal day-to-day experience.*   (No one has offered 
more current analysis in the wake of continuing threads here 
and elsewhere. If you've got more recent data + analysis then 
then please share.)

The largest growth element I see is deaggregation of 'classical' 
space which may have perfectly valid purpose within an AS, or in
a provider-customer relationship, but not N hops away in the DFZ.
The reasons vary from putting the burden of traffic engineering 
on the rest of the world to handwaving about applying security 
band-aids by reducing the visibility into the the target space.

Trivial example pulled off the top: sourced as 
raft of same as-path deaggregates by 7018.  Are there IRR entries 
to indicate a conscious decision rather than error? Surely you 

Yes, growth happens and the memory addition Jared cites has been
going on and continues to go on (multihoming enterprises, other 
edge customers now get to feel the pain).  There are some 
interesting observations as part of the current 'atom' work**
previously discussed in the nigh-weekly related threads here.


* specifically, see para 2 in conclusions of "Complexity of global 
  routing policies" http://www.caida.org/outreach/papers/2001/CGR/
** section 6 in http://www.caida.org/projects/routing/atoms/proposal/

             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

More information about the NANOG mailing list