Subject: [v6ops] In the vein of of the icp/dc guidance

From: Joel jaeggli <[email-masked]>
Date: Tue, 17 Apr 2012 10:37:34 -0700

This was presented at ripe64.

https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2012 08:12:28 +0100

It's fine work IMHO, but I expect that most DC operators will
not want to jump in at the deep end in this way.

Regards
   Brian

On 2012-04-17 18:37, Joel jaeggli wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 18 Apr 2012 09:32:03 +0200 (CEST)

> not want to jump in at the deep end in this way.

Agreed. DC operators are very conscious of deploying new technologies: 
- Capable IPv6 load balancers
- Stateless IPv4/IPv6 translators
- stastics gathering - update for translated IPv6/IPv4 addressess
- Hosted Application with full IPv6 capability

The biggest challenge will be the users who use DC for hosting...

Best Regards,
 		Janos Mohacsi

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 18 Apr 2012 10:17:12 +0200

> not want to jump in at the deep end in this way.

I like the idea too.  But hosting operators will be very cagey about
deploying client-side ipv6 when there is no clear precedent for operating
reliable ipv6-only services, where there is an absence of good quality
ipv6-only monitoring tools, and where many of the software development
companies are still saying "we'll make our products ipv6 aware when we get
some customer demand".

Nick

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 18 Apr 2012 08:20:01 +0000

I think, IPv6-only data centre is a good approach. The most general case would be a DC operator build up a new IPv6-only DC parallel with the existing IPv4 DC. Dual stack DC is too complicated for DC internal or transition purpose.

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, April 18, 2012 3:12 PM
> To: Joel jaeggli
> Cc: IPv6 Ops WG
> Subject: Re: [v6ops] In the vein of of the icp/dc guidance
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Apr 2012 17:42:56 +0000

In the process of planning the migration of operators' customers to IPv6, those operating (both private and public)  data centers asked operators for advice on both interim and permament solutions, stages to customers and some reference to compare different proposals they can get from their providers. Not to mention that operators are provindig datacenter services as well. The idea of http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/  is to provide a reference framework for DC migration into IPv6 and discuss the essential issues at each stage. Datacenter and network operators willing to evaluate the options for DC infrastructure migration to IPv6, as well as technology providers interested in positioning their solutions.

Sent from my iPad

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 00:33:19 -0700

On 4/18/12 01:17 , Nick Hilliard wrote:
> ipv6-only monitoring tools,

So I have to take issue with that statement. the instrumentation I use
for v6 enabled assets in datacenters is by-in-large the same as I use
for ipv4. the gap analysis is beginging to look rather narrow in fact.

> and where many of the software development

excluding them from consideration tends to get the message across...

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 00:44:43 -0700

> not want to jump in at the deep end in this way.

Having a little trouble making internal numbering plan fit in a /12 per
site. Hakes alternatives oddly compelling...

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Apr 2012 08:48:19 +0100

> site. Hakes alternatives oddly compelling...

Is the small size of IPv4 subnets also an issue? /64 is
approximately infinity, after all.

   Brian

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 01:10:54 -0700

On 4/22/12 00:48 , Brian E Carpenter wrote:
>> site. Makes alternatives oddly compelling...
> 

When you are trying to conserve bits, the number of hosts per subnet
drives the mask size directly which as you can imagine can become costly
in a number of ways.

I'm not sure I'd characterize a /64 as infinite, but you're not going to
need to expand it on the basis of host count.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 22 Apr 2012 12:14:17 +0100

> excluding them from consideration tends to get the message across...

I agree in theory - and include ipv6 feature parity in all product
evaluations, and whine/bitch at vendors who have a lax ipv6 attitude - but
excluding them from consideration also tends to put the DC operator at a
competitive disadvantage as it removes product choice for ipv4 services.
This can have a direct impact on revenue, customer retention and all that.
 IOW, we're not there yet.  For sure, we're a lot better now than we were a
couple of years ago, but for many areas/products/services the disparity is
still large enough that ipv6-only services are not a viable option.

Nick

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 22 Apr 2012 10:29:18 -0700

> competitive disadvantage as it removes product choice for ipv4 services.

7 or 8 years ago, people would laugh when I'd put that in an RFP. It
ceased being funny a long time ago. Today we have to build, instrument
and manage IPV6 and IPV4 networks and we expect to have a lot more of
the former if we're lucky or smart enough to stay in business. The tools
have to keep up.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 23 Apr 2012 11:03:50 +0200

* Nick Hilliard

> evaluations, and whine/bitch at vendors who have a lax ipv6 attitude
> - but excluding them from consideration also tends to put the DC
> operator at a competitive disadvantage as it removes product choice
> for ipv4 services. This can have a direct impact on revenue, customer
> retention and all that. IOW, we're not there yet.  For sure, we're a
> lot better now than we were a couple of years ago, but for many
> areas/products/services the disparity is still large enough that
> ipv6-only services are not a viable option.

Hi,

I'm glad you found my presentation interesting enough to discuss. :-)

I agree with you both, actually. We're not religious about IPv6, so we
would certainly not turn down a customer who wants us to manage a
solution that have components that will either only work with IPv4, or a
solution that can not work through stateless translation (so it would
have to run either dual-stacked or IPv4-only).

On the other hand, in order to cater to these customers we need IPv4
addresses, which are in short supply. So even though we cannot
realistically do IPv6-only and stateless translation for *every*
customer, it still makes a lot of sense to do it where we can, so we can
save those precious IPv4 addresses for use where they are absolutely
necessary. And, as it happens, the most of of our customers are running
some HTTP-based application on top of a mostly open-source software
stack. IPv6 tends to be well supported; I reckon that the customers who
are running applications with hard IPv4 dependencies are in the minority.

As an added bonus, maintaining those IPv6-only customers' servers and
applications gives pretty much the same low operational complexity as
IPv4-only operation has. And it requires no stateful devices in the
critical network path. To the best of my knowledge, IPv4-only operation
is the only other option that will provide these two extremely desirable
traits.

In any case, the talk itself goes into more detail about our thinking
than the slide deck, so in case you have 45 minutes to kill, the
recording is available at https://ripe64.ripe.net/archives/video/37/.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com