[rrg] Smart host, dumb network - core-edge-sep. doesn't alter this

[HeinerHummel at aol.com]

In einer eMail vom 18.11.2008 06:04:38 Westeuropäische Normalzeit schreibt  
tony.li at tony.li:


|                   Since it is not practical to solve the
|     routing  scaling problem with host upgrades,
|           adding a core-edge separation  scheme (ITRs,
|                 ETRs and a mapping system) is a way of
|    providing portability and multihoming to
|         all end-user networks  which want it, while
|               reducing the burden on routers, and  while
|                   maintaining the full Internet service at all
|    times.
|
|                   It is adding "stuff" - hardware, software
|    and a global mapping system - to the Net,
|         in order to avoid  adding something uglier
|               and more expensive, ever-bigger  routers
|                   and a less stable DFZ (while still not
|     meeting  the portability and multihoming
|             needs of many smaller end-user  networks).


Well, that's certainly one opinion.

If we want to  change the architecture to something that we can live with in
perpetuity,  we might want to step back and take a larger view of the world.
IPv6 is  coming, like it or not. 
Well, that's certainly one opinion, too.
Quote from the RAWS report:
 
3.2.  IPv6 and Its Potential Impact on Routing Table Size
 
   Due to the increased IPv6 address size over IPv4, a full  immediate
transition to IPv6 is estimated to lead to the RIB and  FIB sizes
increasing by a factor of about four.  The size  of the routing table
based on a more realistic assumption, that  of parallel IPv4 and IPv6
routing for many years, is less  clear.  An increasing amount of
allocated IPv6 address  prefixes is in PI space.  ARIN [ARIN] has
relaxed its  policy for allocation of such space and has been
allocating /48  prefixes when customers request PI prefixes.  Thus,
the  same pressures affecting IPv4 address allocations also affect
IPv6 allocations.
 
Heiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.irtf.org/pipermail/rrg/attachments/20081118/05cfc5f6/attachment-0001.htm>