Re: [armd] datacenter reference architecture draft

[Joel jaeggli <[e-mail]>]

On 11/4/11 07:59 , Manish Karir wrote:
> 
> Hi Joel,
> 
> The goal of 3.4.1-3.4.4 was to discuss variations on how L2/L3 topologies can 
> vary from one data center to the next even with the generic data center
> logical model.  These came out of various discussions at previous ietf/nanog
> meetings and offline discussion.  Some may not make sense to us, but were
> the perfect solution to others who needed to solve a particular problem.

They make sense to someone. as I noted the authors have in the text come
to some conclusions about what model is most appropiate for deploment
within a datacenter in order to support a specific problem namely l2 v2
vm mobility.

The notion that constraining the l2 domain to a single or two tor is
only suitable for static environments is wrong. likewise that
virtualization has to necessarily drive l2 mobility, it does not.


>  I
> think what we wanted to do with this draft is put these discussions down in 
> one place to make sure we were all aware of what architectural decisions
> (tricks?) different people use to solve their application requirements.
> Hope this helps clarify things?  
>
> Also, is the basic description here consistent from what you have seen 
> in terms of data center architectures?  What do you think is missing here?
> Are there any other particularly interesting designs that you have come across
> that should be included here?
> 
> Thanks for your help.
> 
> -manish
> 
> 
> 
> On Oct 31, 2011, at 2:28 PM, Joel jaeggli wrote:
> 
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/armd
>>>
>>
> 
>