[ppml] Policy Proposal 2005-1: Provider-independent IPv6

Thu Apr 27 17:45:25 EDT 2006

On Thu, 27 Apr 2006, Owen DeLong wrote:

> Date: Thu, 27 Apr 2006 01:03:08 -0700
> From: Owen DeLong <owen at delong.com>
> To: "Jason Schiller (schiller at uu.net)" <jason.schiller at mci.com>,
>      Arin Archive <arin at sprint.net>
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6
> 
> 
> On the other side of those who remember, we have group D. This
> group is not ignorant of the limitations of the routing system.
> We are not (yes, I consider myself a member of group D) unaware
> of the issues with routing table growth in the current architecture.
> However, we also remember that one of the primary goals for the
> development of v6 was to FIX THIS.  So far, it hasn't been fixed.
> Between v4 and v6, really, nothing changed in terms of routing.
> 
> However, for both v4 and v6, I am convinced that these issues
> are far less urgent today, although I agree the problem has not
> been completely solved.  Fortunately, I think the problem _CAN_
> be solved and that we have approximately 10 years to solve it.

IPv6 had as its goal to provide enough address space.  It did that, but
that also has implications on the global routing table.  This is why it is
suggested that there be an architectural approach to solving PI,
multi-homing, and mobility problems that do not rely on de-aggregation.

A solution with a complete locator/ID split would probably work, but the
shim6 working group doesn't seem to want to indulge the traffic
engineering needs or requirements of the service providers, content
providers or large enterprise customers who beleive IPv6 traffic
engineering should be at least as functional as IPv4 traffic engineering.

Accepting this PI policy sends the signal that de-aggregation is an
acceptable solution.  Maybe people might think it is a good idea to allow
PI /64s (or /48s) for cell phones into the global routing table to
allow them to be mobile.

> 
> Here's how I figure it:
> 
> 1.	The current routing table is comprised of just over 20,000
> 	active ASNs. The current v4 Prefix:ASN ratio is close to 8:1
> 	on average, with the peaks advertisers being several hundred
> 	and the lows being 1. In the v6 world, this number should be
> 	much much closer to 1:1, probably somewhere around 2:1 will
> 	be realistic. That means that the current routing table
> 	translated to a v6 world will shrink to less than 50,000 routes.
> 	That should give us lots of headroom for v6 growth as v4
> 	becomes less and less prevalant and eventually is not
> 	globally routed.

It is very clear to me that people advertise more specific slices of their
aggrgegate to do traffic engineering.  Why do you think the number of
extra more specific slices for traffic engineering will be reducted to
2:1?

The way I see it by translating the IPv4 table into IPv6 you have the
following.  Start with the CIDR report:
Recent Table History
        Date      Prefixes    CIDR Agg
        03-03-06    179530      118693
AS Summary
         21636  Number of ASes in routing system

Divide the IPv4 table into three types of routes
1. Aggregates
2. De-aggergates that result from adding a second non-contigous block
   (these will go away with IPv6 as the initial assignment will be large)
3. De-aggergates that result from dividing an aggrgegate for traffic
   engineering

Take the number of Internet routes and subtract the number of potentitial
CIDR aggrgegates  179530 - 118693 = 60837  This is roughly the number of
de-aggergates for traffic engineering.

So the IPv4 Internet routing table is 179,530

The IPv6 Internet routing table is the number of IPv6 de-aggergates for
traffic engineering + one aggregate per ASN.  (This assumes that the same
TE practices in IPv4 will be carried over to IPv6) 21636 + 60837 =  82473

Thats 179,530 IPv4 Internet routes
   +   82,473 IPv6 Internet routes
  --------------------------------
      262,003 IPv4/IPv6 Internet routes

Add to that internal more specifics which for a large ISP is between
50,000 and 150,000.  And add to that IPv6 internal more specifics say
between 40,000 and 120,000.  That somewhere between 352,003 and 532,003
routes assuing everyone does dual stack tomarrow.

I know that there will be some ramp up period, but we need to understand
what the routing table will look like once there is wide spread
adoption...  You can argue when wide spread adoptioin will happen, and
project out IPv4 Internet growth, IPv4 de-aggergates for traffic
engineering, and number of ASNs and get a reasonable number of what the
IPv6 routing table will be given normal growth and solving multi-homing
with more specifics in the same way as IPv4.

So I don't think it is unreasonable to think on the agressive side that
there might be fairly good adoption of IPv6 by 2013.  My projections show
1.3M routes by 2013... That means if I want to upgrade a router now, and
it takes 2 years to certify and fully replace my existing network and I
want to depreciate the cost of the router over 5 years, then I need to buy
routers that support 2.3M routes. 

The next question is translating number of routes into RIB size FIB size,
CPU speed, etc...  Geoff Hustom has done some studies in this area...

Take a look at the slides from GROW at IETF 65:

http://www3.ietf.org/proceedings/06mar/slides/grow-1.pdf
http://www3.ietf.org/proceedings/06mar/slides/grow-0.pdf
http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf

My projections are covered in the middle link.

> 
> 2.	It is unlikely that the internet will see anywhere near the
> 	explosive growth of the 90s in the next 5-10 years. Even if it
> 	did, we would still stay well short of 160,000 v6 routes which
> 	is well under most estimates I've heard for current hardware
> 	capability.  As such, there shouldn't be much of a problem
> 	for at least 10 years.
> 
> 3.	The large(ish) ISPs comprise the majority of the operational
> 	focus in the IETF, and, indeed have been a strong enough force
> 	there that they were able to get RFCs cranked out which
> 	attempted to preserve a completely provider-dependent
> 	addressing model for the v6 internet.  As such, faced with
> 	building a scalable routing system or waiting for the network
> 	to implode, I would hope that they will start working towards
> 	a more scalable solution, such as ID/LOC splits.

I don't think there is enough operator support in IETF.  Clearly the
operators don't carry that much wieght.  We can't get shim6 to consider
current operational traffic engineering preferences as a "requirement" 

> 
> 4.	I think that if IETF and large(ish) ISPs and router vendors
> 	work towards a solution, 10 years is more than enough time for
> 	development, testing, and, early deployment.

I need a solution 7 years ahead of the day routers start crashing.

> 
> 5.	Vendor focus, in my experience, tends to be towards making
> 	the large(ish) ISPs happy and the majority of enterprises
> 	are a secondary consideration.  This makes sense when you
> 	consider that the average large(ish) ISP spends several
> 	million dollars per year with their router vendor(s) of
> 	choice, while the rest of the world is significantly less
> 	per enterprise (in most cases) spread over a much wider
> 	collection of sales representatives.  In most sales-oriented
> 	organizations (which as near as I can tell, all the hardware
> 	vendors are today), the sales rep with the largest dollar
> 	value tends to have the largest say in the feature priorities.
> 

When I raise this issue with vendors and ask if other ISPs are concered
abot this they say that the question is very interesting, they have not
beeing looking at the loing term impact of IPv6 on the routing table size
and I am the first to provid some numbers of how big and by when.

___Jason