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

[AshwoodsmithPeter <[e-mail]>]

Thanks Joel,

Something else to consider here is just what the multicast is being used for.

Obviously one use is true multicast data, and if that's the case the underlay needs to be efficient (S,G) (*,G) or such when any serious volume of traffic is involved.

However another use is multicast as a way to find/signal other participants in your application. I do not know how the two applications 'ganglia' and 'vertica' behave below, but if they and others fit in this category perhaps a better solution is to give them an API a bit closer to what they are trying to do eg: register to be member in a group, find members in some group, signal members in some group, rather than a lower level 'multicast this message to this group'... because there are lighter ways to do these membership/signalling functions than brute force multicast.

Peter


-----Original Message-----
From: Joel jaeggli [mailto:[e-mail]] 
Sent: Wednesday, February 15, 2012 12:36 AM
To: AshwoodsmithPeter
Cc: Anoop Ghanwani; Mike McBride; Thomas Narten; Igor Gashinsky; [e-mail]
Subject: Re: [armd] address resolution requirement from hosts to overlay edge nodes. Any opinion?

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
>