14:01:44 <sc68cal> #startmeeting ipv6_neutron
14:01:45 <openstack> Meeting started Tue Apr  1 14:01:44 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:48 <openstack> The meeting name has been set to 'ipv6_neutron'
14:02:59 <sc68cal> Currently, there is mostly a focus on the RC-1 release
14:03:33 <sc68cal> Also, yesterday during the main meeting it was announced that Neutron is going to be following the lead of Nova and other projects when it comes to blueprints
14:03:54 <sc68cal> meaning, that blueprints are going to move from Launchpad, to a git repository managed by Gerrit
14:04:38 <sc68cal> an e-mail to the ML explaining the move is pending, but if you've been following the ML, you can check out the thread over in Nova to get an idea
14:04:53 <baoli> yea, just heard about that too.
14:06:12 <sc68cal> Also - I'd like to solicit people's opinions on the way the current subteam is organized
14:06:58 <sc68cal> For a while in the beginning, I tried to make an agenda on the wiki for every week's meeting, and follow the same couple of topics each meeting
14:07:14 <sc68cal> recap, blueprints, bugs, open discussion
14:08:01 <sc68cal> But it's been a one-man process with not a lot of input from everyone else
14:08:45 <sc68cal> Is everyone comfortable with the format, or does there need to be changes?
14:10:11 <sc68cal> Some of the other teams have put a lot of stuff on their subteam wiki pages, for each meeeting - and most of the time ours is just a copy and paste of the same bullet points
14:11:09 <xuhanp> sc68cal, any suggestions about how to include more content in our meeting?
14:11:59 <sc68cal> xuhanp: for a couple of the first meetings I would shoot an e-mail to the ML with a link to the wiki, and ask people to add stuff to the agenda if they wanted to talk about something
14:12:49 <xuhanp> sc68cal, that sounds helpful!
14:15:12 <sc68cal> So, it's just a thought I had - and I wanted to bring it up with the group and see if there was any feedback. If the current pattern of recap, blueprints, bugs, and open discussion works for everyone, I can continue doing it, but I'll also check our subteam wiki for stuff that people want to talk about
14:15:48 <aveiga> sc68cal: maybe we can solicit a feature request list at the summit?
14:15:53 <aveiga> continue as we are until then
14:16:39 <sc68cal> aveiga: that sounds like a good idea - I know the LbaaS team just set up a wiki page for use cases and asked people to start listing theirs
14:16:45 <sc68cal> and shot it to the ML
14:21:05 <sc68cal> So - I'm not sure what the procedure is for the RCs - when it comes to getting patches like the filtering of RAs from subnet gateways and router devices
14:21:11 <sc68cal> merged
14:21:33 <aveiga> I think it's only bugfixes
14:21:37 <aveiga> not new stuff
14:22:13 <xuhanp> aveiga, my patch is delivered by a bug fix :-)
14:22:48 <xuhanp> I am having some final tests, and I will ping some core member once I get the -1 address.
14:22:59 <aveiga> what I meant was, unless it fixes an issue introduced in RC1, they likely won't accept it until Juno
14:23:09 <aveiga> but ask anyway
14:23:19 <xuhanp> aveiga, good to know
14:24:12 <xuhanp> since we are talking about security, do we want to consider other security enhancement?
14:24:16 <xuhanp> for IPv6
14:24:34 <sc68cal> sure!
14:24:46 <xuhanp> this was also mentioned by �douard Thuleau on my patch.
14:25:32 <xuhanp> one question is about if we should drop egress RA like RA guard.
14:25:55 <aveiga> you mean drop RAs being sent from a VM?
14:26:07 <sc68cal> https://review.openstack.org/#/c/72252/
14:26:07 <djoreilly> think so, vms have no business sending them
14:26:15 <aveiga> djoreilly: not true!
14:26:17 <sc68cal> 'Édouard Thuleau'
14:26:33 <aveiga> run a Load Balancer or firewall in a VM. If it's a gateway for a private tenant network, it issues RAs
14:27:04 <djoreilly> so they are serice type vms
14:27:05 <aveiga> I think we should only drop them if they aren't also listed as Neutron gateways for that subnet
14:27:50 <xuhanp> aveiga, that was my thought. But in that case, since we limit the ingress RA to gateway, why do we need to drop them?
14:28:15 <aveiga> we shouldn't, that's exaclt my point.  If they're listed, we don't drop them.  If they aren't listed, we can drop them
14:28:24 <aveiga> exactly*
14:28:43 <djoreilly> ok
14:29:01 <xuhanp> aveiga, even if they are not listed, the RA cannot going into other VMs, right?
14:29:12 <xuhanp> is the drop necessary?
14:29:44 <xuhanp> Oh. I see your point. you are saying they are already dropped?
14:29:47 <aveiga> yes, I don't think we want to accidentally announce RAs to a provider network, since there might be otehr devices on that network not owned by openstack
14:29:48 <xuhanp> by default rule?
14:30:13 <xuhanp> aveiga, OK. I see.
14:30:26 <xuhanp> that maybe something worth improving in Juno.
14:30:29 <aveiga> I don't think it's a huge risk right now though
14:30:33 <aveiga> yeah, that's a Juno thing
14:30:56 <aveiga> we'll want to wait for a better SG setup anyway, since this is going to cause a LOT of extra rules in iptables right now
14:31:09 <aveiga> I'm concerned about hurting network performance by installing t oo many of them
14:31:46 <sc68cal> I know there was work being done on adding IPSets support
14:32:01 <aveiga> sc68cal: that own't help here
14:32:04 <sc68cal> but that was a long time ago and I haven't heard anything since like...... grizzly summit
14:32:15 <aveiga> this is rule duplication per VM tap port, not a list of addresses
14:32:44 <aveiga> xuhanp: why don't you write this as a line item in the subteam wiki and mark it to be addressed in Juno?
14:33:08 <xuhanp> aveiga, sure. will do.
14:34:02 <xuhanp> #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno
14:34:36 <sc68cal> I think I have to do it to make openstack pay attention :)
14:34:40 <sc68cal> #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno
14:35:05 <aveiga> without the leading space
14:35:11 <sc68cal> #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno
14:35:34 <xuhanp> sc68cal, thanks
14:37:40 <xuhanp> also �douard Thuleau added a PDF about IPv6 security rules from Cisco to help inspire the security enhancement
14:37:51 <xuhanp> #link http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/aag_c45-707354.pdf
14:39:05 <sc68cal> I haven't looked at the PDF yet - but depending on the scope it may be worth a blueprint for just that
14:39:32 <aveiga> I think parts of this are worth looking into
14:39:42 <aveiga> some of it may be overkill and degrade performance though
14:39:51 <xuhanp> there are interesting points about Ipv6 snooping
14:40:38 <aveiga> we're already fixing the RA and DHCPv6 parts
14:44:43 <sc68cal> If there isn't anything else, I can give everyone 15 minutes back
14:45:12 <xuhanp> sc68cal, a quick question. does anyone has any experience on the unit test of neutron client?
14:45:20 <xuhanp> I have some trouble with that and need some help
14:45:30 <sc68cal> I have some, from doing the qos api extension
14:45:52 <xuhanp> great! can I talk to you in neutron IRC?
14:45:58 <sc68cal> sure!
14:46:12 <xuhanp> sc68cal, thanks a lot!
14:46:19 <sc68cal> either that or we can talk over e-mail, I know it's getting late for you
14:46:51 <xuhanp> sc68cal, thanks. Let me try IRC first.
14:46:59 <sc68cal> alright everyone - until next week
14:47:02 <sc68cal> #endmeeting