15:05:45 #startmeeting neutron_ipv6 15:05:46 hi 15:05:46 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:50 The meeting name has been set to 'neutron_ipv6' 15:05:53 hi 15:06:03 * sc68cal is having some odd computer problems - trackpad is broken 15:07:16 My agenda is pretty light again, mostly because this is the last week for things to be merged 15:08:13 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 also my trackpad appears to be broken, so I'll add some people to the chair to help facilitate 15:08:51 #chair aveiga haleyb 15:08:52 Current chairs: aveiga haleyb sc68cal 15:09:12 great :) 15:09:57 In case people haven't noticed, Kyle is starting to -2 things, so get your +2's lined-up 15:10:34 ipv6 PD seems one of the victims so far, but there is always FFE 15:11:40 I'm hoping that PD can get an FFE 15:13:14 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 haleyb: thanks for all the reviews! Will address the new ones shortly 15:14:14 you had a question about adding the RA? 15:14:55 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 haleyb: great thanks! I will update the commit message though 15:15:29 what about your and Xian’s comments about the link-local check for the gateway? 15:15:49 will it "play well" with PD? For example, if we enable a bunch of options will they cause each other problems? 15:16:23 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 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 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 haleyb: it won't affect PD 15:18:10 baoli: thanks, i haven't ever tried all the ipv6 changes together 15:18:47 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 haleyb, so basically for IPv6, an explicitly configured v6 subnet (as v4) on the gw port is rarely needed 15:19:59 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 baoli: yes, regarding prefix on gw port 15:20:59 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 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 baoli: right. but you can't just enable RA, which seems like you should 15:22:39 haleyb: can you clarify? 15:24:02 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 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 and like I do in code, if ipv6_gateway is not set, it means RA is enabled 15:25:44 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 ah ok 15:25:56 gotcha 15:26:10 i was reading the code more than that big comment :) 15:26:23 hehe ok 15:26:39 thanks again for all the insights! I will put a new version real soon 15:26:56 and we’re good otherwise on the RA and the LLA check comments yes? 15:27:00 i will but a comment in the ini file, but i think you know what i mean now 15:27:13 haleyb: sure thing 15:27:38 but yes I know what you mean now :) 15:28:14 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 i'm not saying to change it since it won't work as things are now 15:29:02 no need to ship something that can be configured broken 15:29:14 ok.. I agree :) 15:30:40 I will make sure the comment again is updated to spcify that it needs to be an LLA (for right now) 15:30:55 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 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 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 sc68cal: We had origianlly wanted something along the lines of a 'pd_enabled' flag in the subnet-create api 15:33:29 Right- but that's the core API, I'm thinking an API extension 15:33:36 which should avoid the concerns they probably raised 15:35:52 sc68cal: any suggestion on how the API extension would look like? 15:37:08 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 POST /prefixes/delegate 15:38:07 sc68cal, but how does this prefix is associates with a neutorn subnet 15:38:44 Most likely the prefix object just contains like two fields, of which one is the subnet_id 15:39:36 sc68cal: then how the subnet api gets changed so that it doesn't require a CIDR any more 15:40:27 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 until you get the prefix from upstream 15:40:45 like you do currently 15:42:26 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 "Why isn't there an API where I just request a PD and neutron does this stuff for me?" 15:43:06 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 baoli: That is a good summary 15:46:10 anyway, sorry to hijack the discussion, please feel free to ignorem e 15:56:39 are we done? :) 15:57:52 Guess so 15:57:59 sorry I killed it :( 15:58:57 ok everyone, until next week! 15:59:00 #endmeeting