[RFE] Enable arp_responder without l2pop

[venkata anil]

Remove the dependency between arp_responder and l2_pop.
arp_responder should be enabled without enabling l2_pop.
setup arp_responder on OVS integration bridge

To enable arp_responder, we only need port's MAC and IP Address and no tunnel ip(So no need for l2pop).
Currently agents use l2pop notifications to create ARP entries. With the new approach, agents can use
port events(create, update and delete) to create ARP entry and without l2pop notifications.

The advantages with this approach for both linuxbridge and OVS agent -
1) Users can enable arp_responder without l2pop
2) Support ARP for distributed ports(DVR and HA).
   Currently, ARP is not added for these ports.
   This is a fix for https://bugs.launchpad.net/neutron/+bug/1661717

This allows to create ARP entries on OVS integration bridge.

Advantages for OVS agent, if ARP entries are setup on integration bridge(br-int) rather than on tunneling bridge(br-tun)
1) It enables arp_responder for all network types(vlans, vxlan, etc)
   arp_responder based on l2pop is supported for only overlay networks.
2) ARP can be resolved within br-int.
3) ARP packets for local ports(ports connected to same br-int) will be resolved
   in br-int without broadcasting to actual ports connected to br-int.

Already submitted https://review.openstack.org/#/c/248177/ for this.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/248177

[venkata anil (anil-venkata)]

Explanation of the approach taken in https://review.openstack.org/248177

Previously when arp_responder with l2_pop is enabled, arp flows are added/deleted/updated for ports by agent, only when agent receives l2pop rpc messages for the port updates.

Now with this change, agent doesn't depend on l2 pop rpc messages for add/delete/update arp flows for ports.
Instead, agent uses port_update and port_delete rpc notifications, for add/delete/update arp flows for ports.
arp_responder functionality remains same.

A) Below is the behavior of agents when a port is added on other agent -

When a new port is added to agent, other agents will get port_update notification. For this to happen,
1) ml2 plugin is modified(set flag allow_notify=True) in create_port function, to invoke notify_port_updated when bind is succesfull.

When a port is updated, other agents will get port_update notification.
2) arguments for "port_update" RPC is modified to provide the original port along with the updated port, so that agents after receiving the call can identify the changes to that port.
i) For the new port, it's binding information has got changed( port binding VIF_TYPE from unbound to ovs), as port_update called from plugin's create_port immediately after binding
ii) For existing ports, fixed_ips might have changed. So when we have original port information along with the updated port information, we can identify if any new ips added or ips updated for port.

Correspondingly agents with this information can add arp entries or update arp entries for the port. Agents will do this operation only if it is already having any ports on this network.

When a new port is deleted, other ports will get port_delete notification.
1) Agents need port's network, address and MAC to delete arp entry. So Arguments for "port_delete" RPC is modified to provide port info.

All the above port_update and port_delete notifications will be received also by the agent hosting the port, but this agent will discard the notifcations.

B) Below is the behavior of a agent when hosting a port -

When a new port added on the agent, and if it is the first port on that network and on that agent, then it will add arp entries for the ports(on other agents) on same network. For this agent needs the information about other ports on same network. So a new "get_ports_by_network " RPC call added to agent's RPC.

When a existing port is deleted on a hosting agent, and if that is the last port on that network on that agent, that agent will remove all arp entries belong to that network( this is existing code and no changes added for this).

TODO:
1) Remove calls to arp flows from add_fdb_flow and del_fdb_flow( which are invoked from l2_pop RPC).
2) Take care of DVR ports

[Carl Baldwin (carl-baldwin)]

I haven't been through the patch completely but it sort of feels like this change is trying to obsolete l2pop by doing what l2pop does. Is there something that I'm not getting? What is the motivation for doing this?

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/248177
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]

[Armando Migliaccio (armando-migliaccio)]

Kevin is working to deprecate the use of l2pop altogether. We should discuss this in more details.

[Kevin Benton (kevinbenton)]

Moving to approved state but this will be lower priority for me until all of the other push notification work for the L2 agent is done.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.