05:35:14 <soichi> #startmeeting taas
05:35:15 <openstack> Meeting started Wed Jan 18 05:35:14 2017 UTC and is due to finish in 60 minutes.  The chair is soichi. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:35:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:35:18 <openstack> The meeting name has been set to 'taas'
05:35:30 <yamamoto> hi
05:35:39 <soichi> yamamoto: hi
05:35:53 <soichi> #topic: Loop detection of tap flows (cont.)
05:36:05 <soichi> #link: https://wiki.openstack.org/wiki/Meetings/taas
05:36:46 <reedip> we should reduce the documentation on this page !
05:37:06 <reedip> its getting out of hand :)
05:37:36 <soichi> reedip: do you have any good idea?
05:37:58 <reedip> soichi : to reduce the documentation on the wiki page ?
05:38:04 <soichi> yes
05:38:18 <reedip> soichi : yes, we do not need to keep the old agendas, as they would be covered in the meeting logs already
05:38:37 <reedip> If you still want to keep it, you can save it as a PDF and attach it here
05:38:55 <reedip> but it wont be too helpful as we are already discussing everything here
05:39:35 <soichi> okay, i agree
05:39:58 <reedip> soichi : sorry, I didnt get time for the Loop detection study. I think in the last meeting, we decided that ideally we should block this feature ( creating a Tap Flow, whose source port is a Tap-Service)
05:40:08 <yamamoto> please create a separate wiki page and move the contents if you want to save old ones.  not pdf.
05:40:20 <reedip> yamamoto : ok, and hi :)
05:40:30 <soichi> yamamoto: +1
05:40:48 <kaz> +1
05:41:04 <soichi> reedip: yes, we discussed how to gurad loop
05:41:35 <soichi> But, kaz syas loop can not be created
05:41:55 <soichi> #link: http://lists.openstack.org/pipermail/openstack-dev/attachments/20170118/eea51ee0/attachment-0001.pdf
05:42:14 <kaz> In the current implementation, I guess tap of tap mirrors just own traffic but not mirroed traffic.
05:43:00 <soichi> kaz: could you explain about the slide 1?
05:43:42 <kaz> In the current implementation, flow entry of tap-flow "IN" matches with the destination MAC address.
05:43:47 <reedip> kaz : are we considering bidirectional tap flows or only ingress ( input to VM) tap flows
05:44:05 <kaz> reedip: yes
05:44:21 <reedip> kaz : yes for bidirectional or yes for ingress only
05:44:56 <yamamoto> kaz: how about non unicast packets?
05:44:57 <kaz> reedip: bidirection :)
05:45:50 <reedip> ok
05:46:31 <kaz> yamamoto: non unicast packets also not match the rule.
05:48:36 <yamamoto> kaz: it doesn't match the rule, sure. but i think there are separate rules for those packets.
05:49:34 <reedip> kaz : still a bit unclear bcz of the use of DESTINATION keyword , because what u r stating in the slide is that the desitnation MAC which arrive at VM1 has VM1's MAC
05:50:22 <yamamoto> anyway, our current concern is the api semantics, not the reference impl, right?
05:50:54 <kaz> yamamoto:  yes
05:51:37 <soichi> i agree to gurad createting tap-flow on the port which has a tap-service, as the api semantics
05:52:42 <soichi> actually, we had the gurad on the GUI (Horizon) that we have implemented
05:53:32 <reedip> soichi : we can also gaurd it on the CLI but it would be better if we put a single gaurd on the API than to put it on different front ends
05:53:51 <soichi> reedip: agree
05:55:31 <reedip> njohnston, yamamoto : can we define a device id or device owner for taps?
05:55:35 <reedip> # link https://github.com/openstack/neutron/blob/a0e0e8b6686b847a4963a6aa6a3224b5768544e6/neutron/api/v2/attributes.py#L120
05:55:44 <reedip> #link https://github.com/openstack/neutron/blob/a0e0e8b6686b847a4963a6aa6a3224b5768544e6/neutron/api/v2/attributes.py#L125
05:56:15 <yamamoto> reedip: we can define anything. but why?
05:56:22 <njohnston> +1 to that
05:56:34 <reedip> yamamoto : that would be easier to check , isnt it ?
05:56:48 <yamamoto> reedip: for what?
05:56:48 <reedip> yamamoto : or do u want to check it with the db ?
05:57:25 <reedip> yamamoto: if we have the port object, then we can simply reference the device_owner/device_id for the port to identify if it is a tap_flow or not
05:57:41 <yamamoto> ah, i see.
05:57:49 <yamamoto> i don't think it's possible.
05:58:16 <yamamoto> because usually such a port belongs to compute and those fields are taken for that.
05:58:42 <reedip> yamamoto: when we create a port during creation of tap_service
05:58:59 <reedip> what would we put it in its device_id
05:59:20 <yamamoto> i don't see what's the benefit.
05:59:21 <reedip> currently we are specifying the network during creation of tap-service, and we create a tap_service_port ourselves
05:59:53 <yamamoto> currently?
05:59:57 <reedip> yamamoto : we can always refer the DB to see if the port id which is coming in as a source_port for tap_flow is already a tap_service
06:00:30 <reedip> if you want that logic, then it will also work
06:00:33 <yamamoto> i thought we removed network_id from tap_service
06:01:30 <reedip> yamamoto : u r right , sorry . I was referring the previous API
06:01:31 <yamamoto> i guess looking at ports table is no easier than looking at our tables
06:04:45 <soichi> i think we need to consider this topic a little bit more. Let's continue to the next week.
06:05:19 <soichi> #topic: Open Discussion
06:06:01 <soichi> Do you have any topic?
06:07:07 <yamamoto> anyone here is going to submit boston presentation?
06:07:45 <yamamoto> iirc dealine is around Feb 6
06:08:04 <soichi> wow!
06:08:24 <soichi> currently, i have no idea for presentation
06:09:13 <reedip> yamamoto : I think we can put up a presentation for Tacker with TaaS
06:09:31 <reedip> but I am still trying to think the basics of it
06:09:49 <yamamoto> tacker?  i have no idea how it's related with taas.
06:10:13 <reedip> tacker provides NFV solution to Openstack
06:10:22 <reedip> I was just thinking if we can do something with it
06:12:05 <yamamoto> it might or might not be a good idea.  i don't have enough knowledge to comment right now. :-)
06:12:25 <reedip> umm , okay, let me see if it can be done
06:13:28 <yamamoto> anyway thank you for showing the idea.
06:14:02 <reedip> yamamoto : sure, I will try and put up something related oto it
06:14:22 <reedip> njohnston : did ur taas devstack work ?
06:15:06 <njohnston> it did!  I was able to get it going once I made the taas stable/neutron same as the devstack branches.  oversight on my part.  thanks for all the help!
06:15:26 <yamamoto> good to hear
06:16:23 <reedip> :)
06:16:40 <reedip> nothing else from my side . BTW anyone coming to PTG ?
06:16:55 <yamamoto> i will be there
06:17:20 <soichi> i'm planning to attend PTG
06:19:25 <soichi> reedip: do we need to discuss how to put our presenation slides in the past summits as references?
06:19:26 <soichi> e.g. upload to SlideShare and put the link on the wiki
06:20:59 * njohnston will be at the PTG, see you there!
06:21:26 <yamamoto> i guess anywhere convenient is fine as far as it's publicly accessible
06:22:17 <soichi> yamamoto: okay, thank you for your comment
06:24:42 <soichi> no more topics from me
06:25:30 <yamamoto> me neither
06:25:43 <kaz> me too
06:27:01 <soichi> okay, thank you for today's discussions
06:27:05 <soichi> #endmeeting