15:00:41 <sc68cal> #startmeeting neutron_ipv6
15:00:42 <SridharG> hello
15:00:42 <openstack> Meeting started Tue Oct 21 15:00:41 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:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:52 <baoli> Hi
15:00:53 <xuhanp> hello
15:01:09 <dane_leblanc> Hi
15:01:11 <SridharG> hello all
15:02:42 <sc68cal> Now that Juno has been cut, it's time to start filing specs for Kilo
15:03:39 <xuhanp> sc68cal, I filed one spec for extra dhcp options:
15:03:40 <xuhanp> https://review.openstack.org/129118
15:04:04 <sc68cal> xuhanp: perfect
15:04:08 <xuhanp> will be great if team can review it.
15:04:37 <sc68cal> dane_leblanc: have you rebased your spec for Kilo?
15:04:42 <dane_leblanc> There is one for multiple prefixes/addresses: https://review.openstack.org/#/c/98217 has some reviews already
15:04:56 <dane_leblanc> sc68cal: Yes, it is in the new format
15:05:16 <aveiga> dane_leblanc: that looks like it would be a requirement for the floating addr spec I want to file
15:05:33 <dane_leblanc> aveiga: Looking forward to the floating IP spec
15:06:06 <xuhanp> I think we also need to pick up the work on the dual-stack gateway port blueprint back in Havana
15:06:08 <xuhanp> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
15:06:14 <xuhanp> I can help file a spec for that.
15:06:37 <dane_leblanc> xuhanp: I was going to try fixing that with the multi-prefix blueprint
15:06:40 <xuhanp> I checked with Shixiong about if he or Randy going to work on that one in Kilo, haven't heard from him yet.
15:07:09 <xuhanp> dane_leblanc, you mean in one spec?
15:07:39 <dane_leblanc> xuhanp: Yes, one spec.
15:07:48 <xuhanp> dane_leblanc, great to hear that.
15:08:11 <xuhanp> I am also available to help on that. So let me know if you need any help?
15:08:13 <dane_leblanc> xuhanp: Could be separate spec, but it would mean more spec overhead
15:08:42 <dane_leblanc> xuhanp: Thanks, probably will need some help/opinions
15:09:12 <haleyb> And I also saw a review for prefix delegation, https://review.openstack.org/#/c/93054/ - seems as something a provider would want since "bring your own prefix" won't work very well
15:10:35 <xuhanp> dane_leblanc, I am just worried about too much code to submit for one spec. It's fine if you want to hold them in one spec.
15:10:51 <HenryG> haleyb: Yes, IMO ipv6 should autodelegate where possible since that is part of its appeal
15:11:28 <dane_leblanc> xuhanp: Code size doesn't look very large for the multi-addresses on gateway ports
15:11:44 <xuhanp> dane_leblanc, OK. sounds great.
15:11:50 <aveiga> HenryG: actually, I'd expect it to follow Solicit hints
15:11:51 <haleyb> HenryG: yes, even if neutron just manually assigned a prefix when the ipv6 box is checked, like a FIP
15:11:57 <aveiga> instead of auto-delegate
15:12:30 <aveiga> we'd have to work out the allocation algorithm there, because a client may only hint for a /64 where a net was allowed a /48 ...
15:12:31 <HenryG> aveiga: Good point, I agree
15:15:05 <HenryG> aveiga: I was thinking more abstractly, for tenants that don't really care but just want things to work. And operators that want the defaults to "just work".
15:15:20 <aveiga> well, we could work that out in the api
15:15:32 <aveiga> something like "advertise a /64 unless hinted"
15:15:47 <aveiga> based on network attributes
15:16:02 <HenryG> aveiga: exactly, yes
15:18:02 <HenryG> aveiga: So I (or someone) will check with you for the details on the prefix delegation spec.
15:18:28 <haleyb> yes, for "just work" we need a way to fill-in the default ipv6 prefix for a tenant with one that is globally routable.  I'll admit I have some reading to do on the options...
15:18:42 <aveiga> HenryG: heh, I'm no authority, but I'd be glad to part of the conversation :)
15:19:02 <sc68cal> so
15:19:08 <sc68cal> this is super old, but
15:19:09 <sc68cal> https://wiki.openstack.org/wiki/Neutron/IPv6/PrefixDelegation
15:19:23 <sc68cal> aveiga and I whiteboarded it a while ago
15:20:07 <HenryG> sc68cal: Thanks for pointing that out
15:20:14 <sc68cal> Basically I wanted to make it so a user would just do an API request that says "hey give me a prefix" and we'd do the heavy lifting
15:21:02 <aveiga> sc68cal: we need to revisit that, especially the logic around ordering (which objects exist first?) and scheduling logic
15:22:06 <haleyb> +1, for example, having a check box in horizon.  You can put me on the list as someone interested in working on it
15:23:54 <SridharG> We have one old BP in launchpad related to DHCPV6 relay agent - https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-relay-agent
15:24:30 <aveiga> SridharG: so I actually have a question about that
15:24:36 <aveiga> what's the target use case?
15:24:48 <sc68cal> to be honest we have not seen or heard from the drafter for a long time
15:25:11 <aveiga> I think that's for using an external dhcpv6 server
15:25:28 <sc68cal> and also it was accepted prior to the new neutron-specs workflow, so I don't know if we need to worry about it unless someone files a neutron-spec
15:26:01 <SridharG> sc68cal: yes, its an old one.
15:26:36 <aveiga> I'm wondering if it's actually necessary.  You could potentially just run a service VM listening with a relay running
15:26:54 <aveiga> since I'd assume that net would have dhcpv6 set to off...
15:27:37 <HenryG> There is a separate DHCP relay BP. Looking for it ....
15:27:38 <SridharG> aveiga: IMO I think its for an external Centralised DHCPV6 server.
15:27:45 <aveiga> yup
15:28:02 <aveiga> the local impact seems to be acting as a relay for a non-OpenStack dhcvp6
15:28:13 <aveiga> so again, I think that's solved through NFV work instead :)
15:28:28 <aveiga> just run the relay agent as a service VM and be done with it
15:28:41 * sc68cal likes making things NFV's problem
15:28:46 <HenryG> https://blueprints.launchpad.net/neutron/+spec/dhcp-relay
15:30:29 <aveiga> I think this is entering nice to have territory, and not really core feature space
15:30:42 <aveiga> we still have lots of things to work on that Neutron has to handle
15:31:07 <aveiga> and this is something that can be accomplished without requiring Neutron intervention at the moment, so I vote to either backlog it or not bother
15:31:55 <SridharG> aveiga: sure, np.
15:32:38 <haleyb> and since someone asked me the other day, how painful would it be to do privacy extensions/temp addresses?  It's not on the top of my list by any means, but someone will want it by the L release.  Core things are more importatnt now
15:32:49 * haleyb waits for the tomatoes
15:32:49 <aveiga> impossible
15:33:06 <aveiga> we cannot mathematically predict the address (that's the point of PE)
15:33:11 <haleyb> well, you can remove all the port anti-spoof filters
15:33:12 <aveiga> so we can't do anti-spoofing rules
15:33:36 <aveiga> it's in violation of the BIS stating that you shouldn't use PE on servers
15:33:51 <aveiga> I mean, that's one of those things that's a "you're on your own" deal
15:34:02 <sc68cal> yeah we've been pretty consistent throughout the life of this subteam, not really entertaining PE feature requests
15:34:13 <aveiga> it can be done in SLAAC mode, and you have to disable the filters
15:34:18 <haleyb> I know, and that's what I said back, but people will continue to ask
15:34:29 <sc68cal> we'll make a FAQ ;)
15:34:34 <aveiga> but as soon as you start disabling built-in security features, that's where I shake my head
15:34:45 <aveiga> yeah, that can be done up in docs, honestly
15:35:02 <haleyb> i will continue to say it's unsupported
15:35:03 <aveiga> because there's no way to get proper support in
15:35:11 <aveiga> unless we intercept DAD/ND
15:35:22 <haleyb> feel free to move on to more important things...
15:35:27 <aveiga> ok
15:36:39 <xuhanp> One quick notice: I am still waiting for more feedback for sending out Neighbor advertisement message for IPv6
15:36:40 <xuhanp> http://lists.openstack.org/pipermail/openstack-dev/2014-October/048373.html
15:37:04 <xuhanp> last time we were talking about make ryu a dependency is too big
15:38:13 <baoli> xuhanp, can you clarify the use case for the unsolicited NA
15:39:06 <xuhanp> It's for router to advise itself after HA replacement.
15:39:22 <xuhanp> it's documented in one RFC, I may need time to find that for you
15:39:41 <xuhanp> You can also check the email list in Sep
15:40:16 <baoli> xuhanp, ok, I'm trying to think of a case where it's required.
15:40:32 <xuhanp> it's like the function of ARP in HA case
15:41:13 <xuhanp> but I've been spending some time on finding the right solution to send out the unsolicited NA
15:42:55 <SridharG> xuhanp: I hope this is the link you were referring to - http://lists.openstack.org/pipermail/openstack-dev/2014-September/044602.html
15:43:23 <xuhanp> SridharG, that's right. Thanks a lot!
15:43:45 <baoli> SridharG, thanks.
15:44:08 <SridharG> xuhanp: baoli: np, your welcome.
15:47:53 <SridharG> I submitted a patch for the Bug#1382076
15:48:00 <SridharG> https://review.openstack.org/#/c/129865/
15:48:30 <SridharG> I'll be happy to hear the review comments..
15:50:01 <baoli> SridharG, will take a look.
15:50:31 <SridharG> baoli: thanks.
15:53:00 <baoli> xuhanp, I need to look at it in more detail. But would the VRRP protocol (or keepalived which implements it) takes care of sending the NA after failover?
15:53:41 <xuhanp> baoli, exactly, but there are cases HA is not configured. So we should take care those cases like IPv4
15:54:11 <xuhanp> ARP is not sent out when VRRP keepalived is configured
15:55:15 <baoli> xuhanp, ok still confused. In the case of HA not being configured, would radvd do the same?
15:56:04 <xuhanp> radvd only take care of internal router interface. we still need to take care external gateway port when router is failed over to another host
15:58:29 <baoli> xuhanp, so this is to cover the NA to the gateway port (failover or not) on the neutron router.
15:59:20 <sc68cal> looks like we're out of time
15:59:40 <sc68cal> let's take it to the ML and keep the thread alive that xuhanp started
15:59:40 <xuhanp> baoli, maybe talk another time?
15:59:48 <baoli> xuhanp, sure.
15:59:49 <sc68cal> until next week everyone!
15:59:53 <sc68cal> #endmeeting