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

[Owen DeLong]

I promise, last post for a while on this topic.


--On April 27, 2006 1:10:51 AM -0400 "Jason Schiller (schiller at uu.net)" 
<jason.schiller at mci.com> wrote:

> I am against this policy.
>
> It seems that people really want multi-homing badly to make IPv6 work.
>
> Heidi Hinden's first law: When you want it bad, you get it bad, and most
> people want it in the worst way.
>
Notwithstanding the fact that I have no idea who Heidi Hinden is or
why I should obey her laws... I don't think that's an accurate analysis
of the situation at all.

I think that there is a large(ish) portion of the network community
which does not remember the pre-CIDR internet and does not remember
or realize that the limitations imposed by CIDR were once viewed as
a very bad thing which broke a lot of functionality. There are a
small number of people who do remember the pre-CIDR internet.

Interestingly, both of these groups are subdivided into two groups...

In those who do not remember the pre-CIDR internet, we have group A,
mostly comprised of large(ish) ISPs who like the customer-lock-in
aspects of CIDR and don't want to let go of that marketing leverage.
These are the ones which also want to use reductio ad absurdum
arguments about the size of the mythical global routing table and
address the fact that once upon a time, the BGP table exceeded the
capabilities of the AGS+ routers available at the time.

On the other hand, we have group B, who don't remember pre-CIDR,
but, they want their PI space like they have in v4, and, they want
to be able to multi-home, and, they don't want some overly-complex
solution that requires support on far-end hosts they have no way
to influence or control.

Now, in the case of those that remember, we also have two groups.
Group C, much like group A, is largely comprised of people from
large(ish) ISPs who espouse largely the same position.  In fact,
any distinction between group A and group C is purely an academic
exercise as near as I can tell.

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.

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.

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.

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.

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.


> What concerns me are three things:
>
> 1. Enterprise customer who want PI addresses or useful multi-homing, and
> don't care about the problems it creates for the large ISPs that carry
> full routes.  (That's their problem.)
>
> In reality it is everyone's problem
> if they want to transit one of these ISPs, or use best path routing
> (carry full routes and not just a default to a transit provider).
>
> Lets not forget that router vendors are behind the curve on port speeds
> too.  Are these vendors more likely to solve the routing table problem
> that affects only the largest ISPs or focus on port speed problems that
> affect many large enterprise customers?
>
Yes, in today's architecture, if we assume that this policy will double
the number of ASNs and that the advertising ratio for v6 does come out
close to 2:1, we'll see a v6 routing table, fully deployed, of about
100,000 routes.  That's still smaller than the current v4 table, and,
that's assuming that the number of ASNs issued doubles (which I think is
unlikely in the next 10 years).

> 2. The concern people are being short sited and since there are only 1,000
> routes in the IPv6 Internet table that this will not be a problem any time
> soon.
>
No... People supporting this policy aren't looking at 1,000 v6 routes and
saying "see... v6 table has lots of room".  They're saying "Look: v6 is
failing to gain acceptance.  Further, looking at the number of ASNs in
v4, we can extrapolate that v6 will have better aggregation per ASN, and,
thus we shouldn't see more than 2:1 prefix ratio in v6. That means that
the current v4 internet could be re-implemented in v6 with less than 50,000
routes (vs. the current 180,000+)."  I don't mind that you disagree with
our argument, but, please don't call us short-sighted or ignorant
using a different argument than the one we presented.

> 3. The concern that we haven't done enough research to know if the vendors
> will be able to stay far enough ahead of the route table growth to not
> have a problem.  It is not enough for vendors to build the routers big
> enough in time.  If it takes 3 years to fully replace a network, and the
> router vendors are only two years ahead of the curve, then I only get 2/3
> through my upgrades before having to start a new set of upgrades.  Never
> mind being able to depreciate the cost of the router over 5 years.
>
I think it doesn't matter.  ISPs will route what ISPs will route.  Having
ARIN addressing policy protect ISPs from the legitimate demands of their
customers is an inappropriate use of policy in my opinion. ARIN should
neither encourage nor prohibit the routing of any prefix by any ISP.
That should be a contractual matter between the ISPs and their peers
and customers.

Having said that, I also think that the only real way to address the
true needs of the community is by coming up with a scalable routing
solution. I do not believe that any routing solution based on using
the same number for end system identifier (ID) and topological
locator (LOC) can scale.  I do think that there are possible advantages
to having some level of geographic distribution of these PI addresses
and I encourage the research and effort that is being done toward
that end at this time.  However, I hope that IETF will see this
policy (and similar discussions starting to happen in other RIRs)
and start working on a viable long-term routing protocol so that we
can deploy it before this really becomes an issue.

> We have to understand what it means to make a long term commitment to
> deaggregation.  I don't hear the six largest ISPs standing up and saying
> we did some studies of what the routing table will look like in five to
> ten years, and have talked to our vendors and we don't think it will be a
> problem.
>
You're right.  Instead, you hear a reasonable sampling of their customers
standing up and saying "We're not going to take this any more" about the
provider-lock-in based addressing of the CIDR world.


> The point Aaron was trying to make was in reference to my
> projections.  For example I want to buy new routers today.  It takes 2
> years to certify and fully deploy the router throughout the network.  I
> want the router to live in the network for 5 years to depreciate the
> value.  That means if by 2011 there is wide spread adoption of IPv6 the
> router will need to support 1.3M routes.  This example does not take into
> consideration L3VPN routes, or routes from converging multiple networks
> onto a single chassis.
>
Where on earth did you get the idea that there would be 650,000 active
ASNs by 2011?  You're going to have to work real hard to show me
any reasonable projection that predicts such a value.

If you're claiming that would be the sum of v4 and v6 routes, I would
argue that if v6 adoption is that wide by 2011, the majority of the
core would be v6 and v4 routes would become native only in local pockets.
Across the core, they would be v4 in v6 tunnels, so, the big 6 would
have alternatives to carrying both sets of routes in any one router.
Also if v6 adoption is that widespread, I think that the number of people
still using v4 would be significantly reduced if, for no other reason,
ISPs will start charging extra to preserve v4 infrastructure by then.

Bottom line, I think your projections are simply unrealistic by any
rational version of expectations for the next 10 years, let alone 5.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060427/82e58010/attachment.sig>