Re: [armd] soliciting typical network designs for ARMD

My own perspective was that it seemed useful to put on paper the 
approach to using a mapping system at the hypervisor.
The exactly encapsulation is irrelevant to me.

I was hoping it would prompt discussion of that piece of the idea.
If it did, we then had to figure out whether there was a way to take it 
forward.
Also, if there was interest, it meant that it was worth seeing if the 
ARMD data supported or disagreed with the view that this is part of the 
problem.  At the moment, the data does not tell us.  But if no one 
cares, then it is not going to be effective for me to push folks to find 
out more.

Yours,
Joel

On 9/23/2011 3:46 PM, Warren Kumari wrote:
>
> On Sep 19, 2011, at 7:36 PM, Balus, Florin Stelian (Florin) wrote:
>
>>
>> These two drafts and draft-wkumari-dcops-l3-vmmobility-00.txt seem to be submitted as either informational or experimental. Can the authors of these two drafts clarify what do they plan to do with them?
>
> Honestly? My grand plan was to largely ignore the draft and then feel guilty that I had not incorporated the comments that I have received. Eventually the guilt would have caught up with me and I would have been forced to make a decision as to if I was going to bother writing more, or simply deleting it and pretending nothing had ever happened...
>
> I believe that my co-author ((Joel), who is more level-headed than me) may be been planning on doing something more useful -- I've CCed him.
>
> The draft wasn't really intended to push a new encapsulation technology (the desire was simply to demonstrate that big flat L2 networks are not needed for VM mobility) -- the introduction of an encapsulation was only done because I couldn't easily find an existing solution. If one is created (that satisfied the needs of the protocol), that would be much better...
>
>
> W
>> If relevant feedback is required I think they seem to fit the scope of L2VPN WG. At least two of them talk about some new encapsulation used to provide L2 Multi-tenancy in the Data Centers over some sort of overlay and UDP/IP tunnels. A new L2VPN charter was released recently which includes requirements and solutions targeted at the Data Center space.
>>
>> Florin
>>
>> -----Original Message-----
>> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Murari Sridharan
>> Sent: Saturday, September 17, 2011 1:02 PM
>> To: david.black@emc.com; armd@ietf.org
>> Subject: Re: [armd] soliciting typical network designs for ARMD
>>
>> FYI, here is a talk that I gave last week in relation to the nvgre draft below.
>> http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T
>>
>> Thanks
>> Murari
>>
>> -----Original Message-----
>> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of david.black@emc.com
>> Sent: Friday, September 16, 2011 6:14 AM
>> To: armd@ietf.org
>> Subject: Re: [armd] soliciting typical network designs for ARMD
>>
>> And two more drafts on this topic:
>>
>> http://www.ietf.org/id/draft-mahalingam-dutt-dcops-vxlan-00.txt
>> http://www.ietf.org/id/draft-sridharan-virtualization-nvgre-00.txt
>>
>> The edge switches could be the software switches in hypervisors.
>>
>> Thanks,
>> --David
>>
>>
>>> -----Original Message-----
>>> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf
>>> Of Warren Kumari
>>> Sent: Wednesday, August 31, 2011 3:16 PM
>>> To: Vishwas Manral
>>> Cc: armd@ietf.org
>>> Subject: Re: [armd] soliciting typical network designs for ARMD
>>>
>>>
>>> On Aug 11, 2011, at 11:40 PM, Vishwas Manral wrote:
>>>
>>>> Hi Linda/ Anoop,
>>>>
>>>> Here is the example of the design I was talking about, as defined by google.
>>>
>>> Just a clarification -- s/as defined by google/as described by someone
>>> who happens to work for google/
>>>
>>> W
>>>
>>>> http://www.ietf.org/id/draft-wkumari-dcops-l3-vmmobility-00.txt
>>>>
>>>> Thanks,
>>>> Vishwas
>>>> On Tue, Aug 9, 2011 at 2:50 PM, Anoop Ghanwani<anoop@alumni.duke.edu>  wrote:
>>>>
>>>>>>>>
>>>> (though I think if there was a standard way to map Multicast MAC to
>>>> Multicast IP, they could
>>> probably use such a standard mechanisms).
>>>>>>>>
>>>>
>>>> They can do that, but then this imposes requirements on the
>>>> equipment to be able to do multicast forwarding, and even if does,
>>>> because of pruning requirements the number of groups would be very
>>>> large.  The average data center switch probably won't handle that
>>>> many groups.
>>>>
>>>> On Tue, Aug 9, 2011 at 2:41 PM, Vishwas Manral<vishwas.ietf@gmail.com>  wrote:
>>>> Hi Anoop,
>>>>
>>>>  From what I know they do not use Multicast GRE (I hear the extra 4
>>>> bytes in the GRE header is a
>>> proprietery extension).
>>>>
>>>> I think a directory based mechanism is what is used (though I think
>>>> if there was a standard way to
>>> map Multicast MAC to Multicast IP, they could probably use such a standard mechanisms).
>>>>
>>>> Thanks,
>>>> Vishwas
>>>> On Tue, Aug 9, 2011 at 2:03 PM, Anoop Ghanwani<anoop@alumni.duke.edu>  wrote:
>>>> Hi Vishwas,
>>>>
>>>> How do they get multicast through the network in that case?
>>>> Are they planning to use multicast GRE, or just use directory based
>>>> lookups and not worry about multicast applications for now?
>>>>
>>>> Anoop
>>>>
>>>> On Tue, Aug 9, 2011 at 1:27 PM, Vishwas Manral<vishwas.ietf@gmail.com>  wrote:
>>>> Hi Linda,
>>>>
>>>> The data packets can be tunnelled at the ToR over say a GRE packet
>>>> and the core is a Layer-3 core
>>> (except for the downstream ports). So we could have encapsulation/
>>> decapsulation of L2 over GRE at the ToR.
>>>>
>>>> The very same thing can be done at the hypervisor layer too, in
>>>> which case the entire DC network
>>> would look like a Layer-3 flat network including the ToR to server
>>> link and the hypervisor would do the tunneling.
>>>>
>>>> I am not sure if you got the points above or not. I know cloud OS
>>>> companies that provide the service
>>> and have big announced customers.
>>>>
>>>> Thanks,
>>>> Vishwas
>>>> On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar<dunbar.ll@gmail.com>  wrote:
>>>> Vishwas,
>>>>
>>>> In my mind the bullet 1) in the list refers to ToR switches
>>>> downstream ports (facing servers)
>>> running Layer 2 and ToR uplinks ports run IP Layer 3.
>>>>
>>>> Have you seen data center networks with ToR switches downstream
>>>> ports (i.e. facing servers) enabling
>>> IP routing, even though the physical links are Ethernet?
>>>> If yes, we should definitely include it in the ARMD draft.
>>>>
>>>> Thanks,
>>>> Linda
>>>> On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral<vishwas.ietf@gmail.com>  wrote:
>>>> Hi Linda,
>>>> I am unsure what you mean by this, but:
>>>> 	* layer 3 all the way to TOR (Top of Rack switches), We can also
>>>> have a heirarchical network, with the core totally Layer-3 (and
>>>> having seperate
>>> routing), from the hosts still in a large Layer-3 subnet. Another
>>> aspect could be to have a totally
>>> Layer-3 network.
>>>>
>>>> The difference between them is the link between the servers and the ToR.
>>>>
>>>> Thanks,
>>>> Vishwas
>>>> On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar<dunbar.ll@gmail.com>  wrote:
>>>> During the 81st IETF ARMD WG discussion, it was suggested that it is
>>>> necessary to document typical
>>> data center network designs so that address resolution scaling issues
>>> can be properly described. Many data center operators have expressed that they can't openly reveal their detailed network designs.
>>> Therefore, we only want to document anonymous designs without too much
>>> detail. During the journey of establishing ARMD, we have come across the following typical data center network designs:
>>>> 	* layer 3 all the way to TOR (Top of Rack switches),
>>>> 	* large layer 2 with hundreds (or thousands) of ToRs being
>>>> interconnected by Layer 2. This
>>> design will have thousands of hosts under the L2/L3 boundary router
>>> (s)
>>>> 	* CLOS design  with thousands of switches. This design will have
>>>> thousands of hosts under the
>>> L2/L3 boundary router(s)
>>>> We have heard that each of the designs above has its own problems.
>>>> ARMD problem statements might
>>> need to document DC problems under each typical design.
>>>> Please send feedback to us (either to the armd email list  or to the
>>>> ARMD chair Benson&  Linda) to
>>> indicate if we have missed any typical Data Center network designs.
>>>>
>>>> Your contribution can greatly accelerate the progress of ARMD WG.
>>>>
>>>> Thank you very much.
>>>>
>>>> Linda&  Benson
>>>>
>>>>
>>>
>>> _______________________________________________
>>> armd mailing list
>>> armd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/armd
>>
>> _______________________________________________
>> armd mailing list
>> armd@ietf.org
>> https://www.ietf.org/mailman/listinfo/armd
>>
>> _______________________________________________
>> armd mailing list
>> armd@ietf.org
>> https://www.ietf.org/mailman/listinfo/armd
>> _______________________________________________
>> armd mailing list
>> armd@ietf.org
>> https://www.ietf.org/mailman/listinfo/armd
>>
>
>