RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?

Mailman List Mirror (Read Only)
1

Not sure how to avoid the legal entanglements my employer has placed in the
IT teams path but I'll try to provide a real-world example without
breaking confidentially agreements we all were required to sign for
continued employment at a very large US-based bank.

Our senior IT team had proposed a multi-year upgrade to v6 for our existing
internal network, external services and connectivity to partner companies
in 2009. It was fully funded in 2010, with staffing, vendor reqs and
milestones set.

At the end of 2012 our companies senior finance team reviewed the benefits
and progress. They came away with a very simple view but alas one which
could not be overcome. They held that our bank did not gain any strategic
advantage by rolling out v6 but instead now had two entire security and
software profiles to maintain.

Hence our company has "mothballed" the project and has reassigned the
entire team to other business needs. So, our globally known brand will only
keep a nominal amount of ongoing public statements of being in support of
v6 when in reality we are no longer going to deploy it until the market
demands it.

I have been employed here through two mergers and thought very hard about
leaving, as did several of us that put a lot of effort into the project.
But in the end, the job is secure, it is not my company to tell them they
are wrong and I can't fault the logic no matter how much I wish. Upon
reading this thread I'm dumbstruck at each of the arguments.

None really matter. I had to agree, there was zero gain to be found for my
company, today or in the immediate future, to proceed but there is plenty
of downside. I read the zealots comments and know that they will claim we
are fools. We, as a team, thought so too. But now several months removed,
we all actually agree with the business/finance group.

So there it is. I cannot give specifics, but a well-known global bank has
turned out the lights for now on the v6 deployment. It wasn't due to the
lack of selling to executives, as this thread contends can be done, but due
to the lack of any business case that could be found.

Jerry

2

Is the deployment in such a state that rollout can be resumed if/when it's deemed a priority?

Another possible approach might be to utilize IPv6 for BYOD wireless - it's sort of the ultimate in device segregation.

;>

3

The big problem I have (and with our own IT group) is that their network doesn't provide IPv6 yet we have offered it as a commercial service for a decade or more. This limits the ability to troubleshoot and dog-food the IPv6 network when using their resources. This means we stand up our own resources because they are unable to meet our needs. This is natural in many businesses, you work around what is broken or missing to get things done.

I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. I found banks that would return NXDOMAIN instead of NOERROR when you asked for their domain name. This caused many problems until they corrected it. I actually got in contact with someone there by calling their whois contact. Was amazed that worked, but was a happy surprise.

- Jared

4

That's a great point, but my guess is that the suits will say that since none of their customers are using IPv6, there's no urgency (yes, I know, it's better to be prepared ahead of time; but foresight doesn't generally carry much weight in quarterly-driven enterprises).

5

Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it?

  In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV.

/as

6

Presuming a medium/small service provider, the most typical sequence
that I've been hearing runs something like this:

1. Engineers internally experiment with IPv6 on an individual basis
   (lab, tunnels, virtual servers, etc.) Doesn't always happen,
   but the ones that don't are making their own gamble regarding
   their skills and career trajectory.

2. Some formal recognition by the network team of need to gain IPv6
   experience; this can be equipment for a "real" lab, formal training,
   minor investment in external firewalls to bring up to spec, etc.

3. The network folks start arranging for real IPv6 connectivity from
   the outside, this could be transit or peering, and begin working
   on plans for the "network backbone" to be fully dual-stack.

4. The "talk" with IT regarding IPv6, and acceptance of the concept
   that it would be nice if the web site had some minimal support
   (yes, maybe not the customer ticketing/feedback system, or every
   page, but at least the major content sections.) This leads to
   the idea that IT will test new web rollouts with IPv6, and the
   need therefore to get IPv6 to some of the integration/QA folks.

5. IT/internal network team realization that they have to get IPv6
   internally to some of the Internet network team, some of the
   developers, and that means that the "corporate" network really
   does need to support IPv6, and that means those firewalls, and
   management and training for the internal corporate network team.

6. Several meetings with marketing and sales trying to explain that
   other organizations (i.e. customers are doing the same thing, and
   a general mismatch in expectations since the vast majority of
   customers have never uttered "IPv6" to anyone in sales/marketing.

7. Slow but steady internal progress on IPv6 deployment in the company,
   all while waiting for sales/marketing to recognize the need for IPv6
   services for customers.

8. One key event (often a customer RFP requirement, or a sale lost due
   to lack of IPv6 support) occurs, which then brings the lack of IPv6
   into focus as a competitive issue, and subsequent discussions about
   budget/investment for adding IPv6 support to the service catalog.

YMMV, and every organization is a little different, but the common theme
is that the more awareness that we can generate in CIO/IT industry about
the IPv4 constraints facing the Internet network industry, the faster
that IPv6 will happen...

/John

7

Pretty much the same process that I have seen in many ISPs and enterprises.

Regards.
as

8

Same here in Japan. Pretty much agree on what John has listed.

I observe that recognizing two things is important:

* IPv6 will definitely be needed in not-near future, thus the preparation is definitely needed
* An immediate justification for big investment is nearly impossible

The ISPs and carriers who are successful to deploy IPv6 started from this point and taking steps like 2) and 3) with very small investment and obtain the skills within the engineers which later helped much to have the company light a green signal for official launch. It took years.

Cheers,
MAEMURA Akinori

(2013/03/07 22:48), Arturo Servin wrote: