15:00:15 <sc68cal> #startmeeting neutron_ipv6
15:00:15 <openstack> Meeting started Tue Nov 18 15:00:15 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:10 <xuhanp> hi
15:01:19 <HenryG> o/
15:01:22 <BrianB__> hi
15:01:35 <baoli> Hi
15:01:36 <dane_leblanc> O/
15:01:54 <raorn> greetings everyone
15:03:04 <sc68cal> dane_leblanc: I saw markmcclain -1'd your spec - let's try and talk with him at some point and figure a way forward for your spec (https://review.openstack.org/98217)
15:03:38 <dane_leblanc> sc68cal: He had 2 comments, one saying that one change should be made as a separate bug
15:04:06 <dane_leblanc> 2nd comment was that API changes would depend on the upcoming API splits
15:04:08 <markmcclain> sc68cal: they were mostly procedural items
15:04:29 <markmcclain> overall we need the work
15:04:57 <HenryG> The separate bug issue is legitimate and easy to fix
15:05:18 <raorn> i also have spec that needs to be discussed (https://review.openstack.org/129910)
15:06:00 <dane_leblanc> I've created a bug for part of the separation: https://review.openstack.org/#/c/134978/
15:06:29 <HenryG> It's less clear to me how to line up the spec with the upcoming API changes
15:06:53 <sc68cal> we also need to consider https://review.openstack.org/#/c/131145/
15:07:07 <sc68cal> we will be returning errors when someone asks for a FIP for a v6 subnet
15:08:12 <sc68cal> raorn: thanks for the link to your spec, I'll take a look :)
15:09:17 <raorn> sc68cal: there's also related issue - https://review.openstack.org/125061
15:09:23 <sc68cal> HenryG: I agree - I think Kilo is going to be a tricky cycle to get features landed
15:10:12 <sc68cal> raorn: thanks. That is also on my radar. I have a /27 for v4 and a /64 for IPv6 in my lab - this burns me all the time :)
15:11:43 <baoli> sc68cal: RE: https://review.openstack.org/#/c/131145/. Talked to Bradley, new patch should be up soon.
15:13:02 <sc68cal> baoli: thanks - based on our discussions we had in-person at the summit, as well as talking with markmcclain, the consensus seems to be that floating IPs for IPv6 don't have a good use case at this point
15:13:36 <sc68cal> People were using FIPs in v4 as both a way to have public access, and sorta-kina like a VIP for load balancing
15:14:17 <sc68cal> so I think that Bradley's patch is the correct way forward until a compelling usecase comes forward
15:14:35 <baoli> sc68cal: agree
15:15:21 <clarkb> as a consumer of neutron's API I will say that if I have to have two vey different code paths in my tools to support ipv4 and ipv6 chances are good I will not use ipv6
15:16:07 <HenryG> clarkb: The problem is that the API is heavily geared towards the shortcomings of IPv4.
15:16:14 <sc68cal> ^ +10000
15:16:16 <clarkb> sure
15:16:26 <clarkb> but I shouldn't need to rewrite everything
15:16:52 <sc68cal> clarkb: your tooling should get simpler, due to getting a GUA off the bat
15:16:55 <clarkb> if I want an ipv6 floating IP because it makes tooling simple then why not give it to me?
15:16:58 <clarkb> no it won't be simpler
15:17:03 <clarkb> because it will handle 2 cases instead of 1
15:17:36 <clarkb> we already have to do this massive dance with ipv4 floating IPs. Everything fomr setting up networks and routers properly to actually requesting the IP and attaching it
15:17:45 <clarkb> not needing to do that is good (and I think should be an option)
15:17:58 <clarkb> but if it is the only option I need to do a different dance for ipv6 addrs
15:18:10 <clarkb> which complicates existing tools
15:18:37 <sc68cal> Depends on how you are deploying
15:18:46 <sc68cal> our tooling is simple, v4 provider network, dual stacked
15:18:47 <clarkb> well I am stuck with what my public clouds give me
15:18:58 <sc68cal> tenants attach to that net, boom, all done
15:19:17 <clarkb> also supporting ipv6 floating IPs would be a simple way to add ipv6 addresses to existing hosts right?
15:19:25 <sc68cal> No.
15:19:26 <clarkb> anyways, I am just trying to think like a consumer of the api
15:19:27 <sc68cal> NO NAT
15:19:44 <haleyb> and no v4/v6 translation
15:19:53 <sc68cal> ^ yep
15:19:56 <clarkb> thats fine
15:20:15 <clarkb> but I think the other concern still stands, I will not use ipv6 any time soon if I have to rewrite all my tooling
15:20:26 <baoli> clarkb: neutron requires specificatoin of --ip-version when creating a subnet. So if you plan to use IPv6, some change might be inevitable.
15:20:30 <clarkb> clouds are supposed to make this easy for me
15:20:47 <sc68cal> clarkb: and some clouds _have_
15:20:48 <clarkb> baoli: ya I think having switches to existing code paths is ok
15:20:55 <clarkb> baoli: but needing new code paths is not ok
15:20:56 <sc68cal> like the internal cloud that I happen to be associated with
15:21:38 <baoli> clarkb, ok, I think I understand your concern.
15:21:48 <sc68cal> in the future, hopefully we can do v6 only on a net
15:22:03 <sc68cal> so if you want v6, you create a port on that net, and leave this v4 business as it currently stands
15:22:44 <raorn> actually, we have success with ipv6-only nets
15:22:45 <sc68cal> sorry, it's not going to be seamless, since as HenryG pointed out, v4 was baked into the openstack API from day one
15:23:17 <clarkb> so I think the problem with that attitude is clouds exist to make this stuff easier for the consumer of the apis
15:23:31 <clarkb> if that means that we have to deal with a little more complexity in the cloud that is a valuable trade off
15:23:57 <dane_leblanc> If we did consider supporting floating IP for v6, it might require some retooling anyway if the subnet being used is SLAAC
15:24:44 <clarkb> as it stands I already have to special case far too many things that the clouds should just handle for me :)
15:25:18 <haleyb> clarkb: we have FIPv4 today since you can't reach that VM without it, with IPv6 (and a global address) you don't need FIP, so it's one less step, right?
15:25:41 <clarkb> haleyb: its one less step but its a different code path...
15:25:47 <clarkb> I like that simpler is an option
15:25:52 <clarkb> I really think simpler should be supported
15:26:06 <clarkb> but I also think that we shouldn't break a bunch of existing code
15:26:19 <sc68cal> what existing code exists for openstack for v6
15:26:23 <sc68cal> that we would break
15:26:25 <sc68cal> there is none
15:27:02 <haleyb> let's get rid of all the ipv4 crutches people use today so they can run :)
15:27:32 <raorn> yeah!
15:27:45 <sc68cal> haleyb: preach it :)
15:28:00 <haleyb> i've been trying for ~20 years, hasn't worked yet
15:28:15 * sc68cal starts handing out the kool-aid
15:28:39 <haleyb> maybe we need ipv4 patches, like the nicotine ones?
15:29:00 <haleyb> we digress....
15:29:12 <sc68cal> clarkb: I do think that tooling is a valid concern, maybe we can start a thread on the ML to figure out a way forward?
15:29:14 <clarkb> I am just trying to provide an api consumer view point
15:29:35 <clarkb> keep in mind people have to use the api
15:29:39 <baoli> I think that from the consumer's point of view, the API semantics should be consistent regardless the ip family. I think that's our goal as well. But we may not be able to achieve that 100 percent.
15:29:43 <clarkb> and having tried to use it I think we forget that a lot
15:29:54 <clarkb> baoli: ++
15:30:01 <raorn> clarkb: i have non fip-related question for you, as an api consumer
15:30:10 <HenryG> I agree with baoli
15:30:23 <sc68cal> baoli: agree
15:30:36 <HenryG> I think we can get pretty close to 100% if we ignore some calls with a warning.
15:30:57 <HenryG> Like FIP :)
15:31:00 <sc68cal> HenryG: probably better to just throw an error
15:31:34 <HenryG> sc68cal: I mean like "you asked for a FIP but you already have one"
15:31:39 <haleyb> but v6 will be different since with prefix delegation there will be something like 'neutron subnet-allocate...'
15:32:18 <haleyb> i think carl pushed out his IPAM spec with something like that in it
15:32:23 <HenryG> haleyb: that's for tenants who know what prefixes are and what they want to do with them
15:32:33 <baoli> haleyb, that will be a new API
15:32:53 <sc68cal> haleyb: yeah we're working closely with Carl on IPAM since a lot of his semantics also overlap with IPv6 PD semantics
15:33:03 <sc68cal> hoping to re-use code
15:33:52 <haleyb> yes, just that getting a globally-routable prefix is required to really use v6, so there's extra steps as both admin and tenant
15:34:51 <HenryG> For tenants who just want things to work, the defaults should just work. The admin should be the only one who would need to configure or set up something.
15:36:25 <haleyb> If default is giving a tenant router a global prefix that's fine with me, guess it seems a little optional since i might only want a ULA
15:37:49 <haleyb> i now see how this seemingly little api changes could get painful
15:38:09 <sc68cal> :)
15:38:49 <sc68cal> we'll just have to keep hammering it into shape - right now this all exists in our heads and some pictures on twitter from the whiteboards :)
15:38:56 <HenryG> haleyb: So there is one difference I see in v6. The tenant needs to specify whether their subnet is global or local.
15:39:04 <haleyb> so documentation is a big piece here
15:39:17 <HenryG> ^^ +100
15:39:19 <sc68cal> agree - a huge piece in fact.
15:39:51 <haleyb> HenryG: yes, global or local, one get's assigned (from admin pool), the other could be random or user-specified
15:40:26 <haleyb> Do we need to add an agenda item to the mid-cycle to cover any IPv6 work?
15:41:09 <dane_leblanc> Isn't mid-cycle mostly for tech debt and API splits?
15:41:36 <sc68cal> I think this one is going to be tech dept and splits
15:41:48 <haleyb> yeah, but i see henry and sean (and myself) are going, so I had hopes
15:42:17 <sc68cal> good point - I'm down with an agenda item(s)
15:42:22 <HenryG> haleyb: great, don't forget to add yourself to the wiki
15:42:28 <haleyb> doing it now
15:42:49 <haleyb> too bad there won't be much snow in early Dec
15:44:11 <dane_leblanc> Bring your roller skis
15:44:57 <SridharG> I would like to hear the opinion of the team about the following issue - https://bugs.launchpad.net/neutron/+bug/1393527
15:44:58 <uvirtbot> Launchpad bug 1393527 in neutron "IPv6 Subnets configured to use external router should not be allowed to associate to Neutron Router." [Undecided,New]
15:45:11 <SridharG> The idea is to stop users from associating a SLAAC subnet (configured to use external router) to a Neutron router.
15:45:21 <SridharG> By doing this, we will be giving an early indication to the user instead of making them wonder why the VM is unable to acquire an IP address.
15:45:47 <HenryG> The mid-cycles have really perfected the "nothing much else to do here, let's get to work" locations.
15:46:05 <sc68cal> SridharG: My concern is this would block IPv6 PD
15:47:02 <HenryG> sc68cal: I hadn't thought of that
15:47:17 <SridharG> sc68cal: can you please elaborate..
15:48:13 <sc68cal> It could be that the code that blocks a neutron router to be associated, would have to be un-done when we do IPv6 PD support
15:48:37 <sc68cal> it's close enough to the workflow for PD support that it makes me a bit concerned
15:48:51 <sc68cal> not 1:1, but close enough
15:49:10 <baoli> sc68cal, in that case, it's not an external router anymore for the subnet, right?
15:49:48 <sc68cal> baoli: to be honest, I'm not quite sure - you may be right
15:49:49 <baoli> So if the combination indicates use of external router, then it shouldn't be added in to the neutron router.
15:50:13 <SridharG> baoli: yes, thats my point as well.
15:51:03 <sc68cal> ugh - I forget what external_router means in the API
15:51:20 <sc68cal> external means so many things in neutron :(
15:51:23 <baoli> SridharG, it's just that the user has to be aware of what each combination means
15:51:25 <SridharG> http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact
15:51:42 <HenryG> It seems OK but let's watch out that we don't make things awkward for PD.
15:51:56 <sc68cal> SridharG: OK - you mean with ipv6_ra_mode NOT SET
15:51:59 <sc68cal> ?
15:52:07 <SridharG> sc68cal: yes
15:52:34 <sc68cal> ok now I'm getting closer to being on the same page
15:53:19 <SridharG> sc68cal: cool. So the idea is to return an error at an early stage.
15:53:59 <sc68cal> Got it now - yes that makes sense
15:54:17 <sc68cal> I think I agree with HenryG's thinking. We'll just have to be careful
15:55:02 <SridharG> sc68cal: sure. I'll propose a patch and we can discuss the concerns if any during the review phase. thanks.
15:55:04 <sc68cal> With the last 5 minutes - everyone keep an eye on bugs tagged with ipv6 - https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6&orderby=status&start=0
15:56:31 <baoli> I also want to give folks here a heads up. We are working on an IPv6 + DVR solution here. We have a manual setup for it. We'll share the details soon.
15:57:18 <raorn> i guess my scpec(s) will be discussed on next meeting?
15:57:38 <haleyb> baoli: rajeev and myself have fixes for this we've been working one, one patch is out already
15:57:57 <sc68cal> Would prefer to not have manual setup
15:58:02 <baoli> haleyb, can you share the link?
15:58:17 <sc68cal> raorn: yes, we'll all have to take a look and review
15:58:26 <baoli> sc68cal, the manual setup is a proof of concept.
15:58:53 <raorn> ok
15:59:14 <haleyb> baoli: https://review.openstack.org/134676 but i have another to get out as well
15:59:29 <baoli> haleyb, cool, will take a look at.
15:59:44 <haleyb> our first step is to just get it working, but if you have other thought's i'd like to hear them
16:00:04 <sc68cal> great meeting everyone - good to see everyone at the summit. Until next week!
16:00:09 <sc68cal> #endmeeting