14:00:04 <sc68cal> #startmeeting neutron_ipv6
14:00:04 <openstack> Meeting started Tue Mar  4 14:00:04 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:15 <xuhanp> hello
14:00:26 <sc68cal> xuhanp: hi, how are you?
14:00:39 <xuhanp> sc68cal, I am great. How about you?
14:00:54 <sc68cal> Hoping for spring - tired of snow :)
14:01:05 <baoli> Hi
14:01:07 <xuhanp> :-)
14:01:13 <sc68cal> baoli: good morning
14:01:25 <baoli> sc68cal, good morning to you
14:02:04 <sc68cal> #info Today is the last day for I-3
14:02:31 <xuhanp> yeah. it's kind of sad considering we have so many patches to be reviewed.
14:03:01 <sc68cal> Indeed - at the main meeting, there was a huge amount of blueprints that were targeted to I-3
14:04:01 <sc68cal> At this point, I am just happy that we have a working sub-team, we've got blueprints that everyone is working towards, and some code in review
14:04:27 <sc68cal> There has been discussion of making a feature freeze exception for IPv6 work
14:04:44 <xuhanp> sc68cal, that's great! any luck?
14:04:49 <baoli> that will be a good news
14:05:29 <xuhanp> I just hope more core members can review them. Since we don't have one in our team.
14:05:32 <sc68cal> Yes, so we should make sure that we identify high priority patches for core reviewers
14:05:54 <sc68cal> I think the first two patches are xuhanp's that fixes the RA filtering and allows LLAs for routers
14:06:23 <xuhanp> I kind of hope I can make another patch based on the discussion with baoli and Randy.
14:06:31 <xuhanp> but I am not sure if I can make it by today.
14:06:41 <xuhanp> unit test is killing me
14:06:46 <sc68cal> No rush - I am not going to try and jam this through
14:07:11 <sc68cal> More than likely we'd just be scrambling and end up making more mistakes
14:07:52 <sc68cal> If we can get a FFE - that's fine, but I think it is important for us to get it right the first time, because we won't get another chance to have a clean slate to work on
14:08:15 <sc68cal> So if it slips to J - so be it.
14:08:20 <baoli> xuhanp, thanks for the good discussion and the good work you did
14:08:46 <xuhanp> baoli, no problem. your points make a lot of sense to me.
14:10:12 <sc68cal> I saw that Randy posted a new patchset and blueprint on the ML
14:10:28 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port Allow multiple subnets on gateway port
14:10:59 <sc68cal> I'm going to go ahead and add it to the wiki-  before I forget
14:11:30 <sc68cal> If everyone could take a moment and update the wiki - that'd be great.
14:11:44 <sc68cal> #link https://wiki.openstack.org/wiki/Neutron/IPv6 IPv6 wiki
14:12:05 <xuhanp> sc68cal, will do! I actually hope I can ask some questions to Randy but not sure if he will join.
14:12:30 <baoli> will look at Randy's patch and the wiki sometime this week.
14:13:27 <baoli> sc68cal, the wiki looks good at first glance
14:14:03 <baoli> I don't seem to have permissions to open the links
14:14:07 <sc68cal> yeah, I believe that Anthony and others did work on it recently
14:14:28 <xuhanp> I actually have a question about the external network RA if we can discuss it here.
14:14:41 <sc68cal> sure
14:15:06 <xuhanp> I am now quite clear about the from openstack dnsmasq and the RA from existing provider network gateway.
14:15:21 <xuhanp> but I am confused about RA from external network on the router.
14:15:23 <rtuttle1015> @xuhan... let's discuss
14:15:56 <rtuttle1015> we really want RA from external SP router for learning default route. I'm not convinced we want to use it for SLAAC
14:16:22 <rtuttle1015> I'm open for suggestions on that topic
14:16:46 <xuhanp> so what if qg-xxxx device sends RA or another device on external network sends RA?
14:17:41 <baoli> RA cannot be forwarded, right?
14:17:46 <xuhanp> qr and qg are on the same switch, so qr will get the RA, right?
14:18:00 <baoli> xuhanp, I don't think so
14:18:00 <rtuttle1015> that's a good point. we might want security to prevent untrusted RAs
14:18:17 <rtuttle1015> we set qr to ignore RA
14:18:45 <rtuttle1015> or more specifically, we don't learn default route from RA on qr- interface
14:18:50 <xuhanp> yeah. I am not sure what rules are there for network node.
14:18:58 <rtuttle1015> yes... it is coded that way (new code)
14:19:33 <rtuttle1015> in Shixiong's code, when internal network is added, we set learning default route from RA off
14:19:56 <rtuttle1015> so default route is only learned from SP on external network
14:20:08 <rtuttle1015> this is the intent
14:20:28 <xuhanp> rtuttle1015, what is SP ?
14:20:42 <rtuttle1015> sorry... Service Provider
14:20:45 <baoli> rtuttle1015, my question is that should a router forward a RA received on one link to other links on the same router?
14:21:07 <rtuttle1015> not sure.... for now, I don't think so
14:21:34 <baoli> that's right. So a RA received from qgxxx can't be forwarded to qrxxx links
14:21:45 <haleyb> baoli: RAs are not forwarded by routers
14:21:50 <rtuttle1015> agreed!!
14:22:05 <haleyb> RAs are generated by routers
14:22:19 <baoli> we talked about prefix delegation in the SP case
14:24:30 <rtuttle1015> @baoli: so you mean get RA from SP router with prefix, and use that for tenant networks, correct?
14:25:00 <sc68cal> +1 - PD for tenant networks would be great
14:25:01 <rtuttle1015> so we'd need to integrate with the dnsmasq efforts for defining internal networks
14:25:10 <baoli> rtutlle1015, yes. the router can delegate prefixes from SP.
14:25:15 <rtuttle1015> yes
14:25:34 <rtuttle1015> so we're talking post-I3, right
14:25:41 <sc68cal> defintely
14:25:44 <rtuttle1015> :D
14:26:28 <rtuttle1015> so do we need a new BP for this??
14:26:37 <rtuttle1015> ...or a series of them
14:26:58 <sc68cal> probably a series
14:27:04 <xuhanp> +1 for new blueprints
14:27:08 <sc68cal> but let's just crawl before we start doing marathons :)
14:27:24 <rtuttle1015> yup
14:27:35 <sc68cal> We'll also have to tinker with the API again
14:27:41 <baoli> rtuttle1015: a few weeks back, I asked If I should create one
14:27:52 <sc68cal> since you currently have to specify a CIDR for a subnet, but for PD, you'd be *requesting* a subnet
14:27:59 <rtuttle1015> I think one at least for a placeholder
14:28:12 <rtuttle1015> yes
14:28:21 <baoli> rtuttle1015, I will create one after the meeting
14:28:35 <rtuttle1015> kewl B-)
14:29:26 <rtuttle1015> so we'd need to be able to specify how large a slice to take from PD when specifying an internal net, no?
14:29:47 <rtuttle1015> of course, we'd need checks for overlaps, etc.
14:30:12 <sc68cal> Probably lots we'd have to hash out
14:30:40 <baoli> for sure.
14:31:17 <xuhanp> so let me double confirm here. For my security group RA patch for icehouse (if we can make it), I only allow RA from qr-xxxx LLA address or subnet's gateway IP (which should also be LLA), right?
14:31:31 <sc68cal> xuhanp: sounds correct to me - baoli?
14:31:39 <xuhanp> this is from compute node perspective.
14:32:13 <xuhanp> for now I plan to just use gateway IP from subnet. and we can figure out how to pass the LLA of gateway later.
14:32:20 <baoli> the qr-xxx LLA is the subnet's gateway IP
14:32:22 <xuhanp> may need a new API for that.
14:33:00 <xuhanp> this only when qr-xxxx is created.
14:33:18 <rtuttle1015> can u not just calculate LLA via EIU64 (the same way it's done in the agent)?
14:33:22 <xuhanp> there is case this port is not created and the existing gateway is used.
14:33:43 <baoli> When a subnet is added to a router, the qr-xxx interface will be created
14:33:57 <xuhanp> baoli, yes.
14:34:06 <sc68cal> I'm sure we can scrape out the LLA from the qr-xxx post-creation and set it as the subnet's gateway
14:34:34 <xuhanp> sc68cal, we actually only need the LLA for the security group, right?
14:34:44 <baoli> sc68cal, that's right
14:34:46 <sc68cal> xuhanp: I believe so
14:34:47 <xuhanp> so I can just do that calculation in my security group code.
14:34:55 <haleyb> xuhanp: have you figured out if the icmp type can be specified already?  (based on sean's email)  i'm wondering if iptables will do the right thing, haven't verified that in devstack myself
14:34:56 <xuhanp> using dazhao's code.
14:35:04 <sc68cal> xuhanp: good point
14:35:22 <baoli> xuhanp, you can either calculate it or get it from ip link
14:35:33 <xuhanp> baoli, that's right.
14:35:59 <xuhanp> haleyb, I haven't checked that yet.
14:36:01 <xuhanp> will do soon.
14:36:13 <sc68cal> I *think* that the code that creates the subnet's gateway attribute will occur before the security group code we're patching
14:36:24 <sc68cal> but if not, we can calculate it
14:36:42 <sc68cal> ideally you'd create the subnet, create the neutron router, *then* start launching instances
14:37:12 <xuhanp> sc68cal, great point. I haven't think about this yet.
14:37:27 <sc68cal> and xuhanp's patch happens at the last step, so as long as we're sticking the LLA as the subnet's gateway when we create the neutron router we should be OK
14:37:46 <baoli> xuhanp, do you plan to save the LLA in openstack or get it whenever it's needed?
14:38:22 <xuhanp> that's my new blueprint is about but I haven't figure out the details yet.
14:38:39 <sc68cal> I vote for saving it, since we can return it in API calls instead of continually computing
14:38:48 <sc68cal> when someone does a GET on their subnet, etc.
14:39:18 <sc68cal> I'm not sure how we handle that BP for making GUA's for routers though - that may be tricky
14:40:07 <baoli> sc68cal, the qr-xxx port can still get an address from the subnet without any change, right?
14:41:02 <sc68cal> I don't know for certain, I think it's a case of the qr-xxx port having a GUA addr on the subnet, but we'd only be putting the LLA back into Neutron's DB
14:41:17 <sc68cal> ah no that's wrong
14:41:22 <sc68cal> because the gateway still has ports
14:41:23 <xuhanp> sc68cal, what if the instance is launching before the router is created?
14:41:34 <sc68cal> and the ports would have the addrs on the subnet
14:41:47 <sc68cal> xuhanp: Probably the same thing that happens today - no networking
14:41:57 <sc68cal> or at least no routing
14:42:11 <xuhanp> but we can still get the IP of qr-xxxx although it's not created?
14:42:35 <xuhanp> if not. we won't have the rule for that IP.
14:42:59 <sc68cal> no, we won't know the mac addr of a non-existent device
14:43:04 <sc68cal> but that's OK
14:43:20 <sc68cal> if you launch an instance on a net with no neutron router- you're either doing upstream gateway
14:43:25 <sc68cal> or I don't know what you're doing
14:43:41 <xuhanp> so we expect user to add that rule later when router is created?
14:44:15 <sc68cal> we expect a user to have the gateway already set up
14:44:23 <sc68cal> be it an external gateway, or a neutron router
14:44:48 <sc68cal> so that when the security group rules are being set up for an instance, it can just pull the gateway IP and add a rule to allow RAs in
14:45:18 <sc68cal> baoli: check my assumptions
14:46:11 <baoli> sc68cal, yea, the admin can add SG rules whenever it's needed.
14:47:31 <sc68cal> I think we've got this pretty much licked, with the two patches that you've created xuhanp
14:47:47 <xuhanp> yep. hope so
14:48:07 <sc68cal> we've got a +2 from mark mcclain on the allow LLAs as router interface of v6 subnet
14:48:20 <sc68cal> so, we're looking pretty good :)
14:49:18 <baoli> we are talking about openstack router, I think. So is it possible for the admin to add the router after VMs got launched, or to replace/reconfigure the router, etc.
14:49:39 <xuhanp> that's my previous question, baoli :-)
14:50:07 <baoli> If it's possible, then it has to be taken care of, I guess
14:50:19 <xuhanp> that order will make our security group rule missing
14:50:33 <sc68cal> We can see if there's a way to refresh the security groups and get xuhanp's code path to fire again
14:51:01 <xuhanp> yeah. I can do some check on that.
14:51:04 <baoli> right
14:51:23 <xuhanp> for example, every time the router is created or updated, fire that code again.
14:51:33 <xuhanp> may need to move that to another place.
14:52:17 <sc68cal> We can take a look - but we can always improve it later - my concern is right now we have it a bit too permissive
14:52:54 <sc68cal> I know the RPC for security groups has a way to tell the driver to refresh
14:53:41 <xuhanp> sc68cal, maybe after my patches get merged, then open another bug to track this.
14:53:41 <baoli> We also need to consider the combination of SG rule and the rule that xuhanp's patch will add, I think.
14:53:56 <sc68cal> xuhanp: +1 for another bug to track
14:54:22 <sc68cal> baoli: +1 - although I *think* if they add another rule to allow in RAs, that .... might? win
14:54:43 <sc68cal> have to grab my magnifying glass and read the iptables rules that it creates again.
14:55:15 <sc68cal> since the iptables rules it creates are RETURNs, based on the matching criteria
14:55:25 <sc68cal> the last rule is a DROP
14:55:34 <sc68cal> inside an security group chain
14:55:56 <sc68cal> so if they add a sec group rule to permit RAs from somewhere else in, a new rule is added to the chain that does a RETURN for that address
14:56:19 <sc68cal> before the DROP statement, if I remember correctly
14:56:31 <sc68cal> so I think we're OK
14:56:41 <baoli> So you could create multiple ICMPv6 RA rules in the same time, and the last one in the chain will win?
14:57:31 <haleyb> i'm more worried about the syntax used when adding that rule, since if it's not in iptables-save format things don't always work right on updates
14:57:33 <sc68cal> whichever one matches the packet will win, make it RETURN from the sec-group chain, into another chain that allows it through
14:57:49 <haleyb> baoli: the last one DROPs, so anything before it "wins"
14:58:11 <baoli> sc68cal, haleyb, cool.
14:58:19 <sc68cal> haleyb: is that the "protocol icmpv6" syntax for iptables?
14:58:28 <sc68cal> vs whatever it is currently?
14:58:34 <haleyb> i'd be happy to look at iptables-save before/after output
14:59:12 <xuhanp> haleyb, I think it's the --icmp-type you are talking about?
14:59:20 <xuhanp> --icmpv6-type
14:59:25 <sc68cal> well, looks like we're out of time
14:59:32 <haleyb> sc68cal: i don't remember offhand, i'm more thinking of the filters we add today for types, yes, that thing
14:59:59 <sc68cal> Let's get a blueprint or bug for handling router updates for our sg fix, and a bug for the icmp-type for iptables-save
15:00:01 <baoli> It would be ideal to have consistent icmpv6 RA rules in the chain.
15:00:22 <sc68cal> then let's add it to the wiki so we don't lose track of them
15:00:30 <baoli> agreed
15:00:31 <sc68cal> thanks everyone!
15:00:36 <sc68cal> #endmeeting