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

[MAEMURA Akinori <maem () maem org>]

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:
>         Pretty much the same process that I have seen in many ISPs and enterprises.
>
> Regards.
> as
>
> On 07/03/2013 11:32, John Curran wrote:
> > On Mar 7, 2013, at 5:42 AM, Arturo Servin <aservin () lacnic net> wrote:
> >
> > >         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.
> > 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