On Mon, Aug 22, 2016 at 11:28:52AM -0400, Russell Bryant wrote: > On Mon, Aug 22, 2016 at 11:24 AM, Ryan Moats <rmo...@us.ibm.com> wrote: > > > > > MAC_Binding is a bit tricky - the problem here is how to deal where > > dynamic > > > MAC bindings need to be transferred from one chassis to another for > > either > > > HA or live migration scenarios. My preference here is to leave this alone > > > > > (i.e. allow ovn-controller to continue to write this table) and see what > > we > > > can apply from various anti-arp cache poisoning technologies to either > > the IDL > > > or ovsdb-server itself. > > > > > > The proposal here is that they wouldn't be transferred from home > > > host to another. Each chassis would be responsible for its own mac > > learning. > > > > That's what I'm not comfortable with... > > > Why is that? Isn't that how a network would typically work anyway?
Our current design for MAC_Binding is inadequate in any case and needs to be revisited, because it does not have any provisions for ratelimiting, query tracking, renewal, expiration, or limiting the size of the table (see ovn/TODO for details). Chassis-specific learning is an alternative model we've considered here. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
