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

["Michael K. Smith - Adhost" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> AshwoodsmithPeter
> Sent: Tuesday, February 14, 2012 2:15 PM
> To: Anoop Ghanwani; Mike McBride
> Cc: Thomas Narten; Igor Gashinsky; [e-mail]
> Subject: 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.
> 

Microsoft is configurable for IGMP Multicast and Unicast.  There are also the other LB protocols such as CARP, VRRP, GLBP, HSRP, etc.  

Mike