Hi Ethan, > I really don't want to go down the rabbit hole of retaining optional > backwards compatibility for every little feature we remove just because > there might possibly me some badly configured user who is affected on > upgrade. I'd prefer not to accept this patch until there's a more specific > use > case for it.
Besides the backwards compatibility argument, I think there is another important use case. Several of the (physical) switches that support LACP block all traffic for ports that are configured to use LACP, until LACP is negotiated with the host (similar to the behaviour of OVS 1.9). When configuring a LACP bond on a XenServer host, this means that there will be an interruption of the network connectivity between the time the ports on the physical switch and the bond on the XenServer host are configured. The interruption may be relatively long, if different people are responsible for managing the switches and the XenServers. This may be problematic, because: * There may be VMs running on the host, which will experience a loss of network connectivity. * It complicates configuring a LACP bond of the XenServer management interface over the network. * A special case of the previous point: when XenServer hosts are pooled, the pool slaves rely heavily on the management connection with the master host. Configuring LACP bonding on such a pool slave will become very difficult. All this can be avoided if you can configure LACP on the XenServer host before configuring the physical switch, and having the host fall back to a bond mode that does not rely on the configuration of the physical switch, such that the service interruption is avoided (either balance-slb or active-backup would do). Does that make sense? Cheers, Rob _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
