Re: [armd] datacenter reference architecture draft

Joel jaeggli <joelja@bogus.com> Mon, 31 October 2011 18:28 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B426B1F0CB0 for <armd@ietfa.amsl.com>; Mon, 31 Oct 2011 11:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 7A5ucVoPHbb4 for <armd@ietfa.amsl.com>; Mon, 31 Oct 2011 11:28:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 141981F0CAF for <armd@ietf.org>; Mon, 31 Oct 2011 11:28:55 -0700 (PDT)
Received: from Zorch.local (adsl-99-173-15-226.dsl.pltn13.sbcglobal.net [99.173.15.226]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p9VISrGm002015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 31 Oct 2011 18:28:54 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EAEE8E4.90302@bogus.com>
Date: Mon, 31 Oct 2011 11:28:52 -0700
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Manish Karir <mkarir@merit.edu>
References: <905C201F-E6DD-4FA2-A65A-38472BA39571@merit.edu>
In-Reply-To: <905C201F-E6DD-4FA2-A65A-38472BA39571@merit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 31 Oct 2011 18:28:54 +0000 (UTC)
Cc: armd@ietf.org
Subject: Re: [armd] datacenter reference architecture draft
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 18:28:55 -0000

so, I looked at it for a while...

I'm a bit mystified by 3.4.1-3.4.4

we've already arrived I guess at what we conclude is the ideal topology,
and a particular model of mobility.

When faced with this choice and a desire to constrain both the
complexity and the diameter failure domain one response is to not make
the network the arbiter of mobility, e.g. move that to provisioning or
the application layer. the result is a lot closer to 3.4.1 than it is
the others.

One of he problems I have with managing a large l2 domain, particularly
one constructed as an overlay is that there's effectively no upper bound
appart from physics and good taste for how far it can spread, first they
want across the rack, the module, then across the whole datacenter, then
to the adjacent datacenter, across the country, to other cloud
providers, etc. if you  constrain it sufficiently small that
availability is not a design consideration (1 or 2 switches is big l2
domain) then it doesn't become a dependency.

Insisting that ip addresses move around with virtualized machines is one
way to view the world but it not the only way. nor is constraining
tenets to common l2 buckets the only way to segment applications from
each other, the hosts for the virtual machines can just as well be (are)
policy enforcement points.

On 10/28/11 09:01 , Manish Karir wrote:
> 
> The following draft was submitted to hopefully help focus the ARMD discussion around a common architecture.
> 
> Comments and feedback are welcome.  The goal of the writeup really is to abstract away specific datacenter designs
> each of which focuses on solving a particular application/traffic pattern by trying to talk about what is common between 
> the various designs.  Hopefully this will help some of the very varied discussion that has taken place in this WG so far.
> 
> Thanks.
> -manish
> 
> http://www.ietf.org/id/draft-armd-datacenter-reference-arch-01.txt
> -----------------------------------------
> Filename:	 draft-karir-armd-datacenter-reference-arch
> Revision:	 00
> Title:		 Data Center Reference Architectures
> Creation date:	 2011-10-24
> WG ID:		 Individual Submission
> Number of pages: 11
> 
> Abstract:
>   The continued growth of large-scale data centers has resulted in a
>   wide range of architectures and designs.  Each design is tuned to
>   address the challenges and requirements of the specific applications
>   and workload that the data is being built for.  Each design evolves
>   as engineering solutions are developed to workaround limitations of
>   existing protocols, hardware, as well as software implementations.
> 
>   The goal of this document is to characterize this problem space in
>   detail in order to better understand if there is any gap in making
>   address resolution scale in various network designs for data
>   centers.  In particular it is our goal to peel back the various
>   optimization and engineering solutions to develop generalized
>   reference architectures for a data center.  We also discuss the
>   various factors that influence design choices in developing various
>   data center designs.
> --------------------------------------------------------------------------
> _______________________________________________
> armd mailing list
> armd@ietf.org
> https://www.ietf.org/mailman/listinfo/armd
>