Re: [armd] address resolution requirement from hosts to overlay edge nodes. Any opinion?

[Joel jaeggli <[e-mail]>]

On 2/14/12 14:15 , AshwoodsmithPeter wrote:
> 
> Irrespective of what is right or wrong etc. technically, I think it
> would be very useful to have a taxonomy of the different applications
> that are using multicast / broadcast for things other than ARP.

ganglia is a common datacenter multicast user

vertica clusters can use broadcast for communication and span hundres of
nodes, however unwise that approach may be.

> The complexity of the underlay depends a lot on what happens with the
> use of multicast by the overlay.
> 
> For example. Assume Microsoft load balancing (for better or worse).
> If I remember correctly, and sombody correct me if I'm wrong, it
> generates multicast frames from otherwise unicast packets at the
> router so that multiple hosts all get copies and then only one
> responds for a given flow... or something like that.
> 
> So if we are using something like a VXLAN overlay we need to map the
> L2 multicast in the overlay to L3 multicast in the underlay or do
> head end replication in the overlay and get a wack load of duplicate
> frames on the first link from the router to the core "switch" (really
> it's a router). Not good. The solution presumably is to run
> potentially thousands of PIM-SM or something messages to
> generate/maintain the required multicast state in the IP underlay.
> 
> Anyway the behavior of the upper layer with respect to broadcast /
> multicast affects the choice of head end, (*,G) or (S,G) replication
> in the underlay, which affects the opex and capex of the entire
> solution, so I think its an important question to get a handle on
> earlier rather than later.
> 
> Peter
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Anoop Ghanwani Sent:
> Tuesday, February 14, 2012 4:53 PM To: Mike McBride Cc: Thomas
> Narten; [e-mail]; Igor Gashinsky Subject: Re: [armd] address
> resolution requirement from hosts to overlay edge nodes. Any
> opinion?
> 
> On Tue, Feb 14, 2012 at 1:16 PM, Mike McBride <[e-mail]>
> wrote:
> 
>> There are interesting challenges with unicast and multicast in big 
>> flat DC networks. That's why we are here. One of the constant
>> themes we hear with multicast is the FUD that it doesn't scale.
>> Especially from vendors who are pushing another solution or who
>> have a crappy multicast implementation. Meanwhile multicast is
>> being deployed in large scale networks without scaling issue.
> 
> Like I said earlier...we have large-scale multicast today, but those
> are purpose-built networks, and at least today, they are no where
> near the kinds of scale where people want to go with overlay 
> technology (in terms of size of network and traffic patterns).
> 
>> Large L2 overlay networks? I don't know. Would be good to find out
>> from the community about performance and scalability of multicast
>> in the DC.
> 
> Perhaps it's best we wait until the problems are little more
> obvious. Or may be they're just non-existent and I get proven wrong.
> Either way, it looks like the correct thing for now is to do
> nothing.
> 
> Anoop _______________________________________________ armd mailing
> list [e-mail] https://www.ietf.org/mailman/listinfo/armd 
> _______________________________________________ armd mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/armd
>