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

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.

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: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Anoop Ghanwani
Sent: Tuesday, February 14, 2012 4:53 PM
To: Mike McBride
Cc: Thomas Narten; armd@ietf.org; 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 <mmcbride7@gmail.com> 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
armd@ietf.org
https://www.ietf.org/mailman/listinfo/armd