IP4 Space
Lamar Owen
lowen at pari.edu
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.
More information about the NANOG
mailing list