14:01:44 #startmeeting ipv6_neutron 14:01:45 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:48 The meeting name has been set to 'ipv6_neutron' 14:02:59 Currently, there is mostly a focus on the RC-1 release 14:03:33 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 meaning, that blueprints are going to move from Launchpad, to a git repository managed by Gerrit 14:04:38 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 yea, just heard about that too. 14:06:12 Also - I'd like to solicit people's opinions on the way the current subteam is organized 14:06:58 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 recap, blueprints, bugs, open discussion 14:08:01 But it's been a one-man process with not a lot of input from everyone else 14:08:45 Is everyone comfortable with the format, or does there need to be changes? 14:10:11 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 sc68cal, any suggestions about how to include more content in our meeting? 14:11:59 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 sc68cal, that sounds helpful! 14:15:12 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 sc68cal: maybe we can solicit a feature request list at the summit? 14:15:53 continue as we are until then 14:16:39 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 and shot it to the ML 14:21:05 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 merged 14:21:33 I think it's only bugfixes 14:21:37 not new stuff 14:22:13 aveiga, my patch is delivered by a bug fix :-) 14:22:48 I am having some final tests, and I will ping some core member once I get the -1 address. 14:22:59 what I meant was, unless it fixes an issue introduced in RC1, they likely won't accept it until Juno 14:23:09 but ask anyway 14:23:19 aveiga, good to know 14:24:12 since we are talking about security, do we want to consider other security enhancement? 14:24:16 for IPv6 14:24:34 sure! 14:24:46 this was also mentioned by �douard Thuleau on my patch. 14:25:32 one question is about if we should drop egress RA like RA guard. 14:25:55 you mean drop RAs being sent from a VM? 14:26:07 https://review.openstack.org/#/c/72252/ 14:26:07 think so, vms have no business sending them 14:26:15 djoreilly: not true! 14:26:17 'Édouard Thuleau' 14:26:33 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 so they are serice type vms 14:27:05 I think we should only drop them if they aren't also listed as Neutron gateways for that subnet 14:27:50 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 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 exactly* 14:28:43 ok 14:29:01 aveiga, even if they are not listed, the RA cannot going into other VMs, right? 14:29:12 is the drop necessary? 14:29:44 Oh. I see your point. you are saying they are already dropped? 14:29:47 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 by default rule? 14:30:13 aveiga, OK. I see. 14:30:26 that maybe something worth improving in Juno. 14:30:29 I don't think it's a huge risk right now though 14:30:33 yeah, that's a Juno thing 14:30:56 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 I'm concerned about hurting network performance by installing t oo many of them 14:31:46 I know there was work being done on adding IPSets support 14:32:01 sc68cal: that own't help here 14:32:04 but that was a long time ago and I haven't heard anything since like...... grizzly summit 14:32:15 this is rule duplication per VM tap port, not a list of addresses 14:32:44 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 aveiga, sure. will do. 14:34:02 #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno 14:34:36 I think I have to do it to make openstack pay attention :) 14:34:40 #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno 14:35:05 without the leading space 14:35:11 #action xuhanp to write egress rule improvement in wiki and mark it to be addressed in Juno 14:35:34 sc68cal, thanks 14:37:40 also �douard Thuleau added a PDF about IPv6 security rules from Cisco to help inspire the security enhancement 14:37:51 #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 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 I think parts of this are worth looking into 14:39:42 some of it may be overkill and degrade performance though 14:39:51 there are interesting points about Ipv6 snooping 14:40:38 we're already fixing the RA and DHCPv6 parts 14:44:43 If there isn't anything else, I can give everyone 15 minutes back 14:45:12 sc68cal, a quick question. does anyone has any experience on the unit test of neutron client? 14:45:20 I have some trouble with that and need some help 14:45:30 I have some, from doing the qos api extension 14:45:52 great! can I talk to you in neutron IRC? 14:45:58 sure! 14:46:12 sc68cal, thanks a lot! 14:46:19 either that or we can talk over e-mail, I know it's getting late for you 14:46:51 sc68cal, thanks. Let me try IRC first. 14:46:59 alright everyone - until next week 14:47:02 #endmeeting