[governance] NTIA statement on IP addressing - broadly supportive of RIRs

[David Conrad]

Avri,

On Dec 5, 2012, at 6:59 AM, Avri Doria <avri at acm.org> wrote:
> Yes, but there are very few levels of hierarchy, nothing like what was expected in 1993/95.  

Network operators (as opposed to protocol designers) were quite well aware that it was unlikely that the routing hierarchy would get very deep and argued quite strongly in the IETF that a new routing architecture was necessary. The network operators were told their input wasn't necessary (and many network operators are still bitter about this). This unfortunately did not stop the protocol designers from coming up with proposals completely divorced from reality like RFC 2450.

> By and large the structure is flat and the tables are large and the routers can handle it, 

As I've been told: it's not the size that matters, it's the magic that's in it.

The amount of routes a router can accept is less important than the time it takes to propagate and converge those routes. Without hierarchy, individual hosts going up and down must be propagated globally to each "core" (that is, without a default route) router. 

This simply will not scale.

As you're aware, the current routing system is two or three levels of hierarchy: your machine's address isn't advertised to the routing system individually, it is aggregated into your organization's or service provider's prefix. If your service provider is small, it is possible that their prefixes are aggregated into their service provider's prefixes. But that's usually as far as it goes.  This means the routing system more or less scales to the number of service providers which is (probably) doable. Where things get sticky is when the routing system has to scale to the number of organizations or infinitely worse, devices (think: cell phones as personal routers for your "personal area network" with multiple carriers for reliability).

The absolute size of the routing tables hasn't really been an issue since the mid- to late-90s. It is, of course, possible to throw huge piles of money at Cisco, Juniper, Huawei, et al. to get boxes with ever more insanely expensive content addressable memory in order to make forwarding decisions in the nanoseconds that you're given at today's line speeds, but how frequently do you want network operators to spend the tens to hundreds of millions of dollars necessary to redeploy their core network infrastructure hardware and who is going to pay for it?

The real problems lie in transistor density (routing engines are already some of the largest and most complex chunks of silicon out there) and how long it takes to create new versions of that silicon, transistor element crosstalk (electronic noise jumping between metal traces separated by nanometers), power consumption, heat dissipation, etc.  Ever look at how much it costs (both in money and in time) to buy, power, and cool a fully configured Cisco CRS-3? And people used to think class 5 telephone switches were too expensive...

> especially when you consider that routing is mostly based on AS numbers and peering rather than on prefix length.

AS numbers are merely a way of grouping prefixes so you can apply a particular routing policy in order to figure out where to send packets destined to those prefixes. The fact that routing policy is defined by groupings doesn't mean that a prefix dropping and coming back doesn't cause a routing update to be sent to all the world's "core" routers.

> Also living in a world where routers need to support both v6 routing information tables and v4 routing information tables, a few extra prefixes are not anybody's routing problem these days.

This is equivalent to saying that a few more coal burning power plants are not anybody's climate change problem these days.  Perhaps true, until you look at how many plants are projected in (say) China.

Regards,
-drc


-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t