Subject: [v6ops] Draft on DC migration to IPv6

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 25 Jun 2012 07:58:50 +0000

Hi,

I've recently been at a workshop (the Carrier Cloud Summit) in which most of
the presentations and proposals still only consider v4-based solutions, with
v6 being a matter of border translation if at all, or view v6 as a long-term
issue, not considering either the problems or the new solutions it can bring to
datacenter architecture aspects.

We have recently updated a draft (draft-lopez-v6ops-dc-ipv6-02), precisely oriented
in that direction. Quoting the abstract, the document is intended to "provide a
reference framework for datacenter operators planning for a migration of their
infrastructures to IPv6. It aims to offer a scheme for evaluating different products
and architectures, and therefore it is also addressed to manufacturers and solution
providers, so they can use it to gauge their solutions".

A message from the chair notes that this draft is among those with "no
expressed interest". And since I think datacenter issues should be under the
group consideration, I'd like ask you to have a (second?) look at it.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2012 13:49:40 +0100

Diego,

I think the real problem is persuading the people who manage
data centres that there is an economic and business incentive
to support native IPv6 (as opposed to support native IPv6
customers, which they probably understand). In some cases the
arguments are technical perhaps (for example, if the load
balancers use direct server return, making the servers dual
stack will be the only reasonable approach). But in general
just showing people how to design the technical solution is
not enough for them to adopt it.

So while I understand the idea of your draft, it doesn't solve
the problem of motivation. Also I think it's unlikely that all
DCs fit the single framework you describe - surely there is
a wider range of scenarios? That's why the IETF in general
does better when documenting individual components and solutions
than when tackling frameworks.

Also there should be a clarification of how this draft relates
to draft-chkpvc-enterprise-incremental-ipv6.

Please refer to draft-carpenter-flow-label-balancing instead
of draft-carpenter-v6ops-label-balance.

Regards
   Brian Carpenter

On 2012-06-25 08:58, Diego R. Lopez wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Jared Mauch <[email-masked]>
Date: Mon, 25 Jun 2012 09:28:34 -0400

> group consideration, I'd like ask you to have a (second?) look at it.

A datacenter is usually just a managed customer CPE environment.  I'm not sure
how this differs from any other service delivery for IP, without regard to version
number.

Now my observation:
Generally the "data centers" have had a different class of equipment in there that
did not include IPv6 roadmap as part of their original RFP.

The biggest problem has been customer expectations, that one can't touch/move the service
to IPv6 capable equipment, or that the risk of upgrading the hardware is too high (or
expensive).  These are business drivers that I've seen trump a technology decision.

- Jared

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 26 Jun 2012 07:26:42 +0000

Hi Jared,

> how this differs from any other service delivery for IP, without regard to version

As said in my previous reply to Brian, this draft focuses on the aspects related
to a datacenter and considered from the datacenter operator view, discussing
aspects related to datacenter network structure and multi-tenancy, which make
them different to a simple managed customer CPE.

> expensive).  These are business drivers that I've seen trump a technology decision.

We think a framework like the one proposed in this draft would be of help to
make IPv6 requirements part of datacenter operator RFPs, and define their
service levels to customers.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 26 Jun 2012 07:26:41 +0000

Hi Brian,

> not enough for them to adopt it.

Indeed. But our point there is that providing people with a mechanism
to gauge their requirements and the proposals they get to satisfy them
can ease adoption.

> the problem of motivation.

Motivation can only come from a clear business case, and even enumerating
potential technical benefits (such as simplified load balancing, or better
overlay management) would not provide a definitive motivation. But
a better understanding of the choices should provide additional support
for particular motivations.

> Also I think it's unlikely that all

We'll probably need to refine some of the maturity levels
(especially, level 2) as experience with migrations grows,
but I believe the general framework will stay applicable, as long as
there is not a really disruptive solution, of course.

> to draft-chkpvc-enterprise-incremental-ipv6.

Essentially, draft-chkpvc-enterprise-incremental-ipv6 tries to cover all
the networking aspects in an enterprise, providing general guidances for
different migration strategies. This draft focuses on the aspects related
to a datacenter and considered from the datacenter operator view, discussing
aspects related to datacenter network structure and multi-tenancy, often
(if not always) hidden to the customer (enterprise) view.

> of draft-carpenter-v6ops-label-balance.

Will do. Thanks for the correction.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Arturo Servin <[email-masked]>
Date: Tue, 26 Jun 2012 16:25:21 -0300

Diego,

	Some questions and comments.

	The maturity level 1 is a bit odd to me. Do you mean that it is common to DC to translate all the traffic from v4 to v6 in the border? I am misunderstanding something?

	Shouldn't be a dual stack network (with servers and services in v4) a maturity level 0.5 or 1.5?

	I think also that there are some common scenarios not explored here, for example some native dual stack servers and services combined with single stack services (web server in DS + database server in v4 only).

	The maturity level 3 I think that you need to add that a single stack network is much simple to manage than a dual stack one. IMHO that will be the killer app for an IPv6 only DC.

	Also, take a look at draft-ietf-v6ops-icp-guidance, there is some content that it is already there. 

Regards,
as

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 28 Jun 2012 07:19:07 +0000

Hi Arturo,

>       The maturity level 1 is a bit odd to me. Do you mean that it is common to DC to translate all the traffic from v4 to v6 in the border? I am misunderstanding something?

The maturity level 1 corresponds to a datacenter in which all traffic it is v4-based,
and translation from and to the v6 Internet is provided at the border. Our take is
that this is the most common case nowadays.

>       Shouldn't be a dual stack network (with servers and services in v4) a maturity level 0.5 or 1.5?

If you have dual stack inside the datacenter fabric, you are at maturity level 2.

>       I think also that there are some common scenarios not explored here, for example some native dual stack servers and services combined with single stack services (web server in DS + database s…

As said in the introduction, the document concentrates in how is v6 applied in
the datacenter infrastructure, and the implications and features that this
application has. A scenario like the one you describe would only be possible in
maturity level 2.

It is true that we have not considered the different possibilities with respect
to server and services that maturity levels have. We will update the draft
including these considerations. Thanks for noting it.

>       The maturity level 3 I think that you need to add that a single stack network is much simple to manage than a dual stack one. IMHO that will be the killer app for an IPv6 only DC.

Agreed, provided that the v6 traffic grows up to a certain level and/or vendor
solutions cover your needs for the supporting datacenter fabric to be reliable to
the operator. Note that the argument of a simple stack network being easier to
manage is equally applicable to level 1. I think this is worth to be mentioned
in the text as well.

>       Also, take a look at draft-ietf-v6ops-icp-guidance, there is some content that it is already there.

Will do. Thanls for the pointer.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Arturo Servin <[email-masked]>
Date: Thu, 28 Jun 2012 09:58:11 -0300

Diego,

	Thanks for the reply.

	Just a new comment.

> that this is the most common case nowadays.

	Do you have some examples? Personally I haven't seen any (but I have seen just a few DC with v6, so I am not expert. I am just curious about the basis of your claim).

	I have seen load balancers in front of webservers, but that I think is different.

	For now the most common that I have seen are load balancers in DS and webservers in v4; and dual stack DCs where some services (i.e web, dns and sometimes email ) are in v6 and some others (legacy applications, video streaming, etc.) are in v4.

Regards,
as