14:02:31 <sc68cal> #startmeeting neutron_ipv6
14:02:32 <openstack> Meeting started Tue Mar 18 14:02:31 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:35 <openstack> The meeting name has been set to 'neutron_ipv6'
14:02:38 <baoli> hi
14:03:06 <sc68cal> So - we have some good news
14:03:19 <sc68cal> the subnet attributes patch was merged yesterday
14:03:21 <shshang> What's it?
14:03:26 <shshang> Oh, cool!
14:03:33 <sc68cal> and part of dzyu's patch for EUI64 addresses
14:03:41 <shshang> That's excellent! Congrats, sc68cal!
14:03:44 <sc68cal> we had to split it though
14:03:49 <sc68cal> so we added the utility library
14:04:08 <sc68cal> but we did not patch db_base_plugin_v2
14:04:26 <sc68cal> Here's the bad news
14:04:33 <sc68cal> shshang's patch did not land
14:04:47 <sc68cal> there are concerns about networks with multiple v6 subnets
14:04:56 <shshang> that's fine. :)
14:05:19 <sc68cal> Basically if you have 2 v6 subnets with slaac
14:05:20 <shshang> that's means, I can take my time and no need to rush now
14:05:29 <sc68cal> no idea which prefix is going to be used
14:06:09 <sc68cal> Now the good news is that since the attributes patch landed - no more rebasing to chase the HEAD alembic script
14:06:23 <shshang> Yup, that is true. :D
14:06:26 <baoli> well, I patched in the change, and tried it myself. the VM will get both prefixes.
14:06:26 <sc68cal> which was like 90% of the churn
14:06:46 <SridharG> sc68cal: Did the client (python-neutronclient) side changes also got merged?
14:06:54 <xuhanp> not yet
14:06:57 <sc68cal> SridharG: good question
14:07:04 <xuhanp> I got one -1 about unit test
14:07:09 <xuhanp> I just restored it today
14:07:48 <sc68cal> The other possible piece is that for Icehouse
14:07:59 <sc68cal> we may patch it so that the v6 attributes are not returned to API requests
14:08:11 <sc68cal> since there is nothing behind the API - since the dnsmasq changes did not land
14:08:33 <sc68cal> but once J opens - they'll undo the disable
14:08:50 <sc68cal> so we'd be able to continue our work
14:09:21 <sc68cal> Otherwise - I think we did a great job given the circumstances
14:09:34 <sc68cal> Everyone - pat yourselves on the back
14:10:08 <xuhanp> sc68cal, do we still have time for my security group patch to get merged?
14:10:32 <sc68cal> xuhanp: since that is a bug - it is possible
14:10:45 <xuhanp> I have one small problem with the unit test due to recent code change.
14:10:59 <xuhanp> sc68cal, good to know
14:12:01 <sc68cal> #topic blueprints
14:12:24 <sc68cal> #link https://blueprints.launchpad.net/neutron?searchtext=ipv6 Ipv6 Blueprints
14:13:34 <sc68cal> Since we're moving towards RCs - make sure you've got your BPs all set
14:14:16 <sc68cal> baoli: did we ever register a bp for prefix delegation?
14:14:29 <baoli> sc68cal, I did
14:14:29 <sc68cal> oh there it is
14:14:38 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-prefix-delegation Prefix Delegation
14:14:53 <sc68cal> perfect
14:15:18 <sc68cal> if there isn't anything else, we'll continue on
14:15:54 <sc68cal> #topic bugs
14:16:05 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 IPv6 tagged bugs
14:16:09 <shshang> so if I understand you correctly, we won't be able to make the change to the code until Juno, is that correct?
14:16:33 <absubram> sc68cal: Sean - congrats on getting the neutron side of the new IPv6 attributes getting merged last night
14:16:54 <sc68cal> shshang: Yes - so usually that's the week after the summit
14:16:56 <absubram> unfortunately in the Horizon community, we decided to move the Horizon BP out to Juno
14:17:19 <shshang> OK, good to know. Thank you
14:17:19 <absubram> it should go in very early in J hopefully
14:17:21 <sc68cal> absubram: that's fine - since the attributes don't do anything currently
14:17:59 <sc68cal> Any other bugs to discuss?
14:18:42 <sc68cal> #topic reviews
14:19:15 <sc68cal> So - I don't know if there is anything to report besides what we spoke about in the beginning
14:19:38 <sc68cal> otherwise I'll turn us over to open discussion
14:19:56 <xuhanp> sc68cal, I hope more people can help review my security group bug patch if that's possible :-)
14:20:10 <xuhanp> I kind of changed the design from the beginning
14:20:23 <sc68cal> careful what you wish for :)
14:20:43 <xuhanp> :-)
14:21:19 <sc68cal> But yes - we should review it since there's a chance of it getting merged for icehouse
14:21:44 <sc68cal> anything else before we go to open discussion>
14:21:50 <shshang> Other than that, we can celebrate, right? :)
14:22:35 <sc68cal> I got my celebrating in yesterday - st. patrick's day and getting ipv6 stuff merged
14:22:55 <sc68cal> :)
14:23:06 <shshang> Go GREEN! :D
14:23:22 <sc68cal> But yes - everyone should be proud of the work we've done
14:23:51 <sc68cal> We built a team and made Ipv6 a priority for Neutron
14:24:08 <sc68cal> we put it on the map, and it's only going to get better from here
14:24:16 <shshang> Yup
14:24:19 <xuhanp> sc68cal, good to have you as the lead!
14:24:46 <sc68cal> Haha - well I don't think of it quite that way - I just start the meetings and end them
14:25:26 <sc68cal> We had some great work that was floating around in private forks and we just pulled them out into the public
14:25:58 <sc68cal> #topic open discussion
14:25:59 <SridharG> sc68cal: can you please share the link for the security group bug patch.
14:26:04 <sc68cal> SridharG: sure.
14:26:16 <sc68cal> https://review.openstack.org/#/c/72252/
14:26:26 <SridharG> sc68cal: thanks
14:27:14 <sc68cal> xuhanp: One thing that comes to mind
14:27:31 <sc68cal> your TODO about finding the GUA for a router - if it's put in the subnet's gateway field
14:28:04 <sc68cal> baoli: is GUA for a gateway unusual?
14:28:44 <baoli> sc68cal, not sure.
14:28:53 <xuhanp> sc68cal, you mean my TODO in my patch?
14:28:55 <sc68cal> I know we've probably talked about this a couple times - where we were thinking if the admin sets it that way- we just trust that they know what they're doing
14:28:58 <sc68cal> xuhanp: yes
14:29:48 <baoli> sc68cal, I think that we are talking about LLA here.
14:30:40 <sc68cal> the TODO on line 274 of xuhanp 's patch
14:30:54 <xuhanp> with my security group patch. Only LLA can be used when ra mode is off
14:31:13 <xuhanp> I think this is sc68cal is talking about?
14:31:45 <sc68cal> I think so
14:31:56 <sc68cal> but for Comcast - we'd be setting a gateway IP that is a LLA
14:32:10 <sc68cal> since it'd be a physical device that we know up front
14:32:59 <baoli> sc68cal, that is https://review.openstack.org/#/c/76125/
14:33:29 <sc68cal> right - for routers that neutron creates
14:33:45 <baoli> In that case, we should check if a qr-xxx port is created by neutron when the subnet is added into a router
14:34:12 <baoli> It doesn't seem to make sense to create a neutron port in that case.
14:35:03 <xuhanp> baoli, you are saying we should not allow this subnet be attached to a router?
14:35:08 <shshang> I am confused about which use case you guys refer to....
14:35:19 <shshang> baoli, would u plz elaborate?
14:35:35 <sc68cal> if i'm not mistaken
14:35:42 <baoli> xuhanp, it's a provider net, right?
14:35:47 <xuhanp> yes
14:35:54 <sc68cal> 76125 allows you to create a subnet with a LLA address
14:36:04 <sc68cal> then when you create a router for that subnet, it uses that LLA address
14:36:11 <sc68cal> *attach a router that you've created
14:36:41 <baoli> sc68cal, I think my qeustion is if it's a provider net, and ra is done externally, why would you need a neutron router
14:36:57 <sc68cal> baoli: I don't think 76125 was meant to address that
14:37:07 <sc68cal> remember this patch was in response to the -1 that you did for another review
14:37:12 <sc68cal> where you created a v6 subnet
14:37:15 <sc68cal> then created a router
14:37:29 <sc68cal> with a pre-defined gateway IP that was an LLA address
14:37:52 <sc68cal> and when Neutron tried to set the router's IP to that LLA address that was stored in the subnet's gateway attribute - it blew up
14:38:37 <sc68cal> https://review.openstack.org/#/c/72252/2/neutron/db/securitygroups_rpc_base.py
14:38:42 <baoli> sc68cal, I agree. So you are saying that this subnet with LLA gateway IP still needs to be added in a router?
14:38:43 <sc68cal> line 264
14:39:06 <baoli> sc68cal, I'm not questioning about the change.
14:39:47 <sc68cal> I think all we're trying to fix was this error
14:39:52 <sc68cal> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP address fe80::2001:1 is not a valid IP for the defined subnet.', u'type': u'InvalidInput', u'detail': u''}}
14:40:04 <sc68cal> which happened when you did openstack@devstack-16:~/devstack$ neutron router-interface-add 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub
14:40:20 <sc68cal> but I could be mistaken
14:40:46 <xuhanp> sc68cal, I think baoli's question is do we ever need to do that.
14:41:09 <baoli> xuhanp, yes, that's my question with provider net
14:41:09 <xuhanp> to attach a provider network to the router
14:41:34 <shshang> if it is provider network, then neutron doesn't need to deal with qr- interface any more, right?
14:41:35 <xuhanp> baoli, I don't think neutron limit that provider network should not be attached to a router.
14:41:35 <sc68cal> I don't think this error was related to a provider network and external gateway
14:41:58 <shshang> so what sc68cal described is not applicable for provider network
14:42:09 <sc68cal> this was an error encountered when you were making a neutron router with a predefined gateway
14:42:15 <sc68cal> that was an LLA
14:42:22 <shshang> Yup
14:42:30 <sc68cal> Neutron would try and set the router's IP to an LLA address and the whole thing would blow up
14:43:27 <baoli> sc68cal, yes. Now that the error is fiexed: a user can create a predefined gateway that's not on the subnet, would it make sense to add that subnet into the router any more?
14:43:37 <sc68cal> I don't think it is fixed
14:43:49 <xuhanp> it was supported
14:43:55 <xuhanp> before
14:44:17 <xuhanp> someone wants to change it but Anthoy stopped that.
14:44:28 <xuhanp> If I remember correctly
14:46:15 <baoli> yes, I knew that it was allowed, then the restriction (gateway on the same subnet) was added later
14:48:19 <xuhanp> baoli, yep. with a configuration flag
14:48:29 <shshang> boali, yes, in ipv6 subnet case, it still makes sense to add that subnet to the router
14:49:03 <baoli> shshang, can you explain?
14:49:22 <shshang> I think the use case you mentioned is valid, only for IPv6
14:49:40 <shshang> "a user can create a predefined gateway that's not on the subnet, would it make sense to add that subnet into the router any more?"
14:49:58 <sc68cal> I believe that's the only way that subnet would be able to get traffic out
14:50:07 <sc68cal> if the gateway IP is an LLA address
14:50:11 <shshang> yes
14:50:25 <sc68cal> otherwise the router attach step fails and the subnet has no gateway
14:50:36 <shshang> I remember in IPv6, you can add the GUA as default gateway, and you can also add LLA as default gateway
14:50:53 <shshang> The latter case is the scenario baoli wants to address, right?
14:51:21 <shshang> the former case will pass the check, but the latter case will blow up, because the checkpoint think it is not in the same subnet
14:51:28 <shshang> Is my understanding correct, baoli?
14:51:57 <baoli> shshang, if you create a subnet with a LLA gateway, and then add it to a router.
14:52:13 <baoli> you would end up having two LLAs on the qr-xxx port
14:52:44 <sc68cal> are we sure of that
14:52:44 <shshang> one is predefined, one is auto-calculated, right?
14:52:59 <baoli> shshange, right
14:53:03 <sc68cal> currently it just blows up - no router is created
14:53:23 <sc68cal> so there are no qr-xxx ports
14:53:42 <baoli> Plus, it's against the routing principle to allow a gateway not on the same subnet to forward the subnet's traffic.
14:53:55 <baoli> That's why my question about adding such a subnet into a router.
14:54:12 <sc68cal> but LLAs are not on the same subnet
14:54:26 <sc68cal> in the way Neutron thinks of things being on the same subnet
14:55:35 <sc68cal> am I following this correctly? please let me know if I am mistaken
14:55:37 <baoli> sc68cal, if a gateway with the LLA is external, then it shouldn't be added into a router with the same LLA. But as you said, it's up to the admin to do the right thing. In that case, it would be fine
14:55:48 <shshang> baoli, now I see your point...I am not sure about whether it is legal to have more than 1 LLA. Let me double check
14:55:50 <sc68cal> baoli: The gateway is not external
14:56:06 <baoli> shshang, it's legal
14:56:08 <sc68cal> This is for a subnet that you create - with a predefined LLA address, that you then create a router in neutron
14:56:22 <sc68cal> that will use that LLA address that was set as the subnet's gateway
14:56:29 <sc68cal> which currently fails
14:56:41 <sc68cal> this has nothing to do with an external gateway that is a physical device
14:56:44 <sc68cal> am I correct?
14:57:20 <sc68cal> ok - we need to take this to the mailing list
14:57:39 <sc68cal> we've probably discussed this a couple times and not gotten anywhere - so I will start a thread on the ML
14:57:40 <shshang> baoli, according to Cisco doc,  multiple IPv6 link-local addresses on an interface are not supported
14:57:41 <baoli> sc68cal, if that's the case, the change (or fix), I think, will be different.
14:57:57 <baoli> shshang, cisco is not supporting it
14:58:01 <shshang> yup
14:58:02 <baoli> but others do
14:58:16 <baoli> it doesn't seem to be useful with multiple LLAs
14:58:26 <sc68cal> baoli: I don't agree - I think xuhanp's change fixes
14:59:21 <sc68cal> ok - I'll post on the ML
14:59:25 <sc68cal> thanks everyone
14:59:33 <baoli> sc68cal, we can discuss on the ML
14:59:35 <baoli> thanks
14:59:37 <sc68cal> #endmeeting