[ppml] Policy Proposal 2005-1: Provider-independent IPv6
Jason Schiller (schiller@uu.net)
jason.schiller at mci.com
Fri Apr 28 10:57:22 EDT 2006
Yeah! someone else is actaully thinking about the long term implacations
of PI. :-) These are the types of discussions that need to be fully
flushed out before we all commit to embarking on this path.
On Fri, 28 Apr 2006, Marshall Eubanks wrote:
> (I realized that I incorrectly included the intentional de-aggregates
> in the 7 year table at the bottom here, which messed up the table
> thoroughly, so I am just resending this with those numbers plus a typo
> corrected. It doesn't change much, and actually improves the
> agreement with my estimates. Please
> just disregard the previous version, and accept my apologies for the
> excess bandwidth.)
>
> 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.
Yes, I agree, but I can't figure out how to measure this.
My number assume that all non-contigous blocks from a single AS will be
replaced with one block... this may be too agressive. Take the case
where a single AS exists as 2 seperate stub networks connecting to
two upstream ISPs. Each stub has a non-contigous /24. In IPv6 we give
them a /48, but they will still announce two routes. My calculations
assume only a single route. The same might be true for a single site with
two non-contigous /24, if given a /23 they might still announce 2* /24s
for traffic engineering purposes.
>
>
> >
> > 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.
I'm not sure I follow here... the CIDR report shows 179503 routes, that
could be aggregated down to 118693 routes. that meanse 118693 routes
can't easily be aggregate today, but 60837 could be aggregated. To say it
another way 60837 are intentionally not aggregated.
>
> > 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.
sorry yes, 1.3M in 7 years
>
> I actually think that these numbers are not too far out of line; the
> question is, is the
> time line out of line ?
>
The question I am trying to answer is in the long term when there is wide
spread adoption of IPv6 how bad is de-aggregation as a solution for PI and
multi-homing. What would it mean if wide spread adoption happend by
tomarrow? By 7 years from now? and so on.
The next question is do you want to commit to the course of action and
risk the health of your network on faith that routers big enough will be
ready soon enough?
Your numbers are interesting, can you provide 5, 7, 10, and 14 year
numbers? These are the numbers that are interesting to me when discussing
router purchasing.
> 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.
>
So all small business will either not multi-home or will use the limited
functionality of shim6 when it is available?
What about Europe, Asia, Latin America, Canada??
Suppose I built a scenerio like this. There are 1 billion people in
China. 10% of them have a cell phone. Thats 100 million cell
phones. One quarter of these phones will run IPv6, and want mobility. As
IETF hasn't solved the mobility problem yet, lets use PI addresses to make
mobility work. As long as each phone get a PI /64 and advertises it to
their particular Cell provider or particular cell tower, then roaming just
works. Thats 25 million new routes in the table.
> 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.)
>
You raise an interesting question that i suspect ARIN will not address,
should multi-homers only get one slot in the global routing table
(i.e. 1* /48) or multiple slots to allow for traffic engineering. My
predictions certainly assume multiple slots, and would be less agressive
If there was only one slot. This would make the IPv6 table as large as
the number of ASes in the system which as you point out is linear not
quadratic. :-), but this also does not solve the traffic engineering
problem.
> 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 : 339,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 : 576,000 ( 41 % are IPv6)
> Total Internal (low) : 181,000
> Total Internal (high) : 764,000
>
> Totals (low) : 825,000 ( 29 % are IPv6 external)
> Totals (high) : 1,340,000 ( 18 % 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, an
> amazing agreement
> for anything back of the envelope.)
>
> 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 699,000 route
> router just to support IPv4. If you want to support IPv4 plus IPv6
> (internal only), that's
> 1.1 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.
Assume I have to purchase ne routers today. Are the routers I can buy
today big enought to not be upgraded in 7 years. And again in seven years
time, are the routers I can buy big enough to not need to be upgraded in 7
years.
Yes it is a factor of a bunch of things, and worst offender is IPv4 the
IPv4 Internet table. But the IPv4 de-aggrgegates for traffic engineering
are growing at a faster rate than the total IPv4 table. And sure you can
prevent IPv6 for inheriting this growth by making it commonly accepted
policy that any ASN should only advertise a single aggrgegate to the
Internet table.
Shim6 might ease this a bit when its available for people who haven't
already adopted BGP based traffic engineering. 8+8 GSE may ease this a
bit more for people who haven't already adopted BGP based traffic
engineering and need complex traffic engineer capabilities.
___Jason
More information about the ARIN-PPML
mailing list