Moving to IPV6

[Mike O'Dell]

forwarding lookup memory is certainly a concern, especially
since "wire speed" means 100 gigabits/sec for any machine
going into production in the next year or two. assuming
the TCAMs don't get a lot faster, you can always just
multi-bank and round-robin the lookups. of course,
given TCAMs just fast enough for 10Gbps ports,
multi-banking for 100Gbps ports would need 10x
the memory just for the banks (add the 2x for
atomic updates and you have 20x).

assuming you can solve the problem in the previous paragraph,
you get to the serious heat-death problem - the computation
of the forwarding table. and it's not the size of the *final*
table, is the amount of information which must be sifted
in order to compute the forwarding table. each aggregated
group of prefixes produces one route announcement,
and as previously mentioned, the failure of v6 to deal with
multi-homing means that whatever hack is used to cope
with it will mean that there are at least two 
disaggregated routes introduced into the two upstream
ISPs for each multihomed site, which will produce
an additional disaggregated route announcement for
each of those ISPs.

now consider, however, that every route announcement
is heard multiple time - usually *MANY* times - at
least equal to the number of external links to
other networks (ASes), and within a network,
the multiplier can be much higher (for simply perverse
reasons). hearing fewer than 10 copies would be
a novelty and as many as 100 copies shouldn't be
particularly surprising in large networks.

as for multihoming, as more and more services move
"into the cloud", the need to multihome will become
more urgent for more and more organizations. it's one
thing to have email down for a hour or two, but it's
quite another to have the sales department sitting
idle because they cannot reach Salesforce.com,
or the entire organization in spin loops because
they cannot reach Google Apps. this will force
more multihoming faster than anything else 
i can imagine.

the computation which considers all the announcements
heard and finally crunches a BGP forwarding table
(which is then left-multipled with the IGP forwarding
table) is roughly N*log2(N^2), which approximates
N^2 for large N.  note that N is the number of
announcments heard - not the number of distinct 
announcements, and certainly not the number of entries
in the final forwarding table. it is N^2 of the
biggest number with all the extra copies.

this computation is not sustainable. indeed it displays
the fundamental pathology of an unscalable distributed
algorithm - it sends scads of information to everywhere,
and it's really needed only a small (comparatively) number
of places. A BGP withdrawl on the far side of the world
that you can reach by only a small number of paths rattles
your forwarding table!

As a result, how anyone can say the phrase "BGP convergence"
with a straight face reveals truly gifted thespianism.

in fact, the entire concept of "routing convergence"
for anything other than a very small neighborhood
is just non-sensical.  

my meandering point is that we have come to the end of
Newtonian networks - where control algorithms can 
assume instantaneous propagation of unbounded information
and infinite computing resources to process it.
Space is still locally flat, but at sufficiently-large
scale (or sufficiently small), the Newtonian formulation
of reality simply fails and we must make peace with
a Relativistic model which says networks with a 
propagation diameter larger than the minimum 
inter-event time simply cannot be stable because
the information cannot propagate fast enough;
that telling everyone in the world massive piles
of crap they not only don't care about but CANNOT
care about is a death wish; and that What, Where, and How
needs THREE layers of addressing, not the 2.1 or so
we have now.

The IP architecture has serious wounds and it is bleeding fast.
Yes, a tourniquet can help staunch the blood flow until
we can get to better care.

Unfortunately, it's a head wound, and there aren't many
choices about where to put the tourniquet.

      -mo