Subject: [v6ops] draft-ietf-v6ops-dc-ipv6-01.txt WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 9 Mar 2014 11:00:23 -0700 (PDT)

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6-01.txt.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 05:36:37 +1300

Since I am not a DC operator, I can't really comment on the
general value of this document.

However, I do want to *strongly* suggest removing the reference
to RFC 6294 (of which I am a co-author). The use cases described
in that document are mainly incompatible with the flow label
standard (RFC 6437). In fact it was just a historical review before
we worked on RFC 6437.

I also suggest stressing that firewall deployments should provide
correct treatment of ICMP (RFC 4890) and extension headers (RFC 7045).

Regards
   Brian

On 10/03/2014 07:00, Fred Baker wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tore Anderson <[email-masked]>
Date: Sun, 16 Mar 2014 09:01:02 +0100

* Fred Baker

> believe it to be of operational utility, that is also an important

Hi,

I've read through this document and find it rather low on meat, to be
honest. It uses a lot of words, but doesn't say very much.

These are just a few examples randomly picked:

>  Furthermore, the combination of the regularity and controlled
>  management in a DC interconnection fabric with IPv6 universal end-to-
>  end addressing should translate in simpler and faster VM migrations,
>  either intra- or inter-DC, and even inter-provider.

Okay...but what about explaining how exactly IPv6 will make VM migration
faster? In my experience, this is something that is entirely dependent
on available bandwidth, not the IP version.

>  o  During VM migration (intra- or even inter-DC), Mobile IPv6
>     mechanisms can be applied to keep service availability during the
>     transient state.

That sounds really cool! But...how?

>  At this stage, the advantages outlined above on load balancing based
>  on flow labels and Mobile IP mechanisms are applicable to any L3-
>  based mechanism (intra- as well as inter-DC).  They will translate
>  into enhanced VM mobility, more effective load balancing, and higher
>  service availability.  Furthermore, the simpler integration provided
>  by IPv6 to and from the L2 flat space to the structured L3 one can be
>  applied to achieve simpler deployments, as well as alleviating
>  encapsulation and fragmentation issues when traversing between L2 and
>  L3 spaces.

Again this fuzzy reference to making novel use of Mobile IP somehow
without going into any detail. Oh and what are these "encapsulation and
fragmentation issues" that IPv6 purportedly solves?

>  o  Development.  When a new device or app version is released, it
>     must be tested three times: IPv4, dual-stack, and IPv6-only.
>     Though this does not imply a triple the effort once the
>     development environment is set up, a general estimate is that it
>     implies a 10% additional cost.
> [...]
>  o  Network management.  The incremental costs of managing two L3
>     network plane would come at around a 10% incremental cost.
>
>  In summary, a full dual-stack datacenter would come at an additional
>  5-10% operating cost than a single-stack one.
> [...]
>  Depending of the complexity of the DC network, provisioning and other
>  factors we estimate that the extra costs (and later savings) may be
>  around between 15 to 20%.

Where does these percentages come from? There's no reference to a study
or anything like that as far as I can tell, so they might as well be
pulled out of thin air for all I know.

So while I'm all for deploying IPv6 in data centres, I feel this
document doesn't really succeed in providing very useful guidance as to
how. It's simply lacking the technical details I would expect from an
IETF document and I feel that it is at several places making vague or
unsubstantiated claims about purported benefits of deploying IPv6, of
the kind I'd more expect to see in glossy marketing material.

Tore

---

From: Arturo Servin <[email-masked]>
Date: Sun, 16 Mar 2014 11:22:12 -0700

Tore,

Thanks for the comments.

Regarding the percentages. We got some informal input from people by email,
conversations; so the numbers are rather empirical. We could even remove
the specific number and just say that is more work, empirically between
x-y% perhaps to not leaving it too open. But I am not against removing the
percentage at all.

About the meat, you mentioned some text that is not very clear, do you have
some comments about what you consider that we could focus to discuss with
the rest of co-authors?

Thanks,
as

---

From: Tore Anderson <[email-masked]>
Date: Mon, 17 Mar 2014 11:25:47 +0100

