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

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 01 Nov 2012 23:53:04 +0000

Hi Wes,

On 31 Oct 2012, at 17:10 , George, Wes wrote:
>> 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.

So I think we are in agreement here. Let's say that we find that
considerations on the following items should be included in the draft:
* Management systems
* Fabric
* Hypervisors
* East-west communications (see below)

And comments from DC operators, to know whether they find this list
sufficient or longer than required, and which items they'd like to see
added or removed will be extremely welcome-

I'll include a reflection on this in the slides to be discussed in Atlanta

>> 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...
>>
> [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.

As saide above, the term I'd use for referring to this kind of exchanges
is East-West communication (or "East-bounbd interfaces" or similar terms),
to denotate that they run in an horizontal pattern accross the typical
representation of a DC fabric, in contrast with the communications with
origin and/or destination outside of the DC that is normally referred as
"North-bound communication" or similar terms.

So if we agree on the terminology, I certainly agree in that some more
detailed discussion on this would add to the draft contents. In fact, a few
mentions to this are scattered across the text, in a similar way as it happens
with hypervisors.

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: Arturo Servin <[email-masked]>
Date: Wed, 07 Nov 2012 09:50:30 -0500

Diego,

	A quick comment. For the section 2.3 I think one important motivation
is cost savings by not maintaining two stacks.

	Today basically we need to maintain two datacenters networks, Have
procedures to enable and secure IPv4 and IPv6, test new applications in
both stacks, etc. As datacenter admin, to maintain a single stack is a
real motivation to run ipv6 only at least for internal infrastructure
that do not interact with users (databases, application servers, VM
infrastructure, etc.)

Regards
as

On 21/10/2012 06:02, Diego R. Lopez wrote:
> 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,
> 
> --
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>