[ppml] Policy Proposal 2005-1: Provider-independent IPv6
Marshall Eubanks
tme at multicasttech.com
Fri Apr 28 09:14:44 EDT 2006
Dear Jason;
Thank you for this information. I have been coming at this from the
other direction (I, also,
have been flying a lot this week!), let's see if the lines cross
somewhere.
On Apr 27, 2006, at 5:45 PM, Jason Schiller (schiller at uu.net) wrote:
> 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
It is apparent to me that some multiple address blocks represent
hidden autonomous
systems. I have had several enterprise network architects tell me
things along the line of
"we have N address blocks, one for each location where we have a
presence, and they have separate
upstream providers, but we just don't feel like getting / paying for
an ASN for each one of
these". These clearly will not be aggregated; it is not clear to me
how many CIDR aggregates fall into
this class, but I suspect some do.
>
> 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.
>
Don't almost all of these fall in category 3 ? In addition, won't
NONE of the category 2's
(the address blocks are not contiguous, after all) be potential CIDR
aggregates ? So it's not
clear to me how good an estimate this is. In the spirit of back of
the envelope estimates for
years into the future, I will buy it, but we might be able to a
better job defragmenting the
address space.
> 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.
Isn't this a typo, shouldn't it be "1.3M routes" ? Otherwise, I don't
see where it comes from.
I actually think that these numbers are not too far out of line; the
question is, is the
time line out of line ?
The US Small Business Administration
http://www.sba.gov/advo/research/us_03ss.pdf
estimates that there were 5,696,600 employer firms in 2003, 99.7
percent of which are small firms
(i.e., there are 17090 non small firms, with 500 or more employees).
Of the employer firms, there are 2,262,695 with 5 or more
employees, and 1,237,198 with 10 or more employees. I think that a
reasonable upper bound for the
potential number of ASNs in the US right now is the latter number.
(Since the number of firms is not increasing exponentially as fast
as routes are, and since I am resolutely in back of the envelope
mode, I will assume that these numbers will be constant over the next
decade.)
Assume that the existing 182,282 routes that I see this afternoon are
all due to
large businesses, and that these can be aggregated to 82,473 routes,
as your numbers suggest.
This would suggest that the US might add (1,237,198 - 82,473 =)
1,154,725 routes eventually.
Since the US is roughly 1/5 of the global economy, that suggests that
the total number of additional
routes might be as large as 6 million.
The real question is, by when ? I get a doubling time in the number
of route of ~ 6.5 years from my data. I
do not see a formal doubling time estimate in your presentation,
but you must have estimated it or the equivalent, to get
your power law projections, so I would be curious to hear what it is.
I don't see it as being too much different from your graphs.
182,000 to 6 million routes is 5.0 doublings, which means that I
would predict that the system would saturate
(without artificial constraints) in 33 years, and would reach 1
million routes in about 2.46 doublings, or
~ 16 years, or 2022. If you assume a doubling time of 5 years (which
is not supported by the data, but let's
assume things speed up to be conservative), we get saturation in 20
years, and 1 million routes in 12.3 years,
or 2018.
Note that if you can get a factor of 2 now by defragmenting the
address space, that adds 1 doubling time (~ 6 years or more) to all
of these estimates. Note also that you are assuming that most routes
are doubled in v4 and v6, so that costs you a doubling time if there
is no defragmentation. Let's assume that that is true, and that there
is no defragmentation (to be conservative), I get and 1 million
routes in 9.5 years, or late 2016. If (more reasonably, and more in
line with your estimates), you assume a 50 % defragmentation
of the IPv6 address space, and otherwise a sharing of space between
v4 and v6 (i.e., assuming that every path
is represented in both address spaces), then you get an address space
predictor of (1.5 x 2^(# doublings)), or
1 million routes in 1.87 doubling times, or 12 years. (Hopefully
IPv4 growth would actually start to slow at
some point in this future, so I regard this as a pretty conservative
estimate.)
So, I would estimate that 1 million external routes (with no
artificial constraints) should be achieved somewhere in the 2016 to
2022 time frame, and saturation somewhere around 2030 to 2040. (For
saturation, you clearly also
have to include an estimate of global economic growth in the next few
decades, which would take us way
off into the weeds.)
Of course, I understand from your presentation that you get that
number by including internal routes, so
let's look at them too.
>
> 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.
>
OK, 2013 is 7 years from now, so let's look at your 7 year predictions.
For ease of discussion, I will reproduce these here, rounded off :
IPv4 routes : 338,000
IPv4 intentional deaggregates : 195,000
Projected IPv6 : 237,000
Projected internal IPv4 (low) : 49,000
Projected internal IPv4 (high): 360,000
Projected internal IPv6 (low) : 132,000
Projected internal IPv6 (high): 404,000
Total External : 770,000 ( 31 % are IPv6)
Total Internal (low) : 181,000
Total Internal (high) : 764,000
Totals (low) : 825,000 ( 29 % are IPv6 external)
Totals (high) : 1,049,000 ( 23 % are IPv6 external)
(Seven years is just a little over one doubling time from the present; I
would predict a total of 576,000 v4 + v6 external routes then, so in
back of the envelope
mode I could buy 770,000.)
So, for the 1.3 million route router you need to buy now, if SHIM6
was working today, and
there were NO IPv6 routes required at all (ok, 1), then you would
need to buy a 893,000 route
router just to support IPv4. If you want to support IPv4 plus IPv6
(internal only), that's
1.2 million routes.
So, I do not see that external IPv6 routing policy is driving your
router purchases in the 7 year
time horizon. Please correct me if I am wrong.
Also, aren't internal routes something you have some control over ?
I.e., isn't this something that
you are paid to do, so if they are too expensive to support you can
raise your prices,
encourage aggregation, sub-divide your network, etc. ?
Note, by the way, that even the most aggressive SHIM6 proponents
don't predict its world domination
in less than 7 years, so it's not likely to help much here.
So, as a small multi-homer, I do not see a need to support 1.3
million routes in 7 years, but I do see
a need to support 500,000 to 800,000, which may not be that different
in practice. What I frankly do not
see in all of these numbers is a reason not to support 2005-1.
Regards
Marshall
>>
>> 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
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
More information about the ARIN-PPML
mailing list