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:
[snip]
> 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: 136.223.0.0/16 sourced as
raft of same as-path deaggregates by 7018. Are there IRR entries
to indicate a conscious decision rather than error? Surely you
jest.
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.
Joe
* 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