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