Hi Arturo,

> About the meat, you mentioned some text that is not very clear, do you
> have some comments about what you consider that we could focus to
> discuss with the rest of co-authors?

Well, in general I think the document lacks focus on what information it
actually trying to convey... I'll do my best to try to explain what I mean.

The document revolves around three distinct "stages", right:

1) IPv4-only + IPv6 backwards compat "glue"
2) Dual-stack
3) IPv6-only + IPv4 backwards compat "glue"

(BTW: I find "stages" to be rather ill fitting term, as even the
document itself points that one stage doesn't necessarily follow
another. Maybe "deployment model" or something would be better.)

So...

Are you trying to provide guidance to operators who does not know which
"stage" is best suited for them? If so, that's worth while; objectively
list the pros and cons¹ for each, what kind of considerations might
completely preclude a "stage" from being chosen, and so on. However, if
this is the goal of the document, then I think it would be best to not
include too much technical operational guidance in the document itself,
to keep it digestible.

[1] If you're mentioning a pro or a con isn't immediately obvious to the
reader, such as the «IPv6 makes VM migrate faster» claim in the current
document, makes sure to provide an explanation, or a reference to an
explanation. Otherwise it ends up sounding like marketing fluff,
precisely the opposite of what a good document should be (neutral,
objective, unbiased, etc.)

If on the other hand the point is to provide in-depth technical guidance
for the different "stages" (in the case the operator already has already
made his choice), I would suggest splitting them out into separate
documents - one document per "stage". My reasoning is that if, say, I
have already decided to go down the dual-stack path, any preceding text
about the "IPv4-only + IPv6 glue" stage is irrelevant and just in the way.

I feel that in its current form the document tries to be too many things
at once, and as a result doesn't succeed in being very useful at any of
them. It could do with a sprinkle of the UNIX philosophy: «Write [I-Ds]
that do one thing and do it well».

Tore

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 17 Mar 2014 18:08:59 +0000

Hi Tore,

I must admit that the document does not go into all the precise technical details I would like it to go. The reason for that is, essentially, that when I started to prepare it I was engaged in a project to build a reference lab to demonstrate IPv6 capabilities in different scenarios, being datacenters one of them. So I used the document as a placeholder for all possible additional features we could achieve. The problem is that the project was killed without time for making more than the few scenarios that are contemplated in detail, so the others were left as possibilities. We tried to engage other people who had already experimented with these or other features but were not successful, I have to admit, for whatever the reason...

This said, I still believe the document has the value of providing a framework for the different stages (the name was agreed during one of the first presentations of the draft, because there as a common understanding that they were to represent an evolution to full-v6 scenarios, not different choices), and results of what has already been tested and suggestions in the direction of what should be achieved. Whether this value is enough for publishing it or not is what we are discussing in this last call.

Finally, let me say that regarding the costs it is extremely difficult to get more details from any operator you ask, unless you go through some kind of NDA, what makes impossible to publish them anyhow.

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: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Mar 2014 18:18:44 +0900

On Tue, Mar 18, 2014 at 3:08 AM, Diego R. Lopez <[email-masked]> wrote:

> I must admit that the document does not go into all the precise technical
> details I would like it to go. The reason for that is, essentially, that
> when I started to prepare it I was engaged in a project to build a
> reference lab to demonstrate IPv6 capabilities in different scenarios,
> being datacenters one of them.

Am I the only one who has a problem with having a document entitled "IPv6
Operational Guidelines for Datacenters" come out of a project to build a
reference lab?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 19 Mar 2014 09:10:08 -0700

On Mar 19, 2014, at 02:18 , Lorenzo Colitti <[email-masked]> wrote:

> I must admit that the document does not go into all the precise technical details I would like it to go. The reason for that is, essentially, that when I started to prepare it I was engaged in a project to build a reference lab to demonstrate IPv6 capabilities in different scenarios, being datacenters one of them.
> 
> Am I the only one who has a problem with having a document entitled "IPv6 Operational Guidelines for Datacenters" come out of a project to build a reference lab?

No... You are not alone.

Owen