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

I have to admit I am a bit confused by the direction this is going. 

There seems to be a view that multicast is bad, yet it is a useful tool to permit a significant amount of functionality to be delegated to end systems, and is a part of useful address aggregation in the form of the subnet. IMO virtualized broadcast domains are good things, not something to be avoided, and they permit a trusted resource community to do a lot of self-organizing. 

Perhaps you should be thinking about improving multicast, not evicerating everything else. And as a general design principle, I believe that applies to most areas where the tail is wagging the dog in these deliberations.

My 2 cents
Dave

-----Original Message-----
From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Anoop Ghanwani
Sent: Tuesday, February 14, 2012 10:55 AM
To: AshwoodsmithPeter
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 10:29 AM, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> wrote:

>>That said, there are unicast applications (such as Microsoft's Network 
>>Load Balancing) that require multicast at L2, and because they require 
>>multicast at L2, such a network would still need to support IP 
>>multicast.
>
>>So really, the directory-based approach would be helpful only in a 
>>narrow set of circumstances -- no multicast applications including 
>>things like NLB.
>
> Anoop, even if you have a good multicast in the underlay network and its being used by things like MS NLB there is still enormous value in eliminating the multicast methods that are used to establish the <c-mac, ip-addr, b-mac tunnel> tripple relationships via some form of database etc.

That's correct, Peter.  As I said in my first response, we have to solve both problems -- ipaddr->cmac and cmac->bmac/tunnel.
If we solve only one, then the value proposition is significantly diluted.  As an added benefit, if we solve this problem and there is no other need for L2 multicast in the network (NLB, directed broadcast), then the overlay does not need multicast support from the underlying network.  Requiring IP multicast (especially PIM bidir) from the network is really a big deal, especially at the kind of scale that the VXLAN/NVGRE proposals need it.

Anoop
_______________________________________________
armd mailing list
armd@ietf.org
https://www.ietf.org/mailman/listinfo/armd