[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
44/8
----- On Jul 22, 2019, at 5:54 PM, Owen DeLong owen at delong.com wrote:
Hi Owen,
>> On Jul 21, 2019, at 12:28 , Sabri Berisha <sabri at cluecentral.net> wrote:
>> Only when it becomes cheaper to go IPv6 than to use legacy V4 will V6 be adopted
>> by large corporations. Well, the ones that are governed by beancounters instead
>> of engineers. And by that time, I'll be charging $500/hr to assist $CORP with
>> their IPv6 migration plans.
>
> I can guarantee you that Akamai is very much run by beancounters in addition to
> engineers. I have first hand experience with that.
>
> I can also assure you that itâ??s quite unlikely that any of Comcast, Netflix,
> Facebook, Google, AT&T, T-Mobile, or Verizon just to name a few of the biggest
> are managed without due consideration of input from the bean counters. (Iâ??d bet
> at each of those companies, the day that engineer beats beancounter in a
> disagreement is rare, indeed).
Sure! Facebook and Google were (are, I can only presume) still dominated by
engineers, not beancounters.
The other companies you mentioned have little choice; they are consumer ISPs and
are faced with a simple truth: IPv6 or a line-item for "IPv4 purchase" on the budget.
> The problem with the approach you are taking to IPv6 cost-benefit analysis is
> that your claim of no ROI doesnâ??t actually hold true.
It does, it just depends on the organization.
And don't get me wrong, you're preaching to the choir here. I am very much in favor
of deploying v6. I just have had and still have a hard time getting the resources to
do so. As long as the vast majority eyeballs have IPv4, whether via NAT or native,
non-subscriber platforms will be able to function. deploying IPv6 is seen as one of
the "cool" projects, not a "business critical" one.
Facebook and Google were founded at a time where IPv6 was hot and on engineers' radar.
Their networks were built from scratch with IPv6 and scalability in mind, and
beancounters don't rule those orgs.
Here is how I imagine things go at Comcast etc:
Comcast Engineer: we need IPv6, will cost $bagsofmoney.
Comcast Beancounter: impossible. What's the justification?
Comcast Engineer: we will run out of IPv4 and will be unable to add subscribers, and
thus grow, and thus increase our marketshare.
Comcast Beancounter: approved.
Here is how things go in my experience:
Content Engineer: we need IPv6, will cost $bagsofmoney.
Content Beancounter: impossible. What's the justification?
Content Engineer: well, sometime in the future someone will deprecate IPv4 and all
eyeballs will only have IPv6.
Content Beancounter: when is that going to happen?
Content Engineer: I don't know, for now they're using dual stack and all kinds of
translation mechanisms.
Content Beancounter: come back when it becomes a necessity instead of a luxury.
I had that conversation in multiple organizations. According to Google,
https://www.google.com/intl/en/ipv6/statistics.html, even today among the eyeballs the
adoption rate is a poor 30%. And that graph is not looking like a hockey stick either.
It's still very much a chicken and egg problem, in a lot of networks.
Unless we come up with a real hard deadline (like we had with y2k), there will always
be organizations that won't make the investment. It's either that or wait for a natural
tech-refresh, like we've been doing for the last 20 years.
Sad, but so far this has been my experience. And again, I wish that things were different.
Let's pick 6/6/2026 as IPv4 shutdown day.
Thanks,
Sabri
JNCIE #261
- References:
- 44/8
- From: msa at latt.net (Majdi S. Abbas)
- 44/8
- From: owen at delong.com (Owen DeLong)
- 44/8
- From: bill at herrin.us (William Herrin)
- 44/8
- From: jra at baylink.com (Jay R. Ashworth)
- 44/8
- From: bill at herrin.us (William Herrin)
- 44/8
- From: aled.w.morris at googlemail.com (Aled Morris)
- 44/8
- From: sabri at cluecentral.net (Sabri Berisha)
- 44/8
- From: owen at delong.com (Owen DeLong)
- Prev by Date:
44/8
- Next by Date:
44/8
- Previous by thread:
44/8
- Next by thread:
44/8
- Index(es):