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

[Marshall Eubanks]

Hello;

On Apr 28, 2006, at 10:57 AM, Jason Schiller (schiller at uu.net) wrote:

> 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

ACK. I hadn't quite parse it that way, which makes things a bit clearer.

> 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.

See above.

>
>
>>
>>> 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.
>

Me too.

> 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?
>

Well, that is the other piece of this puzzle, and I would love to see  
some
projections of router capacities.

> 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.

Sure.

Note that in all of this conservatism there is something an internal  
contradiction - we (me for sure, and I
think you too) assume that, while IPv6 is adopted, it never really  
replaces v4. All boxes are eventually
on both a v4 and a v6 path (in this conservative model), which must  
break down at some point (else,
why adopt v6 ?). (This breakdown could take many forms - running out  
of room in IPv4, killer aps in IPv6,
even an abandonment of v6 for something else, but for sure the factor  
of 1.5 won't last forever.)

>
>> 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?

As I said in another post, I don't see how you can get more  
conservative than that. I am
trying for upper bounds, because I think that we can do that.

My experience tells me, anyway, that if we are grossly off, it will  
be because of things we
totally do not anticipate.

>
> What about Europe, Asia, Latin America, Canada??
>

That's the global economy part. I am assuming something about the  
size of these other economies and
how it scales to IP address requirements -
effectively, that in the US, X employees means PI space, abroad, Y  
dollars of revenue mean PI space.

However, this is resolutely BOTE (back of the envelope), and, I would  
strongly argue, that is literally
all you can do when you start talking about 10+ years off.

> 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.
>

And maybe that will happen. Don't know, but I bet that if it does the  
3G and 4G people will solve this
at "Layer RF".

The real question is when. The only firm things we know are the  
current usage and the current doubling time.
My running through the numbers convinced me that the position that  
Vince Fuller forcefully argued at
lunch is correct, and this growth will continue throughout most of  
the the rest of careers, if not our natural lives.

So, unless there is a reason for the growth to become  
hyperexponential (with a doubling time for the doubling time), the  
end numbers are almost irrelevant; we literally may never live to see  
them.
The growth, which we can predict, will likely continue throughout any  
reasonable time horizon for
equipment purchases. If the equipment won't keep up, and the  
protocols can't be modified (link state BGP anyone?),
then there is indeed a problem.

>> 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.

Is there any prospect that TE will become unnecessary ?

>
>> 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.

Is 7 years a magic number ? I thought that at the larger ISP's there  
was a natural cascade, where
today's core routers are tomorrow's regional routers and continue to  
move out the edge as they age.
Is that no longer done or realistic ? Aren't there other things, like  
constantly increasing
bandwidth usage, that also makes routers obsolete ?

>
> 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.
>

Is 8+8 still on the table ? This came up at RIPE, but I thought that the
answer was no.


> ___Jason
>

Regards
Marshall


>