15:01:38 <sc68cal> #startmeeting neutron_ipv6
15:01:39 <openstack> Meeting started Tue Nov 25 15:01:38 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:43 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:56 <sc68cal> #topic Blueprints & Specs
15:03:08 <raorn> hi
15:03:12 <baoli> sc68cal: I submitted a review last night: https://review.openstack.org/#/c/136878/
15:03:19 <sc68cal> If you haven't seen on the ML yet, HenryG and I had some good comments on a spec about Kilo priorities, and we now have an IPv6 Impact section for all specs, for the kilo cycle
15:03:28 <TapioTallgren> Opnfv
15:03:36 <sc68cal> baoli: awesome
15:03:50 <sc68cal> #link https://review.openstack.org/#/c/136878/ Support IPv6 routers and DVRs
15:04:21 <sc68cal> #link https://review.openstack.org/#/c/136514/ Kilo Priorities for Neutron
15:04:53 <johnbelamaric> sc68cal: I will be updating the IPAM spec either today or tomorrow. I'd like to get this team's input
15:04:57 <johnbelamaric> #link https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
15:05:36 <johnbelamaric> in particular, we are trying to put in a framework that will allow future support for DUID-EN - right now I think we can only support DUID-LL
15:06:01 <raorn> so, last time i showed you my fixed-ip-version bp
15:06:06 <raorn> #link https://review.openstack.org/#/c/129910
15:06:07 <sc68cal> johnbelamaric: are you coordinating your work with Carl Baldwin?
15:06:37 <johnbelamaric> sc68cal: yes, we had a long IRC meeting yesterday and are working closely on this
15:07:21 <sc68cal> johnbelamaric: perfect, we'll keep an eye on IPAM, thanks for keeping us in the loop :)
15:07:51 <johnbelamaric> sc68cal: no problem, expect an update tomorrow - just looked at my calendar today and probably won't be able to finish it today
15:08:50 <xuhanp> johnbelamaric, is https://review.openstack.org/#/c/97967/ the link for the spec review?
15:08:53 <sc68cal> johnbelamaric: ok, no problem
15:08:57 <HenryG> raorn: I still have your spec on my radar. I hope it is small and innocuous enough to not meet any resistance.
15:09:27 <sc68cal> ^ +1
15:09:34 <raorn> well, i need your wisdom
15:09:47 <johnbelamaric> xuhanp: yes, but major updates will be submitted. if you follow that comment chain, Carl has posted a much newer WIP interface
15:09:47 <raorn> i've updated the "alternative" section today
15:10:18 <sc68cal> johnbelamaric: is it this? https://review.openstack.org/#/c/135771/
15:10:18 <xuhanp> johnbelamaric, great to know that. Thanks
15:10:40 <johnbelamaric> #link https://review.openstack.org/#/c/134339/
15:10:41 <raorn> current described approach was logical at the time it was implemened, but now SLAAC networks messed the whole thing (in a good way)
15:10:50 <HenryG> raorn: I did not see that. I'll look at it and give it some thought.
15:12:33 <HenryG> raorn: What is meant by "top-level" attribute?
15:13:35 <raorn> the thing near "network_id", "name", etc...
15:15:06 <johnbelamaric> sc68cal: no, that is a different spec, but also a good one for htis team to review
15:16:11 <sc68cal> johnbelamaric: thanks
15:16:23 <sc68cal> So..... we have a lot of specs to review ! :)
15:16:34 <raorn> HenryG: "ip allocation policy" spec is not written yet, i just want to be sure that this idea worth the effort
15:17:26 <HenryG> raorn: I understand. I am having a hard time keeping up with all the specs.
15:18:07 <johnbelamaric> I am not familiar with "ip allocation policy", this may overlap with the IPAM spec
15:18:41 <HenryG> johnbelamaric: I hope they are the same.
15:19:11 <johnbelamaric> HenryG: me too, i am looking for the BP
15:19:17 <raorn> johnbelamaric: currently neutron tries to allocate one IPv4 address and one (well, not one) IPv6 address. if something fails - port is not created
15:19:34 <sc68cal> raorn: yeah I'm trying to find the patch proposed to fix that
15:19:49 <sc68cal> i'm really interested in it since I have a /28 and a /64 for my lab :)
15:19:53 <raorn> sc68cal: https://review.openstack.org/125061
15:20:00 <sc68cal> raorn: thx :)
15:20:32 <johnbelamaric> raorn: ok, so that is directly in the code that will be refactored so we just need to make sure it gets handled properly during refactor
15:21:04 <raorn> so idea is to have per-network property, that will control allocation of fixed ips
15:22:07 <raorn> default allocation, when fixed_ips was not set
15:22:18 <johnbelamaric> raorn: ok, but this is about the policy of whether an exception is thrown when not all IPs can be allocated. reading the comments now
15:23:10 <raorn> there are also comments and "alternative" section in https://review.openstack.org/129910
15:25:13 <sc68cal> OK, in the interest of time I'm going to move on to bugs - overall I think we have a ton of specs that we need to review
15:25:40 <sc68cal> raorn: welcome to the subteam, you're doing good stuff! :)
15:25:45 <johnbelamaric> raorn: ok, just looks like this needs to be coordinated but makes sense
15:26:18 <sc68cal> #info We have a ton of specs that need reviewing
15:26:22 <sc68cal> #topic bugs
15:26:31 <raorn> ok! i am making the "ip allocation policy" bp then
15:26:34 <raorn> thanks!
15:26:38 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6
15:26:41 <salv-orlando> spec 129910 is good for me once ipv6 impact flag is added
15:27:00 <salv-orlando> I’ve looked at the alternative and with the tools we have so far this is probably the best we can achieve
15:27:14 <sc68cal> salv-orlando: excellent - thank you!
15:27:42 <raorn> salv-orlando: looking at current code, i think "alternative" approach is more logical...
15:28:20 <HenryG> salv-orlando: Did you see the latest update in the "Alternative" section in 129910?
15:28:31 <HenryG> jinx
15:29:16 <salv-orlando> HenryG knows I don’t actually review specs but I shake the 8-ball to give a vote
15:29:26 * sc68cal rolls a d20
15:29:29 <salv-orlando> anyway, we’re in the bugs section now. I will comment on the spec.
15:30:12 <sc68cal> So I think the biggest bug on my radar is https://bugs.launchpad.net/neutron/+bug/1376325
15:30:14 <uvirtbot> Launchpad bug 1376325 in neutron "Cannot enable DVR and IPv6 simultaneously" [Medium,In progress]
15:30:34 <sc68cal> I'd probably bump it to High, if I were able to
15:30:48 <Rajeev> I have a review in progress for part of the fix
15:30:49 <HenryG> I think haleyb is working on that?
15:30:51 <sc68cal> it may not be high for the overall neutron effort, but it's probably high on the subteam list
15:31:01 <HenryG> Ah, thanks Rajeev
15:31:09 <Rajeev> https://review.openstack.org/#/c/134676/
15:31:19 <sc68cal> Rajeev: excellent, thanks!
15:31:23 <xuhanp> I used to own the ARP part of it. But I am still struggling with how to send Neighbor advertisement.
15:32:17 <HenryG> (And then there is baoli's spec for big picture)
15:32:21 <sc68cal> xuhanp: Agreed. We need a way to send ND packets, to mimic what ARP does on v4 side
15:32:56 <sc68cal> I think the more arp stuff that gets utilized on v4 side the deeper the hole gets on the v6 side
15:33:30 <xuhanp> I can get rid of using library like ryu now. But I need to write a python script which can be called in namespace.
15:33:40 <sc68cal> xuhanp: I'll try and sync with you on a more china friendly time to help with that
15:34:01 <xuhanp> sc68cal, that will be great. Thanks!
15:34:27 <sc68cal> #action sc68cal sync with xuhanp about ND packet sending from a namespace
15:34:36 <SridharG> I would like to get some feedback for the following patch - https://review.openstack.org/#/c/136733/3/neutron/db/l3_db.py
15:34:43 <HenryG> Would also like to discuss bug https://launchpad.net/bugs/1393527
15:34:44 <uvirtbot> Launchpad bug 1393527 in neutron "IPv6 Subnets configured to use external router should not be allowed to associate to Neutron Router." [Undecided,In progress]
15:35:12 <sc68cal> SridharG: I'll comment on that review
15:35:25 <SridharG> sc68cal: thanks :-)
15:35:35 <sc68cal> basically with the ipv6 address attrs unset, we go back to the way Neutron behaved before we introduced
15:35:42 <sc68cal> which may or may not be broken in some plugins :)
15:36:07 <HenryG> Yes, the question is do we want to allow such a subnet on a neutron router?
15:36:38 <sc68cal> HenryG: hard question....
15:36:57 <sc68cal> my first though is probably not
15:37:04 <HenryG> mine too
15:37:15 <sc68cal> ah!
15:37:32 <HenryG> Hopefully its only tempest that is attempting that, not any real user
15:37:37 <sc68cal> We can throw an error, if ipv6_ra_mode is not set and they try to associate a router?
15:38:02 <sc68cal> hmmmm - no that'd introduce new behavior when the v6 attrs are not set :(
15:38:08 <SridharG> HenryG: sc68cal: I have seen failures in some of the Neutron unit tests and in tempest aswell.
15:38:35 <HenryG> sc68cal: I understand
15:38:59 <HenryG> but still, maybe we should fix things that are broken?
15:39:43 <HenryG> Anyway, let's discuss in the review
15:39:51 <sc68cal> HenryG: agreed
15:39:56 <SridharG> Sure HenryG..
15:40:12 <raorn> i also have somewhat related bug https://bugs.launchpad.net/neutron/+bug/1372882
15:40:14 <uvirtbot> Launchpad bug 1372882 in neutron "Neutron should drop certain outbound ICMPv6 packets" [Undecided,Incomplete]
15:41:48 <sc68cal> So - regarding that bug
15:41:56 <sc68cal> we allow it out of the vm
15:42:12 <sc68cal> but if I remember correctly we block it when the RA packet goes into other vm interfaces
15:42:19 <raorn> we allow anything aout of vm
15:42:33 <sc68cal> xuhanp did the patch that blocks any RA that isn't from the gateway IP
15:42:43 <sc68cal> if I remember correctly
15:42:51 <raorn> yes, but it can be "provider" network, that have non-virtual hosts
15:44:20 <sc68cal> right - and you'd put the LLA of the non-virtual router in the subnet's gateway IP
15:44:28 <sc68cal> to allow RA's through
15:44:46 <sc68cal> trying to find the bug that ian wells reported back during icehouse dev cycle
15:45:10 <raorn> but i don't want a vm to affect metal host
15:45:18 <raorn> in the same network
15:45:50 <raorn> sc68cal: i know what are you talking about, but it protects only vms
15:45:59 <sc68cal> raorn: ahhh, now I see what you're talking about. Yes, good point
15:46:10 <sc68cal> can you update the bug with that?
15:46:20 <raorn> yes
15:48:25 <raorn> done
15:48:46 <sc68cal> raorn: perfect
15:51:25 <sc68cal> any other bugs, otherwise I'll do open discussion
15:51:44 <sc68cal> #topic open discussion
15:53:17 <Rajeev> review https://review.openstack.org/#/c/136947/ from haleyb is also related to lp https://bugs.launchpad.net/neutron/+bug/1376325
15:53:21 <uvirtbot> Launchpad bug 1376325 in neutron "Cannot enable DVR and IPv6 simultaneously" [Medium,In progress]
15:53:35 <Rajeev> that we briefly talked about earlier
15:54:00 <sc68cal> Rajeev: thanks!
15:54:04 <Rajeev> so if you are reviewing one please take a look at the other too
15:54:28 <Rajeev> sc68cal: welcome
15:54:49 <sc68cal> oh, one more thing I just thought of
15:55:19 <sc68cal> #action sc68cal talk to -infra about an experimental job that uses the "4+6" feature of DevStack to do dual stack, for testing at the gate
15:55:39 <sc68cal> now that has landed
15:56:20 <Rajeev> sc68cal: +1
15:57:47 <sc68cal> If there isn't anything else, I'll give everyone back 3 minutes :)
15:57:53 <Rajeev> xuhhanp: sc68cal: is baoli (Robert) also in China timezone ?
15:58:07 <sc68cal> Rajeev: no I think he's US PST
15:58:15 <baoli> I'm in ET
15:58:18 <HenryG> Rajeev: US EST
15:58:30 <sc68cal> ah, I stand corrected :)
15:58:32 <Rajeev> sc68cal: HenryG: thanks
15:59:04 <sc68cal> One other thing to chew on, in the last couple of minutes, since we mentioned TZ, is the possibility of having a asia/pacific friendly meeting time
15:59:39 <sc68cal> basically have two chairs for the subteam, one for US/Euro and one for Asia/Pacific
16:00:16 <sc68cal> anyway, thanks everyone!
16:00:31 <sc68cal> see everyone next week!
16:00:33 <sc68cal> #endmeeting