14:01:01 <slaweq> #startmeeting neutron_drivers
14:01:02 <openstack> Meeting started Fri Nov  9 14:01:01 2018 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:11 <yamamoto> hi
14:01:13 <slaweq> hi
14:01:15 <ralonsoh> hi
14:01:37 <slaweq> mlavalle is not available today, so I will chair this meeting
14:01:54 <slaweq> I have "orders" from him so should be good ;)
14:02:11 <Chenjie> Hi guys, if possible I want to discuss the RFE https://bugs.launchpad.net/neutron/+bug/1793653
14:02:12 <openstack> Launchpad bug 1793653 in neutron "[RFE] Enable other subprojects to extend l2pop fdb information" [Wishlist,In progress] - Assigned to ChenjieXu (midone)
14:02:17 <slaweq> lets wait for amotoki and haleyb
14:02:26 <haleyb> hi
14:02:38 <slaweq> Chenjie: it's on the list for today
14:02:44 <slaweq> hi haleyb
14:02:52 <Chenjie> slaweq: thanks!
14:03:31 <slaweq> ok, I think we have quorum now so we can start
14:03:45 <slaweq> #topic RFEs
14:03:59 <slaweq> I have 3 RFEs for today
14:04:02 <slaweq> first is:
14:04:21 <slaweq> https://bugs.launchpad.net/neutron/+bug/1796925
14:04:22 <openstack> Launchpad bug 1796925 in neutron "[RFE] port forwarding floating IP QoS" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:05:49 <slaweq> I think that reported of this RFE is not here today
14:07:58 <slaweq> IIUC comment #2 in this RFE he wants to apply bandwidth limit to all port forwardings attached to FIP, yes?
14:11:35 <yamamoto> that's my understanding
14:12:59 <slaweq> yes, we can already attach QoS policy to Floating IP, so that would be IMO only change on backend's side to apply such QoS to port forwarding also
14:13:25 <slaweq> and if that is true, I'm ok with that change
14:13:32 <slaweq> what do You think?
14:15:24 <yamamoto> api-wise it's intended to use the existing qos_policy_id field?
14:15:53 <slaweq> that's my assumption as we already have qos_policy_id in FIP
14:16:21 <slaweq> do You think we should ask about clarification on that?
14:17:33 <yamamoto> so right now qos_policy_id is not expected to affect port-forwarding traffic?
14:18:39 <slaweq> yes, I think so
14:19:43 <slaweq> but I'm not 100% sure
14:20:26 <yamamoto> so, this rfe is about changing the behaviour of the combination of qos-fip + port forwarding?
14:21:46 <slaweq> that is only my assumption :)
14:21:54 <yamamoto> i guess we should ask some clarification :)
14:22:02 <slaweq> I think I will ask about that in RFE and we can back to it next week
14:22:08 <slaweq> what do You think?
14:22:47 <yamamoto> +1 except that i guess we will skip next week
14:23:26 <slaweq> yep, so we will back to it on next meeting
14:23:49 <yamamoto> +1
14:24:03 <slaweq> ok, I will post questions after this meeting
14:24:11 <slaweq> lets go to the next one
14:24:13 <slaweq> https://bugs.launchpad.net/neutron/+bug/1793653
14:24:14 <openstack> Launchpad bug 1793653 in neutron "[RFE] Enable other subprojects to extend l2pop fdb information" [Wishlist,In progress] - Assigned to ChenjieXu (midone)
14:24:57 <slaweq> Chenjie: the floor is Yours :)
14:25:41 <Chenjie> thanks!
14:26:29 <Chenjie> Miguel asked about performance issues. I sent an email to WR to ask for performance issues but didn't got reply.
14:27:23 <Chenjie> Miguel said that he has sent an email to Thomas to ask his opinion on this RFE. I don't know whether Thomas reply or not.
14:27:32 <yamamoto> WR?
14:27:40 <Chenjie> WindRiver
14:27:50 <slaweq> no, tmorin didn't reply anything
14:27:57 <Chenjie> This RFE is a patch from StarlingX.
14:28:25 <Chenjie> StarlingX comes from WindRiver.
14:28:34 <yamamoto> i'm still not sure how it can work.  how do you distinguish agent ip for tunnels and your gateway ip?
14:29:47 <Chenjie> I think there is no need to distinguish agent_ip for tunnels and gateway ip.
14:30:00 <yamamoto> why not?
14:30:24 <Chenjie> For neutron network agent_ip is used. For bgp_vpn network gateway ip is used.
14:31:37 <slaweq> am I understand correctly that You want to have something which will allow subprojects to "plug into" l2pop logic and add own IP:mac pairs which neutron will send to agents?
14:32:30 <Chenjie> slaweq: yes!
14:32:41 <yamamoto> now i'm confused. maybe because i don't understand bgpvpn.
14:33:32 <yamamoto> maybe some examples of l2pop rpc payloads with this extension would help
14:33:46 <slaweq> ok, so in fact it's not on neutron's side to distinguish IPs, if some project will add SOME IP:MAC pair, neutron will just add fdb entries for it, right?
14:34:19 <Chenjie> yamamoto: yes, I think so. I will add some examples to the RFE later.
14:34:37 <yamamoto> thank you
14:34:40 <Chenjie> slaweq: yes!
14:34:52 <Chenjie> yamamoto: you are welcome!
14:35:12 <slaweq> Chenjie: ok, thx. I think that now I understand it more or less :)
14:35:32 <yamamoto> i have another concern. implications for non agent implementations. like odl
14:35:33 <slaweq> Chenjie: please add those examples to RFE to make it all 100% clear
14:35:58 <slaweq> yamamoto: are they using l2pop mechanism driver?
14:35:59 <Chenjie> slaweq: Ok, I will do that.
14:36:15 <yamamoto> slaweq: i don't think so
14:36:59 <yamamoto> if bgpvpn chose to propagate this info via l2pop, it won't be available to non-agent implementations
14:37:19 <yamamoto> isn't it a problem?
14:37:52 <Chenjie> yamamoto: it should not be problem.
14:38:39 <Chenjie> yamamoto: this RFE just wants to avoid broadcast. In non-agent implementations, they will just broadcast.
14:39:19 <Chenjie> yamamoto: this RFE can avoid the broadcast when the vm in the neutron network send packet to other networks.
14:40:22 <slaweq> yamamoto: here I agree with Chenjie - this is feature for l2pop, if e.g. odl wants to have something similar, they need to implement it on their own
14:41:34 <yamamoto> and make bgpvpn provide the same info in two different ways?
14:42:04 <slaweq> hmm, that is good point
14:43:03 <slaweq> how odl is today dealing with fdb entries for neutron ports? Do You know?
14:43:26 <slaweq> in other words, what they are using instead of l2pop mechanism
14:43:37 <yamamoto> i don't argue they should implement it for odl. but it might be better to have some abstraction.
14:43:53 <yamamoto> i don't know
14:44:00 <slaweq> yes, I know, odl is only an example here :)
14:45:12 <yamamoto> i'll ping some odl folk to look at the rfe later
14:45:31 <Chenjie> yamamoto: thanks!
14:45:35 <slaweq> yamamoto: ok, so let's wait for their feedback on it
14:45:44 <slaweq> and for Chenjie's examples too :)
14:45:54 <Chenjie> yamamoto: for now l2pop uses: ports:{agent_ip_1: [(mac_1, ip_1),(mac_2, ip_2)], agent_ip_2: [(mac_3, ip_3),(mac_4, ip_4)]}
14:46:07 <slaweq> and we will get back to this one also on next meeting, ok?
14:46:13 <Chenjie> yamamoto: other subprojects just need to add fdb in this format
14:46:25 <Chenjie> slaweq: Ok, thanks!
14:47:31 <slaweq> yamamoto: fine for You?
14:48:09 <yamamoto> Chenjie: i vaguely remember that there was some surrounding structure. "vxlan" or something.
14:48:37 <Chenjie> yamamoto: yes
14:48:53 <Chenjie> yamamoto: I will post the correct format in the RFE.
14:49:09 <yamamoto> Chenjie: thank you
14:49:14 <yamamoto> slaweq: yes
14:49:23 <slaweq> ok
14:49:31 <slaweq> lets go to the last one then
14:49:32 <slaweq> https://bugs.launchpad.net/neutron/+bug/1784590
14:49:33 <openstack> Launchpad bug 1784590 in neutron "neutron-dynamic-routing bgp agent should have options for MP-BGP" [Wishlist,In progress] - Assigned to Ryan Tidwell (ryan-tidwell)
14:51:16 <slaweq> IIUC this RFE, it's about adding possibility to annonce IPv6 prefixes to IPv4 peers
14:51:47 <yamamoto> it seems fine in general.  i wonder how we can/should expose different capabilities of different backends though.
14:54:08 <slaweq> yamamoto: You mean by API for example? or what exactly?
14:54:35 <yamamoto> for api users.
14:55:16 <slaweq> that's good question
14:55:46 <slaweq> is it done for any other capabilities currently? Do You know?
14:55:56 <tidwellr> it's not
14:56:05 <yamamoto> and the proposed patch seems to "just" change the behaviour. i wonder if it can be a compat problem.
14:56:43 <tidwellr> yamamoto: in its current state, you can applying the peering relationship via the API, but it fails silently
14:57:08 <slaweq> can we maybe add shim api extension which will expose if this feature is available or not?
14:57:44 <slaweq> tidwellr: in current API it is possible, so there will be no API change here, right?
14:58:41 <tidwellr> slaweq: right the user that encountered the bug assumed this should work because the API allows you to map peers to a BGP speaker of ip_version=4
14:59:03 <njohnston> wow, the DST change is really screwing me up
14:59:22 <slaweq> ok, so IMO this if fine to go like it is now
14:59:30 <slaweq> yamamoto: haleyb: what do You think?
14:59:48 <haleyb> i try not to think :)
14:59:58 <slaweq> sorry
15:00:00 <yamamoto> it's ok for me as far as the behaviour change is stated loudly in doc
15:00:15 <tidwellr> I agree that some sort of discoverability is needed here though
15:00:47 <slaweq> we are out of time now
15:01:01 <haleyb> seriously, the bug and change look ok, short of a release note.  but think the discovery would be a good thing as tidwellr states
15:01:37 <yamamoto> njohnston: i always feel lucky to live in a country without dst
15:01:55 <slaweq> I agree haleyb but maybe this discovery of features may be another rfe? of should it be included in this one?
15:02:11 <slaweq> ok, we need to finish
15:02:16 <slaweq> #endmeeting