15:05:14 <HenryG> #startmeeting neutron_ipv6
15:05:14 <openstack> Meeting started Tue Jan 20 15:05:14 2015 UTC and is due to finish in 60 minutes.  The chair is HenryG. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:18 <openstack> The meeting name has been set to 'neutron_ipv6'
15:05:20 <ihrachyshka> yeah, let's go
15:05:29 <baoli> HenryG: ok, go ahead
15:05:37 <HenryG> Why can't I find the agenda page?
15:07:13 <baoli> Hmm, the link gets lost
15:07:13 <aveiga> HenryG: I can't find it either. It's no longer in the wiki
15:08:00 <HenryG> OK, I think we just have some bugs/issues to talk about, and maybe multiple prefixes
15:08:25 <HenryG> #topic multiple slaac addresses
15:08:42 <HenryG> #link https://review.openstack.org/147076
15:09:10 <HenryG> Mark left a comment
15:09:23 <HenryG> Any opinions?
15:10:03 <ihrachyshka> I haven't seen that one, will need to look more closely
15:10:11 <HenryG> First question is whether to backport. I think it's fine to NOT backport.
15:10:46 <aveiga> HenryG: +1
15:10:48 <sc68cal> sorry, got a litle held up - thanks HenryG
15:11:07 <aveiga> we provided support for SLAAC as a basic option, but never intended support for advanced IPv6 networks with Juno
15:11:11 <HenryG> Second question is to "treat v4, v6-stateful and v6-stateless" addressing as "co-equals".
15:11:57 <HenryG> My take on that is that v6 is on a different trajectory than v4 here.
15:12:23 <HenryG> In v6 we want multiple prefixes with one address from each prefix.
15:12:35 <ihrachyshka> not to backport, it's change in behaviour.
15:13:15 <HenryG> (v4 is just one address from any of the v4 prefixes = pooling)
15:13:21 <aveiga> HenryG: also agreed on the IPv6 behavior
15:14:04 <baoli> HenryG, v4 can be given multiple addresses as well.
15:14:04 <aveiga> I think the interesting part is going to be how we provide those addresses
15:15:22 <HenryG> baoli: can you be more specific?
15:15:58 <ihrachyshka> HenryG, you may add an alias to your interface, and set a different IP address to it.
15:15:58 <baoli> HenryG, you can assign addresses to the neturon port with port-update
15:16:51 <dane_leblanc> There should be a difference between how we handle/assign V6 stateless vs. V6 stateful
15:17:23 <dane_leblanc> V6 stateless should be automatic/implicit, whereas V6 stateful must be associated explicitly
15:17:24 <sc68cal> ihrachyshka: at least on freebsd, that is a manual process that has to be done inside the guest
15:17:35 <HenryG> ihrachyshka, baoli: OK, but the v4 address is still taken from the pooled-together prefixes, right?
15:17:45 <ihrachyshka> sc68cal, yeah, but who said fixed ip must be backed up by dhcp?
15:18:03 <baoli> HenryG, it can be taken from any of the v4 subnets, Dane can confirm
15:18:21 <ihrachyshka> +
15:18:39 <ihrachyshka> HenryG, what do you mean by 'pooled-together prefixes'?
15:18:42 <sc68cal> ihrachyshka: I don't know if there is a specification for it, but it is at least by convention
15:19:14 <dane_leblanc> There's an assumption in the code currently that a port only has one subnet, since the port dict only has a 'subnet' entry, not a 'subnets' entry
15:19:54 <sc68cal> dane_leblanc: you mean inside the code of the L3 agent, yes?
15:20:16 <dane_leblanc> If a second v4 address is added via port-update, and the address is from a different subnet space, this will probably break things
15:20:18 <baoli> dane_leblanc, talking about regular ports (not router ports, or external gw ports)
15:21:01 <baoli> dane_leblanc, I remember you had one paragraph in your multiple prefix spec on multiple v4 addresses
15:21:06 <dane_leblanc> baoli: right, port['subnet'] might not come into play on internal (non-router) ports
15:22:02 <dane_leblanc> baoli: multi-prefix spec says that V4 handling won't change, we should still allow v4 addresses added via port-update
15:23:17 <dane_leblanc> (I take back the previous "...this will probably break things", the 'subnet' vs. 'subnets' should only effect router ports
15:23:33 <HenryG> So this patch https://review.openstack.org/147076 is just for create_port, as far as I can tell
15:24:30 <HenryG> It does not change any code for update_port, it seems
15:24:32 <baoli> I think it's a bug fix
15:24:37 <dane_leblanc> HenryG: Yes, looks like create_port without fixed_ips being specified
15:25:51 <HenryG> And what it does is create an IP address for each v6 slaac subnet on the network the port is on
15:25:58 <dane_leblanc> So it should pick a single v4, a single v6 stateful, and all v6 stateless, I think
15:26:09 <HenryG> dane_leblanc: exactly
15:27:00 <HenryG> So I think Mark's comment is that v6-stateless is now not "co-equal" with the other two
15:27:25 <baoli> I actually thouthgt that this should be addressed by the mp bp
15:27:26 <dane_leblanc> This is as it should be, since SLAAC is automatic
15:27:31 <aveiga> actually, I need to make this a bit more complicated
15:27:41 <aveiga> why do we only do one v6-stateful address?
15:27:57 <HenryG> aveiga: That is where I was going :)
15:28:18 <aveiga> ah, ok.  I'm doing some work with the Teclo/NFV team, and that's going to come up soon :)
15:28:35 <HenryG> My take is that this bugfix partially-implements the multiple prefix BP
15:28:45 <dane_leblanc> aveiga: For v6-stateful, we could have diverged from V4 handling, and selected all v6 stateful subnets (in addition to all v6 stateless)
15:29:13 <dane_leblanc> But in multi-prefix BP, we chose to stay closer to V4 approach
15:29:43 <dane_leblanc> HenryG: Yes, this partially overlaps with a multi-prefix change that is out for review.
15:29:53 <aveiga> dane_leblanc: are you suggesting that one of the stateful networks is somehow higher weighted than the others? Not nit-picking, as I agree with keeping it close to v4 for user expectations
15:30:06 <aveiga> I just want to make sure it's not off the table for other uses, like orchestrating a VNF
15:30:42 <dane_leblanc> aveiga: Good question, there's no clear weighting, only "first" v6 stateful gets selected.
15:31:13 <dane_leblanc> probably based on which was created first chronologically. Should be same as v4 case.
15:31:24 <aveiga> dane_leblanc: how is first seleceted? This could cause some issues if, say it uses UUID and the network is deleted/recreated for some reason
15:31:52 <ihrachyshka> I would think adding ipv6 address from every subnet would be beneficial at least to avoid router when accessing neighbours (as it turned out, there is no easy way to pass routes for local subnets via dhcpv6)
15:31:53 <aveiga> ok, we can table this bit of a tangent
15:33:42 <HenryG> Yeah, I am somewhat with ihrachyshka here. At least for stateless it seems we don't want to pool subnets.
15:35:13 <HenryG> v4 subnet pooling was done to expand address space. v6 shouldn't need that. <-- HenryG's
15:35:14 * ihrachyshka notes that someone should really point me into 'pool' term definition
15:35:54 <HenryG> ihrachyshka: It just means all subnets together create one pool to pick an address from.
15:36:21 <ihrachyshka> ah, ok, 'considering them as single entity -> choosing only one of addresses', got it
15:36:32 <HenryG> v4 subnet pooling was done to expand address space. v6 shouldn't need that. <-- HenryG's opinion
15:36:40 <ihrachyshka> YES
15:36:44 <sc68cal> ++
15:36:50 <ihrachyshka> it's 2010s outside
15:38:22 <HenryG> So in v6 if you add a subnet it should mean you intend to add another address.
15:38:29 <HenryG> Anyway, let's move on
15:38:32 <dane_leblanc> HenryG: So if I understand what you're saying, v4 pooling (all subnets are treated equal, pick one address) doesn't apply to v6 stateful, since v6 stateful subnets are separate
15:39:03 <ihrachyshka> dane_leblanc, or better, since they are huge
15:39:07 <baoli> HenryG: the port create API also allow specifying a specific subnet.
15:39:31 <HenryG> dane_leblanc: Yes
15:39:35 <ihrachyshka> baoli, we may ignore it. more addresses won't hurt anyone
15:39:40 <HenryG> baoli: interesting
15:40:02 <baoli> So it's not strictly for pooling purpose unless I misunderstood the original intent
15:40:55 <HenryG> baoli: So that must be for the users who want to be specific about which v4 address they get
15:41:08 <baoli> ihrachyshka, I agree if that's what the API is designed for.
15:41:09 <dane_leblanc> baoli: Good point, if fixed_ips list is provided for port-create, user gets to specify explicit subnets to include
15:41:49 <ihrachyshka> dane_leblanc, but user's requests will be fulfilled. with another hundred of addresses :)
15:42:29 <HenryG> For v6 then, we have to decide if specifying a subnet returns just one address, or ignores the subnet provided and just returns addresses from all subnets anyway.
15:43:17 <HenryG> We may have to amend the BP with some details like this. It will affect the API.
15:43:23 <ihrachyshka> we already assign more addresses than requested for stateless case. I don't see why stateful should be different
15:43:32 <dane_leblanc> HenryG: I think it makes sense to "ignore the subnet" and return address for all subnets only for the SLAAC cases
15:43:51 <HenryG> dane_leblanc: That is what I am leaning towards also
15:44:31 <dane_leblanc> ihrachyschka: It's unavoidable for stateless, they're automatic, doesn't matter if you pick them in the API/CLI, you'll get them anyway
15:45:28 <aveiga> dane_leblanc: that is, unless you want to implement filters at the iptables level to block packets from the router port
15:45:31 <ihrachyshka> dane_leblanc, well yes. but I wonder what is drawback in setting more addresses than originally asked for?
15:45:32 <baoli> Like ihrachyshka pointed out earlier, one difference between v4 and v6 in terms of multiple stateful addresses, is that for v4, one can add routes through dhcp so that router doesn't have to be invovled for inter-subnet communication. For v6, dhcpv6 can't be used to inject routes.
15:45:39 <aveiga> but that can be messy
15:46:01 <ihrachyshka> baoli++ and that's pretty significant to avoid networker node
15:46:42 <baoli> ihrachyshka, so the API is kind of ambiguous on subnets.
15:47:00 <aveiga> the other issue with sending all RAs from all subnets is that most systems will just take the first RA they see in terms of routes
15:47:17 <aveiga> so all non-local packets will be sent via the first seen router, regardless of the source address
15:49:51 <HenryG> aveiga: Thanks for that info. Noted, but I don't know what to do about that yet.
15:50:02 <HenryG> Something to keep in mind, for sure.
15:50:25 <aveiga> HenryG: not much we can do about it besides filtering
15:50:52 <aveiga> and only some distributions pay attention to RA weighting
15:50:59 <aveiga> so that's not a silver bullet either
15:51:44 <baoli> RA can carry both default route and prefixes and the default route can be disabled on RAs if the RA is intended for prefixes and auto config only, I think.
15:52:54 <aveiga> baoli: right, but then how do you differentiate?
15:53:09 <aveiga> if I want the route available for some servers but not others, that doesn't work
15:53:21 <aveiga> it is, unfortunately, all or nothign
15:54:14 <baoli> aveiga, that's right. The RA is sent to the LAN
15:54:53 <aveiga> yep, all nodes multicast address
15:55:50 <HenryG> We can't solve all problems in this meeting :)
15:56:17 <ihrachyshka> yeah. :) I want to point out that we still don't set M=1 for stateful RAs: https://review.openstack.org/#/c/148203/
15:56:18 <aveiga> HenryG: yup, I just wanted folks to be aware of the consequences of allowing RAs from all subnets for a port
15:56:58 <ihrachyshka> I would be glad to see it happened in reasonable time so that we can backport it the next month
15:57:03 <HenryG> dane_leblanc: Does it make sense to amend the Multiple Prefix spec to add details about address (non)pooling?
15:57:20 <HenryG> ihrachyshka: sorry
15:57:29 <dane_leblanc> HenryG: I think the details are there, question is whether they're the correct details. :)
15:58:19 <dane_leblanc> HenryG: Specifically for which stateless subnets to include for the 2 cases: fixed_ips included, and fixed_ips not included.
15:58:44 <dane_leblanc> Oops  ^^^ *stateful, not stateless
15:59:29 <HenryG> dane_leblanc: Yes, that's what I meant by amending
16:00:00 <HenryG> OK, back to ihrachyshka
16:00:01 <dane_leblanc> HenryG: If we have consensus, I can change/amend
16:00:29 <jorgem> o/
16:00:40 <aveiga> HenryG: I think time's up
16:00:42 <dane_leblanc> Times up for IPv6
16:01:09 <ihrachyshka> ok, thanks all for the chat
16:01:23 <HenryG> OK, we can talk in the neutron channel
16:01:31 <HenryG> #endmeeting