Hi Allain,

During the OpenStack driver meeting on last Friday, the community asked me to provide some examples of l2pop RPC payloads with this extension to this RFE. Could you please help review the example?

The link for RFE: https://bugs.launchpad.net/neutron/+bug/1793653

The patch ID: 4ae5a58

 

Example:

 

L2pop driver on server side:

===============================

1) when port binding or status or ip_address(or mac) is updated, notify this port's FDB(i.e port's ip address, mac, hosting agent's tunnel ip) to all agents

2) also checks if it is the first or last port on the hosting agent's network, if so

   a) notifies all agents to create/delete tunnels and flood flows to hosting agent

   b) notifies hosting agent about all the existing network ports on other agents(so that hosting agent can create tunnels, flood and unicast flows to these ports).

 

For subproject networking-bgpvpn to extend l2pop fdbs:

===============================

1) when port binding or status or ip_address(or mac) is updated, notify this port's FDB(i.e port's ip address, mac, hosting agent's tunnel ip) to all agents

  No action

2) also checks if it is the first or last port on the hosting agent's network, if so

   a) notifies all agents to create/delete tunnels and flood flows to hosting agent

     No action

   b) notifies hosting agent about all the existing network ports on other agents(so that hosting agent can create tunnels, flood and unicast flows to these ports).

     Insert the ports information from BGPVPN to the FDB

     The network_id, segment_id and network_type are all from neutron. Becaue the network_id, segment_id and network_type relate to the port which triggers l2pop.

        network_id: comes from the port's network

        segment_id: comes from the segment which the port bounds to.

        network_type: comes from the port's network

     Thus networking-bgpvpn only needs to insert information into 'ports' as following:

        {75b21e39-15b9-4f12-8a60-1375a4dbdbef:

          {'segment_id': '12',

           'network_type': 'vxlan',

           'ports': {'12.66.1.1': [('fa:16:3e:d2:70:92', '168.177.1.23'),('fa:16:3e:f3:a4:21', '168.177.1.5')],

                  '13.96.1.1': [('fa:16:3e:f9:cc:77', '169.177.1.16'),( 'fa:16:3e:a5:ee:f1', '169.177.1.12')]}}}

3) Update the BGPVPN gateway

   a) add a new gateway

Use the L2populationAgentNotifyAPI in neutron\plugins\ml2\drivers\l2pop\rpc.py. For simplicity, we call L2populationAgentNotifyAPI as l2pop_notifier.

      l2pop_notifier. add_fdb_entries()

        network: the network associated with the BGPVPN

        network_id: network’s id

        segment_id: network’s “provider:segmentation_id”.

        network_type: network’s “provider:network_type”

     Thus networking-bgpvpn needs to call add_fdb_entries() to add the following fdb:

        {75b21e39-15b9-4f12-8a60-1375a4dbdbef:

          {'segment_id': '100',

           'network_type': 'vxlan',

           'ports': {'12.66.1.1': [('00:00:00:00:00:00', '0.0.0.0')]}}}

   b) withdraw an existing gateway

      l2pop_notifier. remove_fdb_entries()

        network: the network associated with the BGPVPN

        network_id: network’s id

        segment_id: network’s “provider:segmentation_id”.

        network_type: network’s “provider:network_type”

     Thus networking-bgpvpn needs to call add remove_fdb_entries() to remove the following fdb:

        {75b21e39-15b9-4f12-8a60-1375a4dbdbef:

          {'segment_id': '100',

           'network_type': 'vxlan',

           'ports': {'12.66.1.1': [('00:00:00:00:00:00', '0.0.0.0')]}}}

4) Delete BGPVPN

   l2pop_notifier. remove_fdb_entries()

   Similar to 3b but will remove all the fdbs belonging to the BGPVPN(including the gateway and all the devices in the BGPVPN)

5) Update BGPVPN device

a) add new devices

      l2pop_notifier. add_fdb_entries()      

      Similar to 3a but add new device’s fdb information.

   b) withdraw existing devices

      l2pop_notifier. add_fdb_entries()

      Similar to 3b but remove the fdb information belonging to the devices which are withdrawn

6) BGP agent updates

a) agent up

      l2pop_notifier. add_fdb_entries()       Similar to 3a but add new device’s fdb information

      l2pop_notifier. remove_fdb_entries()   Similar to 3a but remove the fdb information belonging to the stale device

   b) agent down

      Similar to 3b but remove all the fdbs belonging to the agent(including the gateway and all the devices)

7) disassociated a VPN from a BGP speaker

      l2pop_notifier. remove_fdb_entries()

      Similar to 3b but remove the fdb information belonging to the BGPVPN whose association with a BGP speaker has been dropped.

 

What’s more, I have several questions:

1. it seems that the bgpvpn in stx-networking-bgpvpn can only be l2vpn according to the docstring in function _get_network_id. To support this RFE, whether it can be l3vpn or a bgpvpn can associate more than one network?

2. Could you please provide the network flow between a vm in neutron network and a device in bgpvpn? Suppose the fdb of the device in bgpvpn has been prepopulated.

 

Best Regards,

Xu, Chenjie