06:31:19 <anil_rao> #startmeeting taas
06:31:20 <openstack> Meeting started Wed Nov 25 06:31:19 2015 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:31:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:31:24 <openstack> The meeting name has been set to 'taas'
06:31:28 <yamamoto> hi
06:31:31 <anil_rao> Hi
06:31:35 <soichi> hi
06:31:37 <kaz> Hello
06:31:46 <reedip> o/
06:31:50 <dedery> Hi, just came to say hello. I'll not be able to attend
06:31:57 <dedery> Have a great meeting.
06:32:10 <anil_rao> Hi dedery
06:32:31 <anil_rao> Let's get started.
06:33:02 <reedip> Hi , I have some queries related to the API.
06:33:26 <reedip> maybe we can take them up at the end ?
06:33:46 <yamamoto> reedip: let's have "open discussion" after consuming the agenda items.
06:33:55 <reedip> agreed
06:34:12 <anil_rao> Any left over items from last week?
06:34:22 <yamamoto> #link https://wiki.openstack.org/wiki/Meetings/taas Agenda
06:34:42 <yamamoto> who added "More Core Reviewers needed"?
06:35:28 <anil_rao> No response ...
06:35:54 <anil_rao> Let's proceed to soichi's proposal then
06:36:01 <soichi> anil_rao: Thank you for your comments.
06:36:29 <anil_rao> Any thoughts from the others regarding this proposal.
06:37:56 <anil_rao> soichi: I have some questions, which I had put in my review comments. Can we discuss?
06:38:15 <soichi> Yes.
06:38:40 <anil_rao> First, the part about switching the port of the monitorng VM from br-int to br-tap.
06:39:06 <soichi> If port of a monitoring VM is reconnected from br_int to br_tap by the taas agent
06:39:13 <soichi> at the time of tap service creation, I guess any changes is not required to
06:39:24 <soichi> existing Neutron mechanism and TaaS API.
06:39:32 <soichi> I think port security can be disabled after a VM is deployed by using Neutron API:
06:39:41 <soichi> neutron port-update <port_id> --port_security_enabled False
06:40:34 <anil_rao> This might work okay but I am worried that we are getting too entrenched into details that should not really be a part of TaaS. Any thoughts?
06:41:18 <anil_rao> Consider the case when a tap-service instance is deleted. We will then have to restore the port back to br-int.
06:41:49 <soichi> Exactly
06:42:17 <anil_rao> I'll examine your patch more thoroughly. Thanks for posting it.
06:42:58 <soichi> Yes, please. We are waiting your feedback/
06:43:21 <soichi> Excuse me, but I'd like to ask about port security settings.
06:43:32 <soichi> I added following 3 lines in local.conf when I set up our site:
06:43:40 <soichi> 1. [[post-config|/$Q_PLUGIN_CONF_FILE]]
06:43:43 <anil_rao> Sure plese go ahead
06:43:48 <soichi> 2. [ml2]
06:43:56 <soichi> 3. extension_drivers=port_security
06:44:10 <soichi> In our site, a monitoring VM (connected to br_tap) can receive mirrored packets without disabling port security.
06:44:25 <soichi> I'm afraid that this is because our site has a wrong configuration on neutron or somewhere.
06:44:31 <soichi> What do you think?
06:44:51 <anil_rao> There were 2 issues w.r.t. getting traffic into the monitoring VM.
06:45:45 <anil_rao> Firstly, if port security is enabled, rules in iptables (Security groups implementation) prevent packets from entering the monitoring VM because the mac and ip addresses don't match.
06:46:13 <anil_rao> Disabling port-security allowed us to get this barrier.
06:47:02 <anil_rao> Furthermore, mac-address learning in the Linux bridge (connecting the OVS port to the monitoring VM's vNIC) was preventing packets from getting through. So we disabled this and essentially turned the bridge into a hub
06:47:32 <anil_rao> I am surprised how you are able to get past these in your environment.
06:48:54 <soichi> We have set mac address leaning disabled.
06:49:43 <anil_rao> Are security groups functional in your environment?
06:51:51 <soichi> Yes, I think so. We configured the default security group to through ICMP and SSH.
06:52:52 <anil_rao> Essentially there are mac-address spoofing and ip address spoofing rules in iptables that will prevent typical mirrored packets from getting through to the monitoring VM, unless port-security is disabled.
06:54:05 <anil_rao> Let's discuss this on the mailing list.
06:54:08 <soichi> ok. we will check mac-address spoofing and ip address spoofing.
06:54:13 <soichi> Sure
06:54:43 <anil_rao> I was hoping to hear from some of the others regarding the other item, which is dedicated tunnels for TaaS, as opposed to using the existing Neutron inter-host tunnels.
06:54:55 <anil_rao> Anyone?
06:55:56 <yamamoto> i'm afraid it requires ovs-agent be more aware of taas.
06:56:57 <kaz> for example?
06:57:15 <yamamoto> eg. moving ports between bridges would make ovs-agent think the port is plugged/unplugged
06:57:39 <kaz> i see.
06:59:23 <anil_rao> How about the dedicated tunnels vs existing tunnels. I see it being a lot of work if TaaS were to maintain its own set of tunnels. Any thoughts from the others?
07:01:04 <anil_rao> OK, lets move to th next item.
07:01:14 <soichi> I have one more item.
07:01:20 <anil_rao> Yes
07:01:24 <yamamoto> i have a mixed feeling about the dedicated tunnel idea.
07:01:27 <soichi> On the openstak-dev mailing list, we got a message from Fawad?
07:01:34 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080136.html
07:01:40 <soichi> What should we do?
07:03:22 <yamamoto> i guess someone should explain the history of the bp and the current taas project.
07:03:28 <yamamoto> on ML.
07:03:49 <anil_rao> I can take a stab at that.
07:03:59 <soichi> Thank you.
07:04:16 <reedip> There's not much written on the BP as such
07:04:27 <anil_rao> I'll post there tomorrow (its 11:00 pm here now). :)
07:04:50 <reedip> Maybe a neutron page ( like the spec up for review) would be an ideal way to approach this ?
07:05:10 <anil_rao> The original BP is quite old. The TaaS spec (which got initiated after the Atlanta summit) is more relevant.
07:05:57 <anil_rao> Dedicated tunnels would mean that we essentially reimplement a lot of stuff that Neutron/ML2 is already doing today.
07:08:01 <anil_rao> I believe performance isolation is something that should be of general interest for regular production traffic too. That is how to ensure good performance for different neutron provisioned virtual networks.
07:08:25 <anil_rao> TaaS mirrored traffic is just another type of production traffic IMHO.
07:08:36 <yamamoto> +1
07:09:47 <soichi> We are planning to measure performance. I'd like to discuss with numbers.
07:10:36 <anil_rao> soichi: That would be great.
07:14:13 <anil_rao> We should also not forget that while service provider initiated monitoring is 'important' we would also want TaaS to be used by individual tenants. So it may not be always be possible  to have multiple host level NICs.
07:14:55 <soichi> I see.
07:17:59 <anil_rao> Do folks want to discuss the last few lines in the agenda?
07:18:57 <anil_rao> I did not understand what was meant by 'IP addresses of underlay networks are hard-coded.
07:19:57 <soichi> IP addresses of hosts required to create a dedicated tunnel.
07:20:15 <anil_rao> okay.
07:21:27 <anil_rao> the br-tun tunnel mgmt is quite sophisticated. New tunnels are automatically created when hosts come on-line for example.
07:23:50 <soichi> It can be one of a idea.
07:24:43 <soichi> We did not create full-mesh tunnles to avoid loop.
07:26:21 <anil_rao> Your solution may not necessarily require a full mesh, but I fear that if there are enough tap-service instances and tap-flows to them, we might end up with a very complex array of TaaS dedicated tunnels. At this point, we will be essentially re-doing everything ML2 Neutron does today to handle the various corner cases.
07:27:42 <anil_rao> Let's continue this discussion on the mailing list. I'll post my original review comments to your thread there and we'll proceed then. Does this sound okay?
07:27:46 <soichi> I will consider your comment.
07:27:50 <soichi> ok
07:28:25 <yamamoto> even if we want to use dedicated tunnels, it's better to make ovs-agent create another set of tunnels for us, rather than having our copy of tunnel management code.
07:28:36 <anil_rao> Agree
07:28:45 <yamamoto> it would be easier if we turn our agent to an agent extension.
07:29:25 <yamamoto> 2 mins left for open discussion. :-)
07:29:45 <anil_rao> yamamoto: We should definitely consider this. Even if not the full TaaS agent, some parts of it could definitely be an agent extension.
07:30:13 <anil_rao> redeep?
07:30:18 <reedip> Hi, if the open-discussion is open , I wanted to discuss some points about the API
07:30:30 <anil_rao> Yes
07:30:36 <reedip> a) is it required to list the API end points under /taas/?
07:30:57 <anil_rao> Looks like we are out of time. Can we continue this next week.
07:31:10 <reedip> hmm....
07:31:33 <anil_rao> reedip: Sorry. Next week you go first.
07:32:10 <anil_rao> redeep: Also, please start a discussion thread on the mailing list and we'll all join in there.
07:32:37 <anil_rao> I stop the meeting now. It is past 11:30 pm (PST). Thanks, Bye.
07:32:44 <soichi> Thank you.
07:32:47 <yamamoto> bye
07:32:49 <kaz> bye
07:32:55 <anil_rao> #endmeeting