All of this assumes "normal hardware refresh cycles" That may be the
case for ordinary office users but I got a million dollar asphalt kiln
attached to a Windows 98 controller with a serial port that says
otherwise.
Just wanting to point out that "normal hardware refresh cycles" more
often comes out of the mouth of the salesguy wanting to sell you
something than out of the network manager. Most of them will say "if it
ain't broke don't fix it" first.
And switching infrastructure tends to be pretty bulletproof if you
buy good hardware to start with. I've got a lot of customers with
switch infrastructure that hasn't changed in years.
"normal hardware refresh cycles" is something the Fortune 1000 have.
It's a nice concept but not one universally adopted by everyone else in
the real world. Another one of these is "hardware service contracts"
That's not universally adopted, either.
Ted
On 4/2/2015 3:04 AM, Mikael Abrahamsson wrote:
On Fri, 27 Mar 2015, Phil Mayers wrote:
I don't believe the rollout cost was high. We used refresh cycles to
upgrade to v6-capable gear, and rolled out slowly to grow our team
knowledge. But we don't have detailed cost breakdowns.
This is my experience as well, if someone already has decided to employ
skilled people and tell them (or gave them fairly free hands) to have
IPv6 enabled on most services in the "next few years", then this will
happen without very little extra cost.
If one decides that "We need IPv6 on services in the next 6 months" then
there'll be lots of extra truck rolls and immediate capex and opex if
this has not been taken into account previously.
It takes 3-5 years to get IPv6 running with minimal extra cost, then it
can be done as part of normal hardware refresh cycles and slowly
increasing exposure to IPv6 by staff. So the entities who have not
started yet and want to get started quickly will have to face increased
cost.
I was involved in IPv6-enablement of a fairly large ISP and in 2007-2010
most of the groundwork was done going full native IPv6 instead of
tunnels etc, testing all platforms, working bug cases with vendors that
had software bugs, waiting for the fixes, testing again, then looking at
the next aspect like IPv6-enabling one of the services with friendly
users, run that for a while, then turning on more customers, enabling
more services etc. The earlier one starts, the more can be done over
normal upgrade cycles of software, you can help the vendor to get
everything done in a way that'll actually for for you.
Another strategy is to wait until everybody else has done this work and
hope you were in luck with the things you purchased and that it'll just
work out of the box without any preparation. This is also a valid
strategy, as long as not everybody does this :)
