[161308] in North American Network Operators' Group
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (John Curran)
Thu Mar 7 08:33:16 2013
X-Report-Abuse-To: abuse@dyndns.com (see
http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse
reporting information)
From: John Curran <jcurran@istaff.org>
In-Reply-To: <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net>
Date: Thu, 7 Mar 2013 08:32:37 -0500
To: NANOG General Mail List <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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=20
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=20
their skills and career trajectory.
2. Some formal recognition by the network team of need to gain IPv6=20
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=20
the idea that IT will test new web rollouts with IPv6, and the=20
need therefore to get IPv6 to some of the integration/QA folks.
5. IT/internal network team realization that they have to get IPv6=20
internally to some of the Internet network team, some of the=20
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=20
a general mismatch in expectations since the vast majority of=20
customers have never uttered "IPv6" to anyone in sales/marketing.
7. Slow but steady internal progress on IPv6 deployment in the company,=20=
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=20=
into focus as a competitive issue, and subsequent discussions about=20=
budget/investment for adding IPv6 support to the service catalog.
YMMV, and every organization is a little different, but the common theme=20=
is that the more awareness that we can generate in CIO/IT industry about=20=
the IPv4 constraints facing the Internet network industry, the faster=20
that IPv6 will happen...
/John
