Subject: [v6ops] New version of draft-lopez-v6ops-dc-ipv6

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 21 Oct 2012 10:02:52 +0000

Hi,

This new version incorporates all the changes discussed in Vancouver,
being the most salient a title change and the renaming of the "maturity
levels" (and their numbers) into named "transition stages", plus more
elaborated text for examples at each transition stage, and a first full
attempt for the security considerations.

http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6

Diff http://www.ietf.org/rfcdiff?url2=draft-lopez-v6ops-dc-ipv6-03

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: "George, Wes" <[email-masked]>
Date: Fri, 26 Oct 2012 10:54:12 -0400

I've read this version of the draft, and I have a few comments.

I would not refer to your last transition stage as "Next Generation" as that is not a particularly descriptive term for the stage that you describe, and it is also a fairly overloaded term - my "next generation" DC may well be the one where I increase the bandwidth, or build out a fabric, start using some new widget, or whatever. I would maybe call it IPv6-only or Single-stack IPv6, since that is really the desired end state, where as much of the DC as possible is running IPv6 for all functions, and IPv4 connectivity is handled via transition and translation technologies at the edges of the DC (eg loadbalancers, etc).

Section 2.3 should mention the fact that this stage may be driven by either a lack of enough IPv4 resources (whether private or globally unique) or a need to reclaim IPv4 resources from portions of the network which no longer need them. There is a point at which dual stack is simply not possible anymore, and once that point has been reached, a careful evaluation of what still needs to speak IPv4 and what does not will need to happen to ensure judicious use of the remaining IPv4 resources.

It might also be helpful to discuss the different classes/categories of things that are in an average data center, as those may have a bearing on how the transition proceeds, and indeed may be at different phases of the transition at different times:

Management systems (provisioning, alarms/PMs, software distro, etc)
Fabric (and perhaps even discuss the different layers, ToR, agg, core, etc)
Hypervisor (though this is already mentioned in a few places in the draft)
Machine-to-machine communications (one application talking to another over an API)
End-user applications/content
External services
Etc

The key here is to keep it generic enough so that it's widely applicable, rather than getting so specific that you have to have multiple different scenarios to represent different potential DC applications and designs.

Security considerations: draft-vynke-opsec has been replaced by draft-ietf-opsec. However... The referenced draft covers a lot of ground, and simply referring to it by itself might be daunting to potential readers. It might be worth highlighting specific sections that are especially pertinent to DCs, such as the discussion of ND cache exhaust, etc.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Diego R. Lopez
> Sent: Sunday, October 21, 2012 6:03 AM
> To: IPv6 Ops WG
> Subject: [v6ops] New version of draft-lopez-v6ops-dc-ipv6
>
> Hi,
>
> 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:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 30 Oct 2012 15:33:47 +0000

Hi Wes,

Thanks for the comments. A few more detailed replies inline

> I would not refer to your last transition stage as "Next Generation" as that is not a particularly descriptive term for the stage that you describe, and it is also a fairly overloaded term - my "ne…

It makes sense, though I can understand that using something we could call
an euphonic name would help in sending the message that's the desirable
stage to achieve. I'd suggest to have some live discussion about this in
Atlanta...

> Section 2.3 should mention the fact that this stage may be driven by either a lack of enough IPv4 resources (whether private or globally unique) or a need to reclaim IPv4 resources from portions of…

Agreed. Mentioning this will add more weight to the reasons to achieve this
stage. Will update the document in this respect.

> The key here is to keep it generic enough so that it's widely applicable, rather than getting so specific that you have to have multiple different scenarios to represent different potential DC appl…

This is a good point, though I think we should agree in limiting the number
of such items, and clearly identify how the application of v6 affect them and
in which respect they are specific to the DC environment. Certainly
management systems are, as considerations on the fabric and hypervisors.
In the case of end-user applications and content I think they are mostly considered in other operational guideline: (draft-chkpvc-enterprise-incremental-ipv6) and we could follow an approach similar to the used in
the security considerations.

When it comes to M2M and external services, I'd like to have a clearer idea
of what you are referring to...

> Security considerations: draft-vynke-opsec has been replaced by draft-ietf-opsec. However...

Right. Will correct.

> The referenced draft covers a lot of ground, and simply referring to it by itself might be daunting to potential readers. It might be worth highlighting specific sections that are especially pertinent to DCs, such as the discussion of ND cache exhaust, etc.

That certainly makes sense. Will take care of it for the coming version

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "George, Wes" <[email-masked]>
Date: Wed, 31 Oct 2012 12:10:58 -0400

> From: Diego R. Lopez [mailto:[email-masked]]
>
> This is a good point, though I think we should agree in limiting the
> number of such items, and clearly identify how the application of v6
> affect them and in which respect they are specific to the DC
> environment. Certainly management systems are, as considerations on the
> fabric and hypervisors.
[WEG] Yes. That's a good test to use. There's a lot of risk in getting too specific and to specialized here, so feedback from DC operators on a set of categories that make sense will be very helpful.

> In the case of end-user applications and content I think they are mostly
> considered in other operational guideline: (draft-chkpvc-enterprise-
> incremental-ipv6) and we could follow an approach similar to the used in
> When it comes to M2M and external services, I'd like to have a clearer
> idea of what you are referring to...
>
[WEG] I can try to clarify a bit -
M2M - At least in my company's systems, have a fairly modular design to the applications that we use, so we end up with a lot of applications that have one set of functions, but make API calls to other applications within the data center for additional information that they require to complete their intended function. These machine-to-machine communications are a good place to experiment with moving to IPv6, especially when you have control over both of the applications (vs one where you're making calls to an API on an externally managed system for example). This is because assuming you have an IPv6-capable fabric in place, and the underlying VM infrastructure supports IPv6, it may be as simple as changing a few DNS entries to add AAAA records, and the traffic going between these applications will begin using IPv6 in a way that is relatively straightforward from a control and rollout perspective because you are not dealing with the variable that any sort of human user might introduce - it's two applications talking to one another directly. It is worth noting that in some cases these are not necessarily contained completely within one datacenter, so you could make a distinction between those that stay within a single data center vs those that must communicate between datacenters.
External services refers to any sort of applications that are providing services consumed outside of the datacenter (vs those like I outlined above).
Hopefully that helps. I know that M2M is also an overloaded term, and I didn't exactly use it in the traditional sense, so I apologize for any confusion I may have caused.

Wes George