IP4 Space

Fri Mar 26 21:25:30 UTC 2010

On Friday 26 March 2010 02:10:45 pm Mark Andrews wrote:
> In message <201003261157.23601.lowen at pari.edu>, Lamar Owen writes:
> > "Hey, great presentation.  Compelling arguments.  But I have one
> > question: will our existing gear that's not yet fully depreciated handle
> > it?  No? 

> What percentage of your equipment already supports IPv6?  Most 5 year old
> pieces of equipement already have IPv6 support.  It just needs to be
> enabled.

While my hypothetical answer was intentionally worst-case, with just-barely-
too-old hypothetical hardware being mentioned, in reality my situation is 
dealing with in some cases much older equipment.  I could go into detail, but 
you guys don't want to read my pity party, I'm sure.  

But "supporting IPv6"  and "handling it [dual stack with comparable 
throughput]" are two different things.

> > No, we cannot afford to forklift upgrade now.

> IPv6 is *not* a "forklift upgrade".  

I have few routers that will do IPv6 at all, and even fewer that will do it 
efficiently. Where we have layer 3 switches, none will do IPv6 in hardware, and 
only one will do it in software (OSR 7609).  For us, efficient dual-stack is a 
forklift upgrade.

> Turning on IPv6 doesn't really affect the amount of bandwith you use.

Not my point; if I have to spend on hardware/software upgrades (both being 
expensive, especially for out-of-contract hardware), then that's less dollars 
we have to spend on bandwidth.  Thus I lower my bandwidth, and spend that 
previously-opex money on capex instead.

[snip]

Don't misunderstand; we are and have been working on our plan for rolling out 
dual-stack, and I hope to have an IT intern this summer who will do the grunt 
work. 

I'm just having to try to be frugal when doing so, and with an understanding 
of the limitations of our older gear; I don't plan on being bit by some 
surprise 'feature' on one of our arcane pieces of gear. Once we understand 
what can do what and how fast it can do what it does, then we can 
intelligently redeploy equipment to produce the least pain at the least cost 
when IPv6 is enabled on it.  And if we have to purchase some newer kit, well, 
we'll cross that bridge when we come to it.  It will be a tough sell when we 
come to that bridge.

For instance, terminating a slow MetroE on Cisco 12000 1 port GE.  Overkill, 
on first glance, but not when you factor the actual IPv6 performance on that 
linecard.  And if already have that gear, fully amortized, then you've reduced 
your implementation cost (maybe not opex, but it would take a lot of reduction 
in opex to offset the reduction in capex), and thus made it more likely to 
happen.

> > At the CxO level, it's all about the money.  Or the lack therof.

> Turn on IPv6 should be a $0 cost.  Fully supporting IPv6 on all the
> services you offer will have some cost.

Nothing is $0 cost.  Time is money, after all.

But I do appreciate all the advice I have gleaned from NANOG and c-nsp over 
the years on the various and sundry ways people have performed the 'addition' 
of IPv6 to their IPv4 networks.  And I thank all those who have shared their 
experiences; even if it didn't help anyone else, it has helped this non-profit.

And while I understand most of the issues involved in the negative impact of 
not going dual-stack, and am in full agreement that we need to do so, I still 
have to look at the economic reality of the situation.  

Yes, in order to get this done in this economy you (or your department head, 
or whatever) have to get your CIO/CTO and maybe the CEO on board (typically 
the CIO would get the CEO on board).  But even with them on board the costs 
may be greater than the bottom line can currently bear.  And to get the CxO's 
on board you have to speak the C language....no, not that C, but the language 
of the CxO.  And that's dollars and cents; cost-benefit, etc.  Business 101.

Having said all that, we are well on the way to getting the equipment 
selection phase (among equipment we already have on hand or in service) 
completed.  We know what equipment we have that will definitely not work, and 
we know what equipment we have on hand that definitely will work.  Now we have 
to determine how well that workable equipment will work, and if there are ways 
to continue to use some of the equipment that is in service, but not able to 
handle IPv6.