14:00:32 <slaweq> #startmeeting neutron_drivers
14:00:33 <openstack> Meeting started Fri Feb 12 14:00:32 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:36 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:37 <slaweq> hi
14:00:38 <mlavalle> o/
14:00:44 <amotoki> hi
14:01:09 <haleyb> hi
14:02:01 <slaweq> lets wait few more minutes for ralonsoh and njohnston
14:02:11 <ralonsoh> hi (sorrY)
14:02:22 <slaweq> I think that Nate is not here today
14:02:37 <slaweq> and yamamoto already wrote an email that he will not be there
14:02:41 <slaweq> so I think we can start
14:02:44 <lajoskatona> o/
14:02:46 <slaweq> #topic RFEs
14:02:59 <slaweq> we have one RFE for today https://bugs.launchpad.net/neutron/+bug/1915151
14:03:01 <openstack> Launchpad bug 1915151 in neutron "[RFE] There should be a way to set ethertype for the vlan_transparent networks" [Wishlist,New] - Assigned to Slawek Kaplonski (slaweq)
14:03:46 <slaweq> Sean already made some comment there and I really like his idea about new extension and attibute "qinq" for networks
14:04:04 <slaweq> something similar to "vlan_transparency" but treated separately
14:04:52 <ralonsoh> because the goal of this RFE is to accept QinQ, right?
14:05:03 <slaweq> right
14:05:23 <slaweq> but in the way that user controls C-Tag in his own
14:05:31 <slaweq> something like we have now with vlan transparency
14:05:48 <slaweq> but we now send packets with 2 vlan tags and ethertype 0x8100
14:05:54 <slaweq> so it's not really qinq
14:06:09 <slaweq> and it can work e.g in tunnel networks also if backend supports that
14:06:12 <amotoki> my memory is ambiguous. Is C-tag an internal tag right?
14:06:20 <slaweq> amotoki: yes
14:06:23 <slaweq> it's inner tag
14:06:32 <slaweq> S-tag is the outer one
14:06:41 <slaweq> and that would be controlled by Neutron
14:06:56 <ralonsoh> yeah, we discussed about this in Atlanta and other meetings. I think the idea of having something different to vlan-transparency is better. And we can control the backends supporting it
14:06:58 <slaweq> that's at least use case which we have and would like to fit
14:07:10 <slaweq> yes
14:07:31 <slaweq> in fact control mechanism would be very similar to what we have now with vlan_transparency
14:07:40 <ralonsoh> agree
14:07:43 <amotoki> so, what we would like to achive is that VM sends C-tag and neutron adds S-tag, right?
14:07:53 <slaweq> amotoki: right
14:08:05 <amotoki> and is it out of scope that we allow VM to send QinQ itself?
14:08:09 <slaweq> and packet will have ethertype 0x8a88
14:08:24 <slaweq> amotoki: yes, vm will see "just" one vlan tag
14:08:44 <amotoki> slaweq: thanks for clarification
14:08:57 <slaweq> basically we have cu who was using vlan_transparency to achieve that
14:09:14 <lajoskatona> slaweq: how this differs from trunk?
14:09:41 <slaweq> but now some Cisco switches strips one vlan tag from packets if it's ethertype 0x8a88
14:10:08 <ralonsoh> trunk ports are transparent for the VM
14:10:11 <slaweq> lajoskatona: in this case user can configure any vlan tag in the vm, no matter what is configured in neutron
14:10:28 <slaweq> lajoskatona: and packet in underlay network has 2 tags
14:10:38 <lajoskatona> ah, ok ,so no preset segment_id or similar
14:10:41 <slaweq> with trunks, tag is changed and single tag is send to the wire
14:11:22 <lajoskatona> ok, thanks, I see now why this can be useful
14:12:40 <amotoki> you says neutron adds S-tag (outer tag), so what is the difference from a normal vlan neutron network case?
14:13:10 <slaweq> amotoki: the difference is that vm see packets with vlan tag (one)
14:13:22 <slaweq> so inside vm You need to configure e.g. eth0.100
14:13:34 <slaweq> this is similar to trunks
14:13:41 <amotoki> slaweq: it is about an inter tag (C-tag)
14:14:06 <slaweq> yes, C-tag is configured by user inside vm
14:14:21 <amotoki> I wonder the relationship between outer tag and a VLAN for a neutron VLAN network.
14:14:21 <slaweq> and S-Tag is neutron's tag added on the compute node
14:14:33 <amotoki> are both same?
14:14:35 <mlavalle> hence the name QinQ
14:14:37 <slaweq> amotoki: outer vlan is Neutron's vlan
14:14:58 <slaweq> so, let's say we have in neutron network with segmentation_id=10 (vlan network)
14:15:07 <slaweq> and it has this qinq feature enabled
14:15:13 <slaweq> so user can plug instance to it
14:15:20 <slaweq> and he will have eth0 interface in vm
14:15:31 <slaweq> so far, our normal vlan network, right?
14:15:48 <slaweq> and then user can also add eth0.100 or eth0.200 or whatever inside vm
14:16:10 <mlavalle> the Q in inQ
14:16:13 <slaweq> and packets send through eth0 will have then s-tag=10 (neutron) and c-tag=100 (vm)
14:16:16 <slaweq> mlavalle: exactly
14:16:20 <ralonsoh> the point is not to enforce the user to use any specific VLAN range, depending on the infrastructure
14:16:48 <amotoki> yeah, right
14:17:37 <mlavalle> We've had proposals for this before. To me, it is clearly needed, so I say +1
14:17:45 <ralonsoh> +1
14:18:02 <mlavalle> and I like Sean's proposal
14:18:45 <slaweq> I will not vote for that as I proposed it
14:18:47 <amotoki> for my understanding, the difference from vlan_tranceparency is that in case of vlan_transparency packets from VM are sent to a neutron network without any change right?
14:19:13 <slaweq> amotoki: difference is in fact in the ethertype which packets have
14:19:29 <slaweq> in vlan transparency it is 0x8100 (802.1q which is "normal" vlan)
14:19:48 <slaweq> and in that qinq case we want to send 0x8a88 which is really qinq
14:20:11 <slaweq> and also this qinq will be possible only for vlan networks
14:20:16 <amotoki> slaweq: packets you talk about is at the neutron network layer.
14:20:18 <slaweq> otherwise it doesn't makes sense
14:20:25 <amotoki> slaweq: what about packets from VM?
14:21:11 <slaweq> amotoki: I would need to check that but IIRC inside the vm it would be 0x8100 as there would be one vlan
14:21:19 <slaweq> hmm, that is good question
14:22:25 <amotoki> I think we need to clarify three cases (this prposal, trunk and vlan_transparency) from both of neutron network and a NIC in a guest VM.
14:22:41 <amotoki> * perspectives.
14:23:13 <slaweq> true
14:23:30 <slaweq> I will check all those cases and will update RFE next week
14:24:23 <amotoki> sounds fine. thanks
14:24:40 <slaweq> thx amotoki++
14:24:47 <slaweq> that's very good point to clarify
14:25:01 <slaweq> anything else do You want me to check before we will get back to that?
14:29:27 <amotoki> nothing else from me. If we can clarify the need and we dont' support it now, the RFE would make sense.
14:30:09 <slaweq> I will update it next week and we can get back to it
14:30:15 <slaweq> are You all ok with that?
14:30:20 <mlavalle> +1
14:30:24 <ralonsoh> yes
14:30:25 <amotoki> sounds good
14:30:29 <slaweq> thx
14:30:40 <haleyb> +1
14:30:51 <slaweq> if You would have any additional questions/doubts, please write a comment there
14:31:01 <slaweq> ok, that's all what I had for today
14:31:18 <slaweq> on demand agenda is also empty
14:31:29 <slaweq> so I think I can give You 30 minutes back today
14:31:40 <mlavalle> Just one point
14:31:40 <slaweq> thx for attending the meeting and have a great weekend :)
14:31:43 <slaweq> mlavalle: sure
14:31:58 <mlavalle> As soon as https://review.opendev.org/c/openstack/neutron-lib/+/774929 merges, can we do a neutron-lib release?
14:32:17 <slaweq> yes, I actually wanted to ask You about it today :)
14:32:29 <mlavalle> You are welcome ;-)
14:32:32 <slaweq> amotoki: are You ok with that?
14:33:12 <amotoki> slaweq: I am okay with that, but is it okay to add a new attribute to an existing API extension?
14:33:37 <slaweq> I was thinking about it
14:33:43 <lajoskatona> technically it will be a new extension if I understand well, or not?
14:33:54 <slaweq> but in that case IIRC we never really finished that address groups feature yet
14:34:01 <lajoskatona> which extends the previous extension
14:34:02 <ralonsoh> that's correct, this extension is not released yet
14:34:04 <slaweq> so IMHO in that case it would be fine
14:34:24 <mlavalle> that was our thinking
14:34:34 <lajoskatona> oh I see now, yeah I have the same understanding, it is the feautre of  this cycle, not an older one
14:34:51 <slaweq> so I tried to be more practical and not fall into "extensions madness" again ;)
14:34:59 <amotoki> good point. If we don't release it, we can do it.
14:35:23 <slaweq> btw, there is also one my patch waiting for review https://review.opendev.org/c/openstack/neutron-lib/+/770612
14:35:41 <slaweq> it's not critical so we don't need to wait for it but maybe You can take a look at it too?
14:36:04 <slaweq> I would then be able to work on the neutron part of fix for that issue
14:37:25 <amotoki> back to the first topic, the address group neutron extension is shipped as part of victoria release but is it incomplete right?
14:37:37 <slaweq> amotoki: right
14:37:59 <amotoki> thanks, so the current neutron-lib patch makes sense.
14:40:31 <slaweq> mlavalle: bad news is that it seems that we will not merge it without https://review.opendev.org/c/openstack/neutron/+/775357
14:40:54 <slaweq> as neutron-tempest-plugin-api is failing on that patch due to oslo_policy 3.6.2 :/
14:41:48 <mlavalle> ok, we need to work on that patch then, right?
14:42:06 <slaweq> I hope it can be merged soon
14:42:13 <slaweq> it is needed also to unblock other things
14:43:10 <slaweq> it's now in the check queue in zuul
14:43:16 <slaweq> so we need to be patient :)
14:43:46 <mlavalle> ok
14:43:47 <slaweq> mlavalle: but I will keep an eye on it and will try to merge all through the weekend to propose release of neutron-lib asap for You :)
14:43:48 <mlavalle> np
14:43:57 <mlavalle> thanks!
14:44:12 <slaweq> anything else to discuss today?
14:45:08 <mlavalle> not from me
14:45:41 <slaweq> if not, thx for attending and have a great weekend :)
14:45:46 <ralonsoh> have a nice weekend
14:45:48 <slaweq> see You online o/
14:45:51 <slaweq> #endmeeting