15:05:45 <sc68cal> #startmeeting neutron_ipv6
15:05:46 <aveiga> hi
15:05:46 <openstack> Meeting started Tue Mar 17 15:05:45 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:50 <openstack> The meeting name has been set to 'neutron_ipv6'
15:05:53 <dboik_> hi
15:06:03 * sc68cal is having some odd computer problems - trackpad is broken
15:07:16 <sc68cal> My agenda is pretty light again, mostly because this is the last week for things to be merged
15:08:13 <sc68cal> So I'll just open the floor for discussion, for anyone who has questions or concerns about code reviews that are in flight
15:08:41 <sc68cal> also my trackpad appears to be broken, so I'll add some people to the chair to help facilitate
15:08:51 <sc68cal> #chair aveiga haleyb
15:08:52 <openstack> Current chairs: aveiga haleyb sc68cal
15:09:12 <haleyb> great :)
15:09:57 <haleyb> In case people haven't noticed, Kyle is starting to -2 things, so get your +2's lined-up
15:10:34 <haleyb> ipv6 PD seems one of the victims so far, but there is always FFE
15:11:40 <baoli> I'm hoping that PD can get an FFE
15:13:14 <haleyb> yes, it is close.  i think is we want the changes for ipv6-router in we'll have to move fast as well - i did have more comments on those today that can maybe be answered quickly
15:14:04 <absubram> haleyb: thanks for all the reviews! Will address the new ones shortly
15:14:14 <absubram> you had a question about adding the RA?
15:14:55 <haleyb> absubram: i guess after re-reading the blueprint it wasn't clear you were adding RA, but I'm not against it
15:15:14 <absubram> haleyb: great thanks! I will update the commit message though
15:15:29 <absubram> what about your and Xian’s comments about the link-local check for the gateway?
15:15:49 <haleyb> will it "play well" with PD?  For example, if we enable a bunch of options will they cause each other problems?
15:16:23 <baoli> haleyb: https://review.openstack.org/#/c/156283/13/neutron/agent/l3/agent.py. Regarding the comments from you and Xiang Hui: if it's not link-local, then the default route wont' be able to get installed successfully because there won't be route to the prefix.
15:16:55 <baoli> if an explicit prefix is needed on the GW port, one can configure one subnet on the gw port
15:17:02 * sc68cal has a working trackpad again
15:17:07 <haleyb> absubram: well, you can have a non-link-local gateway by the RFCs... but with that comment I see what you mean - the route add will fail with -ENETUNRACH
15:17:40 <baoli> haleyb: it won't affect PD
15:18:10 <haleyb> baoli: thanks, i haven't ever tried all the ipv6 changes together
15:18:47 <baoli> haleyb: on the other hand, if RA is enabled, then the GW port will get an IP address and default route if the upstream router has RA turned on.
15:19:34 <baoli> haleyb, so basically for IPv6, an explicitly configured v6 subnet (as v4) on the gw port is rarely needed
15:19:59 <haleyb> baoli: so in the case of RA, does that need to be a config option?  For example, you don't need ipv6_gateway if you're using RA, correct?
15:20:14 <haleyb> baoli: yes, regarding prefix on gw port
15:20:59 <baoli> haleyb, since this is a router with forwarding turned on, the accept_ra config option has to be 2 in order for RA to be processed by the neutron router
15:21:26 <absubram> haleyb: I think you are correct there.. which is why I assumed that if ipv6_gateway is configured, the user hasn’t enabled RA on the upstream :)
15:21:43 <haleyb> baoli: right.  but you can't just enable RA, which seems like you should
15:22:39 <baoli> haleyb: can you clarify?
15:24:02 <haleyb> Sure, should the config be "learn default route from RA" or "use this value"?  i guess you get that by not setting ipv6_gateway, so maybe the help text just needs clarifying
15:25:05 <absubram> haleyb: yes I think I will clarify the comment for the config.. but yes, if the config is enabled, it means the upstream router doesn’t have RA enabled
15:25:32 <absubram> and like I do in code, if ipv6_gateway is not set, it means RA is enabled
15:25:44 <haleyb> the .ini file text mentions the router must send RAs, but maybe it should also say we will get the info from it
15:25:54 <absubram> ah ok
15:25:56 <absubram> gotcha
15:26:10 <haleyb> i was reading the code more than that big comment :)
15:26:23 <absubram> hehe ok
15:26:39 <absubram> thanks again for all the insights! I will put a new version real soon
15:26:56 <absubram> and we’re good otherwise on the RA and the LLA check comments yes?
15:27:00 <haleyb> i will but a comment in the ini file, but i think you know what i mean now
15:27:13 <absubram> haleyb: sure thing
15:27:38 <absubram> but yes I know what you mean now :)
15:28:14 <haleyb> absubram: yes, i'm fine on the LLA, although i'm sure in the future someone will try and use a global for the router
15:28:44 <haleyb> i'm not saying to change it since it won't work as things are now
15:29:02 <haleyb> no need to ship something that can be configured broken
15:29:14 <absubram> ok.. I agree :)
15:30:40 <absubram> I will make sure the comment again is updated to spcify that it needs to be an LLA (for right now)
15:30:55 <sc68cal> john-davidge_: have a question - may or may not be dumb - but I keep getting hung up on the API workflow for PD - having a user create a subnet of ::/64 seems like a bit too much "magic" and will be hard to explain to users. Do you think we should think about an API extension that does the workflow steps you specify on behalf of the user, so the user facing API hides some of the complexity?
15:31:37 <sc68cal> so the user has an API like "just give me an IPv6 subnet, here's my tenant ID" and then Neutron does the heavy lifting
15:32:28 <john-davidge_> sc68cal: That's what we originally proposed, but the response from many was that a change to the API was best avoided, hence we went with the 'magic' cidr
15:33:15 <john-davidge_> sc68cal: We had origianlly wanted something along the lines of a 'pd_enabled' flag in the subnet-create api
15:33:29 <sc68cal> Right- but that's the core API, I'm thinking an API extension
15:33:36 <sc68cal> which should avoid the concerns they probably raised
15:35:52 <baoli> sc68cal: any suggestion on how  the API extension would look like?
15:37:08 <sc68cal> baoli: Probably really simple. Something where the user just POSTS their tenant ID and credentials, and neutron goes and does the workflow that john-davidge_ documents in his patch
15:37:51 <sc68cal> POST /prefixes/delegate
15:38:07 <baoli> sc68cal, but how does this prefix is associates with a neutorn subnet
15:38:44 <sc68cal> Most likely the prefix object just contains like two fields, of which one is the subnet_id
15:39:36 <baoli> sc68cal: then how the subnet api gets changed so that it doesn't require a CIDR any more
15:40:27 <sc68cal> baoli: You could still do the workaround that john-davidge_ 's patch does, putting in the ::/64 to keep the rest of neutron happy
15:40:42 <sc68cal> until you get the prefix from upstream
15:40:45 <sc68cal> like you do currently
15:42:26 <sc68cal> Just a thought, I just keep thinking the dreaded question someone's going to ask "Why do I create a subnet of ::/64 and set this flag and then later that subnet changes to a different CIDR"?
15:42:58 <sc68cal> "Why isn't there an API where I just request a PD and neutron does this stuff for me?"
15:43:06 <baoli> sc68cal: let's call  it a two api approach, so subnet-create ::/64 says I need to create a subnet but I dont' know its prefix, then the second API (extension) says get the prefix using the PD mechanism.
15:43:46 <sc68cal> baoli: That is a good summary
15:46:10 <sc68cal> anyway, sorry to hijack the discussion, please feel free to ignorem e
15:56:39 <absubram> are we done? :)
15:57:52 <sc68cal> Guess so
15:57:59 <sc68cal> sorry I killed it :(
15:58:57 <sc68cal> ok everyone, until next week!
15:59:00 <sc68cal> #endmeeting