Description of problem:
Currently the Mac binding aging removes rows that are still relevant and that can cause short traffic disruption. In order to avoid that add mechanism that will refresh the timestamp when the MAC binding is still in use.

Initial proposal for the implementation was started as ovs-discuss thread [0].

The following approach was decided to be taken:

Add "mac_cache_use" action into "lr_in_learn_neighbor" table (only the flow that continues on known MAC binding):
match=(REGBIT_LOOKUP_NEIGHBOR_RESULT == 1 || REGBIT_LOOKUP_NEIGHBOR_IP_RESULT == 0), action=(next;)  -> match=(REGBIT_LOOKUP_NEIGHBOR_RESULT == 1 || REGBIT_LOOKUP_NEIGHBOR_IP_RESULT == 0), action=(mac_cache_use; next;)

The "mac_cache_use" would translate to resubmit into separate table with flows per MAC binding as follows:
match=(ip.src=<MB_IP>, eth.src=<MB_MAC>, datapath=<MB_Datapath>), action=(drop;)

This should bump the statistics every time for the correct MAC binding. In ovn-controller we could periodically dump the flows from this table. the period would be set to MIN(mac_binding_age_threshold * 3/4) from all local datapaths. The dump would happen from a different thread with its own rconn to prevent backlogging issues. The thread would receive mapped data from I-P node that would keep track of mapping datapath -> cookies -> mac bindings. This allows us to avoid constant lookups, but at the cost of keeping track of all local MAC bindings. To save some computation time this I-P could be relevant only for datapaths that actually have the threshold set.

If the "idle_age" of the particular flow is smaller than the datapath "mac_binding_age_threshold" it means that it is still in use. To prevent a lot of updates, if the traffic is still relevant on multiple controllers, we would check if the timestamp is older than the "dump period"; if not we don't have to update it, because someone else did.

Also to "desync" the controllers there would be a random delay added to the "dump period". 

[0] https://mail.openvswitch.org/pipermail/ovs-discuss/2023-May/052475.html