[ppml] Policy Proposal 2005-1: Provider-independent IPv6
Jason Schiller (schiller@uu.net)
jason.schiller at mci.com
Thu Apr 27 01:10:51 EDT 2006
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.
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?
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.
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.
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.
(Leo this is your cue to say this will only affect about 6 ISPs and maybe
the world is better off without them.)
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.
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Public IP Global Network Engineering schiller at uu.net
UUNET / Verizon jason.schiller at verizonbusiness.com
The good news about having an email address that is twice as long is that
it increases traffic on the Internet.
On Wed, 26 Apr 2006, Arin Archive wrote:
> Date: Wed, 26 Apr 2006 02:15:53 -0400 (EDT)
> From: Arin Archive <arin at sprint.net>
> To: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2005-1: Provider-independent IPv6
>
> I am against this policy.
> It appears that most people at the last want to make a policy for policy's
> sake. There are many other things that haven't been looked at in addition
> to just IPv4 and IPv6 tables. I haven't heard or seen any studies of the
> impact that VPNs have in addtion and even get more nervious when
> discussions on PEv6 are brought up. As others have mentioned, historically
> temporary solutions aren't. I believe that we are making the same mistakes
> as we did when v4 was first rolled out with a /48 out of a reserved /44
> per PI request. How large is this PI swamp that is being proposed?
> If 2005-1 is repealed, how will the space be returned without litigation?
> Odds are that it won't and we'll be forced with it with no recourse.
>
> Aaron Dudek
>
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
More information about the ARIN-PPML
mailing list