16:03:33 <Sukhdev_> #startmeeting: networking_ml2
16:03:34 <openstack> Meeting started Wed May 24 16:03:33 2017 UTC and is due to finish in 60 minutes.  The chair is Sukhdev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:37 <openstack> The meeting name has been set to '__networking_ml2'
16:03:50 <Sukhdev_> #topic: Agenda
16:03:55 <Sukhdev_> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_May_24.2C_2017
16:04:19 <Sukhdev_> I have kept the agenda open and we can add as we go along
16:04:31 <Sukhdev_> #topic: Announcements
16:04:53 <Sukhdev_> Anybody has something to announce/share ?
16:05:06 <rkukura> nothing from me
16:05:30 <trevormc> i do
16:05:37 <trevormc> just wanted to say I made two more RFEs
16:05:45 <Sukhdev_> trevormc : please go ahead
16:05:52 <trevormc> https://bugs.launchpad.net/tap-as-a-service/+bug/1693248 [RFE] Mirror VF Ports and https://bugs.launchpad.net/neutron/+bug/1693240 [RFE] Support SRIOV VF VLAN Filtering
16:05:54 <openstack> Launchpad bug 1693248 in tap-as-a-service "[RFE] Mirror VF Ports" [Undecided,New]
16:05:55 <openstack> Launchpad bug 1693240 in neutron "[RFE] Support SRIOV VF VLAN Filtering" [Undecided,New]
16:06:21 <trevormc> so now I don't know if this is ML2 related anymore
16:06:38 <Sukhdev_> trevormc : I thought you had 5
16:07:11 <trevormc> i did without the 5th one. We don't have a need for only pushing or only popping VLAN tags / customer tags
16:07:27 <trevormc> OVS does push/pop operations for us so we can use that I guess.
16:07:56 <Sukhdev_> I see
16:08:08 <Sukhdev_> any other announcement?
16:08:34 <Sukhdev_> #topic: RFEs/Bugs
16:08:53 <Sukhdev_> trevormc : do you want to discuss these FREs?
16:09:09 <trevormc> Yeah did I file the tap-as-a-service RFE correctly?
16:09:31 <trevormc> I wasn't sure if I could do it as a bug in neutron, or a blueprint in taas.. i just did a bug in taas
16:10:58 <trevormc> I'm not sure do any of you have questions on them?
16:11:14 <trevormc> are they relevant to ML2?
16:12:05 <Sukhdev_> trevormc : so, depending upon how you plan on implementing it, will dictate where it belongs
16:12:50 <Sukhdev_> you should add some details to the RFE to provide the context
16:13:17 <trevormc> yeah I don't really know the details lol
16:13:21 <Sukhdev_> for instance, how would you like this to be configured? will this be admin or tenant scoped, etc
16:13:54 <rkukura> trevormc: Are the features (not the implementations) you are proposing something useful in general (with any ML2 MD), or only with SR-IOV?
16:14:26 <trevormc> The two I mentioned today are specifically for SR-IOV because of VFs
16:15:10 <rkukura> trevormc: For instance, what does “allocate a range of VLANs to a port” mean for a port that isn’t SR-IOV? This almost sounds like a trunk port to me.
16:16:10 <trevormc> rkukura, yes I believe it should be trunk port. The link from ML indicates it only supports one VLAN.
16:16:51 <trevormc> I just lack the technical details. I thought I could put this idea out there and we could work together to make some sense out of i.t
16:17:17 <trevormc> At AT&T they only understand the SR-IOV use cases so thats all i can tell you.
16:17:20 <rkukura> So is this RFE about implementing the existing trunk port feature using SR-IOV?
16:17:42 <trevormc> I think it already works, just for one VLAN.
16:18:28 <rkukura> Isn’t a “trunk port” a port that provides the VM with access to a set of neutron networks as VLANs on a vNIC?
16:19:02 <trevormc> yeah that's the intention.
16:19:25 <rkukura> So I’m not clear on what you mean bt “for one VLAN” in this context?
16:19:37 <Sukhdev_> rkukura : correct - that is what trunk port does
16:20:20 <sadasu> trevormc: can you elaborate on the use case ?
16:20:52 <Sukhdev_> It almost sounds like the RFE should be to say - extend trunked vlan support to SRIOV ports
16:21:03 <Sukhdev_> that is, if it already does not do it
16:21:32 <trevormc> I asked the research team they said "supporting VNFs that manipulate VLANs inherently multi-tenant"
16:22:02 <trevormc> filtering traffic at the port level helps us do that.
16:22:13 <trevormc> I'm having a hard time asking the right questions I guess..
16:22:25 <trevormc> do either of you know pcarver?
16:22:49 <trevormc> he has been helping me get this information but I get like 30 minutes every two weeks.
16:22:50 <rkukura> trevormc: I’ve met him, but have not worked closely with him.
16:23:10 <Sukhdev_> trevormc : yes, I know pcarver well :-)
16:23:47 <trevormc> so the problem here is, I don't understand the technology and upstream doesn't know what I'm asking
16:24:56 <Sukhdev_> trevormc : my suggestion is to have pcarver help you fill in the details in the RFE - this will help every body understand as to what is that you are trying to do
16:25:35 <trevormc> yeah I was just about to do that
16:26:24 <rkukura> trevormc: I suggest trying to articulate a use case in the RFE that cannot be currently addressed with Neutron, and how a test would be structured for that use case.
16:26:29 <Sukhdev_> trevormc : here is my suggestion - try creating a trunked port, add bunch of networks to this port and run a VM with SRIOV interface and play with it and see what you see and what you do not know - you may be surprised
16:27:02 <rkukura> Sukhdev_: that’s the test part I was suggesting ;)
16:27:15 <Sukhdev_> rkukura : +1
16:27:40 <trevormc> ok, ill see if I can get access to a lab with that hardware..
16:28:33 <Sukhdev_> trevormc : you may want to ping rossella__  about the trunked port information. She can tell you if this will work with SRIOV or not and most likely give you advise as to what is the quick way to get this going
16:29:00 <rkukura> Sukhdev_: +1
16:29:17 <trevormc> ok ill see if shes around, thanks.
16:29:25 <trevormc> I heard VSPerf may be an option.
16:30:32 <trevormc> ok i didnt have anything else on this.
16:30:36 <Sukhdev_> trevormc : I think rossella__ is the right person to start with
16:31:28 <yamamoto> trevormc: this vsperf you mean? https://wiki.opnfv.org/display/vsperf/VSperf+Home
16:31:35 <trevormc> yes
16:31:44 <trevormc> yamamoto, yes
16:33:17 <Sukhdev_> trevormc : do you have another RFE to discuss?
16:34:12 <trevormc> Sukhdev_: nothing new, just the QinQ driver should be ready for review.
16:34:45 <Sukhdev_> trevormc : cool - thanks
16:35:06 <yamamoto> trevormc: wrt bug 1693248, i guess taas meeting is more appropriate.  http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting
16:35:07 <openstack> bug 1693248 in tap-as-a-service "[RFE] Mirror VF Ports" [Undecided,New] https://launchpad.net/bugs/1693248
16:35:40 <trevormc> one thing I think that may need to change in the patch is the get_mtu, I think I need to account for multiple headers.
16:36:10 <trevormc> yamamoto, yeah I think that will be an early morning for me. Thanks for the suggestion.
16:36:34 <trevormc> yamamoto, I think its like 2:30 in the morning for me at that time lol.
16:37:14 <trevormc> 00:30 , late night I guess.
16:37:48 <trevormc> Sukhdev_, no more bugs/RFEs to discuss from me.
16:37:49 <yamamoto> trevormc: this meeting is 1:00am for me. :-)   you can always use ML instead.
16:38:25 <trevormc> I think ML it will have to be.
16:38:32 <Sukhdev_> yamamoto :  you and I covered the monolithic DB transfer over neutron channel - do you want to discuss any further details here?
16:40:25 <yamamoto> Sukhdev_: i have no specific thing to discuss
16:40:33 <Sukhdev_> yamamoto : cool
16:40:50 <Sukhdev_> #topic: Open Discussion
16:41:10 <Sukhdev_> Any body want to cover anything which we have not discussed already?
16:42:26 <Sukhdev_> look like we are done
16:42:34 <Sukhdev_> Thanks folks
16:42:43 <Sukhdev_> have a wonderful day
16:42:46 <Sukhdev_> bye
16:42:47 <trevormc> thanks everyone
16:42:53 <Sukhdev_> #endmeeting