RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?
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
On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote:
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.
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. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mar 6, 2013, at 11:31 PM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote:
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.
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.
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
On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote:
I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology.
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). ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 7 Mar 2013, at 02:50, Dobbins, Roland wrote:
On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote:
I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology.
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).
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
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
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
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
participants (7)
-
Arturo Servin -
Arturo Servin -
Dobbins, Roland -
Jared Mauch -
Jerry Klonaper -
John Curran -
MAEMURA Akinori