Re: [armd] soliciting typical network designs for ARMD

[Murari Sridharan <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, September 16, 2011 6:14 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Warren Kumari
> Sent: Wednesday, August 31, 2011 3:16 PM
> To: Vishwas Manral
> Cc: [e-mail]
> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/armd

_______________________________________________
armd mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/armd