[Starlingx-discuss] RFE Review Request for patch 88b7bc7 for StartlingX Upstreaming

[Xu, Chenjie]

Hi Ryan,
Thank you for your reply! For your questions:

1. What's the context for this RFE:
StarlingX extends Neutron, networking-bgpvpn and neutron-dynamic-routing as stx-neutron, stx-networking-bgpvpn and stx-neutron-dynamic-routing. These extensions enable Neutron network to learn external MAC/IP information from BGPVPN network and publish the external MAC/IP information  internally via the L2POP mechanism. Similarly, internal MAC/IP information in Neutron network is published to remote systems via a subscription to L2POP RPC notifications and finally will be received by the BGP agent.

2. It looks like this RFE is one of several in the neutron space that would be required to achieve this functionality, is that correct?
Yes, it is. To achieve what I describe in question one, 3 RFE has been posted to Neutron.
1). RFE "Enable other subprojects to extend l2pop fdb information" (https://bugs.launchpad.net/neutron/+bug/1793653) should be used by networking-bgpvpn to publish the (MAC, IP) information in BGPVPN network to Neutron network.
2). RFE "Add l2pop support for floating IP resources" (https://bugs.launchpad.net/neutron/+bug/1803494) extends l2pop FDB information to avoid the broadcast in the scenario that two VMs, residing on different network, communicate by their respective floating IP.
3). This RFE proposes to add an RPC query API to l2pop. This RFE is used by BGP Dynamic Routing agent to pull the l2pop FDB information.

For the changes in stx-networking-bgpvpn and stx-neutron-dynamic-routing, the plan is to upstream them to networking-bgpvpn and neutron-dynamic-routing. However, in the short term this is not being prioritized nor has any attempt been made to approach the individual project teams about getting this accepted.

I'm not sure if this is the same idea that using BGPVPN to provide an alternative to the current l2pop implementation or not. Looking forward to your reply!

Best Regards,
Xu, Chenjie

From: Ryan Tidwell [mailto:rtidwell at suse.com]
Sent: Thursday, December 20, 2018 6:08 AM
To: Xu, Chenjie <chenjie.xu at intel.com>
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] RFE Review Request for patch 88b7bc7 for StartlingX upstreaming


Chenjie,

Thanks for reaching out. I've taken a glance over the RFE, it's very detailed but lacks some context. Just to be sure I understand this correctly, is the idea here to use BGP EVPN as a method for providing l2pop functionality? If so, I've actually been thinking about this for some time now and I think it would be great to provide an alternative to the current l2pop implementation. I could certainly see supporting this functionality in some fashion in neutron-dynamic-routing. It looks like this RFE is one of several in the neutron space that would be required to achieve this functionaliy, is that correct? If I'm not understanding the use case correctly, could you explain what you have in mind? In the mean time I'll look this over again and leave some comments.

-Ryan
On 12/19/18 2:17 AM, Xu, Chenjie wrote:
Hi Ryan,
Could you please help review the RFE for Neutron (https://bugs.launchpad.net/neutron/+bug/1806316) and leave a comment?

This RFE proposes to add an RPC query API to l2pop. The API is used to allow an agent to query the full FDB for a list of network_id values. This is needed by the agents which want to support l2pop but don't have ports bound to themselves (Potential for BGP Dynamic Routing agent). The project stx-neutron-dynamic-routing is a fork project for neutron-dynamic-routing. The project stx-neutron-dynamic-routing implements the l2pop for BGP Dynamic Routing agent:
https://github.com/starlingx-staging/stx-neutron-dynamic-routing/blob/master/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py#L1053
https://github.com/starlingx-staging/stx-neutron-dynamic-routing/blob/master/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py#L1180

The plan is to upstream these changes to neutron-dynamic-routing. However, in the short term this is not being prioritized nor has any attempt been made to approach the individual project teams about getting this accepted. Could you leave a comment on the potential use?

Best Regards,
Xu, Chenjie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181220/62317f5e/attachment.html>