Re: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04)

"Alexis Munoz \(Gmail\)" <amunoz0481@gmail.com> Wed, 19 June 2013 01:55 UTC

Return-Path: <amunoz0481@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD04811E80A5 for <v6ops@ietfa.amsl.com>; Tue, 18 Jun 2013 18:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsJKfbqF2uRQ for <v6ops@ietfa.amsl.com>; Tue, 18 Jun 2013 18:55:45 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id CA42921F93BA for <v6ops@ietf.org>; Tue, 18 Jun 2013 18:55:44 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id ia10so3463305vcb.28 for <v6ops@ietf.org>; Tue, 18 Jun 2013 18:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=1xUK3qcHdvqHNtZTFU4portSJ7PTdpKHpeJf50shb0E=; b=t4YtaD9ha3OGr8Cp1Mqb3+PBA/9a6+S4UxdePBTWTHl/6qTztnItyhBWEUvvPd4G5H 9rsSeRaCkpF6GkQLqJ6hinnq/aVJoH415yo/MxxXJ7VX1+FEkxITY2H1wgLsivETfJc9 SBYs7Z90KdYo8HJuW2Z5T3FKCenNaMzYV7rkS4oU6zMmX0O95UM97WB1fKVDGbPm6dRv 1p9cSQCbdk3/PwZtiHEQBhVQrQdMZYCddeE2Lt6kS5MttQzakaySLARXXuhzCXOwVOUT uEl7dnrNr6OybAt42yI0OXDloh0FESJk44q5fSAmbFNUEdxTtgfRTbTaJcOXviM+JnHS C3eA==
X-Received: by 10.58.68.38 with SMTP id s6mr252415vet.46.1371606944170; Tue, 18 Jun 2013 18:55:44 -0700 (PDT)
Received: from AMUNOZPC ([181.129.131.86]) by mx.google.com with ESMTPSA id bk7sm7321965ved.0.2013.06.18.18.55.42 for <v6ops@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 18 Jun 2013 18:55:43 -0700 (PDT)
From: "Alexis Munoz (Gmail)" <amunoz0481@gmail.com>
To: v6ops@ietf.org
References: <51C070BB.9090209@criba.edu.ar>
In-Reply-To: <51C070BB.9090209@criba.edu.ar>
Date: Tue, 18 Jun 2013 20:55:39 -0500
Message-ID: <017f01ce6c90$1ae2e190$50a8a4b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCIoMgyEq3OaLkWA6YFxvUyr3pWP5vH3Q4g
Content-Language: en-us
Subject: Re: [v6ops] IPv6 Operational Guidelines for DC (draft-lopez-v6ops-dc-ipv6-04)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 01:55:49 -0000

Dear Authors

First of all, I would like to congratulate to all the team who is
participating in addressing this guideline ahead. Excellent work.

So, I have read the document and I took some notes focus more in Enterprise
Datacenters that I would like to share here. I split my notes following the
chapters on the document:

2.1. General Architecture 

The generalized interconnection schema in a DC in my opinion must goes
beyond. Normally, in a datacenter infrastructure there are modules
interconnecting the DC. I agree, the Internet Access is one of them, but we
cannot forget that there might be also modules interconnecting the DC such
as WAN and Remote Access Modules, all depend on the scenario and sector. The
IPv6 Deployment in the Datacenter might extend the interconnectivity  to
Branch Offices, Partners, Third-Parties, so forth. The IPv6 address schema
should consistent end-to-end, even more for delivery services and
applications on public or private networks.


2.2. Experimental Stages 

One of the implicit advantages of IPv6 application are Flow Labels and
Mobile IP, only if they are applied at the ingress elements. However, it is
not clear for me, because all the internal networks are IPv4 in this stage,
then, why Mobile IP comes into play, also, Are we  talking about Mobile IP
on IPv4 or IPv6?. 

Additionally, for VM Migration intra or inter-DC, we might prefer to use
mechanism offered by vendors for moving either the virtual machines or the
data, and to keep the ip address intra or inter-DC, there are mechanism as
VLANs, Extended LANs, so on.  

I will really discuss and review the advantages and disadvantages  of this
stage. If somebody is interested in looking this stage for experimentation
or early evaluation, the idea is to find out a good purpose for enroll it. 


2.3. Dual Stack Stages 

On which internal elements are required to have dual-stack??, I guess that
an internal part or element could be defined as Switch, Router, Load
Balancer, Firewall, NIPS, Server, Network Service, Application, so forth. I
think that could be interesting to mention in general in a dual-stack stage
which elements are more common to have a dual-stack to achieve a soft
transition and avoid impact in the performance of the services and
applications.  

Additionally, the Dual-Stack is focus on LB Mechanism, what happen in
scenarios where is not required a Load Balancer?....how is affected the data
transmission in the farm servers??...Should left in IPV4 the Farm Servers
and apply Dual-Stacking in the Services Layers with devices as Firewall,
Load Balancer, DNS, Router, Wireless Controllers, So Forth?...what is the
best practice here?

2.4 IPv6 Only Stage. 

I absolutely agree that  planning the ip address schema is one of the most
important and stronger part for a transition IPv6 into the DC Infrastructure
successfully, also apply for any of the transition stages. 

3. Other Operational Considerations
3.1 Addressing

The document recommend at least to have a /48 for each Datacenter, what
should be the recommendation to allocate the subnets inside the datacenter?,
I know all depends on the services and architecture, but I think could be
good idea to mention some general good practices to allocate properly the
IPv6 into the DC Infrastructure. 

3.3. Monitoring and Logging

Collect data specific can be using SNMPv3 over IPv6 as well, or is not
supported SNMPv3 over IPv6 yet?

3.4. Costs

What were the parameters or model to estimate the extra costs??...that might
be very useful to support the business case. I suggest to add to the
document.   

I hope these comments can help to the authors and the community to adopt the
document as WG item.  

Thanks a lot.

Alexis Muñoz

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Santiago Aggio
Sent: Tuesday, June 18, 2013 9:38 AM
To: v6ops@ietf.org
Subject: [v6ops] IPv6 Operational Guidelines for DC
(draft-lopez-v6ops-dc-ipv6-04)

Dear Authors,

    My impression is that this very good, very clear, is a guide that covers
most of the realities faced by an operator and an engineer of a DC
infrastructure to deploy IPv6, with several considerations that help in the
moment of decision and the work involved in the technical side of the
routing, management and monitoring.

     The architecture described is very simple and clear, and very well the
above stages to reach IPv6-only model. The references also seem to cover
these aspects.
  
Great Job!!!!, Congratulations

Santiago Aggio
Bahia Blanca
Argentina.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops