14:00:14 <sc68cal> #startmeeting neutron_ipv6
14:00:15 <openstack> Meeting started Tue Feb 18 14:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:18 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:31 <sc68cal> Hello everyone
14:00:37 <baoli> Hi
14:00:42 <aveiga> hello
14:01:06 <sc68cal> No real concrete agenda today - so I won't bully everyone
14:01:27 <dzyu> hello everyone
14:01:46 <sc68cal> dzyu: Hi!
14:02:10 <sc68cal> #topic recap last meeting
14:02:10 <dzyu> long time to see you since I just came back this week
14:02:48 <sc68cal> #link http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-11-14.01.html minutes from last meeting
14:02:57 <sc68cal> No action items were posted last week
14:03:29 <aveiga> I'd like to fix that this week
14:03:39 <baoli> sc68cal, regarding the RA rule, I sent you an email with a few questions. Can you respond just to educate me?
14:03:41 <absubram> hi
14:03:47 <aveiga> I noticed that our wiki page is... lacking.  I'd like to take an AI to clean it up, sc68cal
14:04:04 <sc68cal> baoli: I'm hoping to discuss during the open discussion
14:04:13 <baoli> ok, sounds good
14:04:34 <sc68cal> aveiga: Thanks - I think everyone should take a crack at updating the wiki
14:04:47 <shshang> Good morning, afternoon, evening!
14:04:56 <xuhanp> hello, everyone
14:05:16 <sc68cal> Do we have any BPs to discuss?
14:05:51 <sc68cal> I know we have quite a bit to discuss regarding reviews
14:06:31 <sc68cal> #topic reviews
14:07:00 <sc68cal> I know I have to rebase my review so that the alembic script gets run correctly
14:07:22 <sc68cal> since it's so close to I-3 - it's going to get more frequent
14:07:46 <dzyu> Yes, I just rebase my code change https://review.openstack.org/#/c/56184/ base on Sean's code change
14:08:12 <xuhanp> sc68cal: I remember you still want to have some discussion about attribute validation
14:08:26 <xuhanp> based on your last comment
14:09:04 <sc68cal> xuhanp: Yes - I was worried about the deployment model we're using, but I was able to clear it up by talking to aveiga
14:09:35 <sc68cal> where ra_mode would be ATTR_NOT_SPECIFIED
14:09:43 <sc68cal> and address_mode would be SLAAC
14:09:58 <sc68cal> and enable_dhcp would be true
14:10:36 <sc68cal> and I believe the patch that shshang has makes everything work correctly
14:11:56 <sc68cal> where the dhcp agent will not start up on the v6 subnet, and dzyu's patch calculates the ipv6 slaac addresses. In theory. I haven't had a chance to do an integration test to verify
14:12:29 <sc68cal> Otherwise I just have to sit down re-read our convo last week and put together the code to block the bad combos we identified
14:12:47 <sc68cal> #action sc68cal add validation logic for bad combos identified last week
14:13:17 <sc68cal> #action sc68cal rebase first patch to fix alembic script
14:14:25 <sc68cal> Hoping that we can get xuhanp to rejoin
14:14:36 <dzyu> shshang: one question need to confirm. if ra-mode or address-mode is SLAAC/dhcpv6-stateless, OpenStack need to calculate the ip address base on subnet prifix and mac address, is it right?
14:14:55 <aveiga> dzyu: yes
14:15:01 <shshang> yes
14:15:32 <dzyu> Ok
14:17:42 <baoli> sc68cal, can we go over the questions regarding RA rule?
14:17:49 <sc68cal> yup - teeing it up
14:17:52 <sc68cal> baoli: you had some q's about this review? https://review.openstack.org/#/c/72252/
14:18:12 <sc68cal> since xuhanp rejoined
14:18:22 <xuhanp> yep. I was disconnected
14:18:47 <baoli> yes. with this command,     neutron router-gateway-set <router-id> <ext-net-id>
14:19:03 <baoli> an address from the ext-net will be the gateway IP, right?
14:19:48 * sc68cal checks the doc
14:20:22 <sc68cal> http://docs.openstack.org/havana/install-guide/install/apt/content/install-neutron.configure-networks.html
14:20:39 <sc68cal> there appears to be a last step, where you assign an interface to the router
14:21:04 <sc68cal> neutron router-interface-add EXT_TO_INT_ID DEMO_NET_SUBNET_ID
14:21:38 <baoli> sc68cal, that's the subnet gateway ip
14:21:53 <xuhanp> sc68cal: I believe this is for adding the tenent network
14:22:05 <xuhanp> what baoli mentioned is the external network
14:22:50 <baoli> is that DEVICE_OWNER_ROUTER_GW
14:22:52 <sc68cal> I'm not 100% sure on what router-gateway-set does inside the plugin
14:23:35 <sc68cal> but it looks like from that doc it's just establishing the route between the ext-net-id and the demo_net_subnet_id
14:24:03 <sc68cal> so, we'd only be concerned about RAs going from the newly created router & interface, announcing RA's inside demo_net_subnet_id ?
14:24:26 <sc68cal> I don't think we'd be changing anything on ext-net-id, but I could be wrong (likely)
14:24:49 <baoli> I think that my concern is this: for IPv6, if the gateway ip (router gw, or subnet gw) is used to construct a iptable rule to allow RA, then it should make it explicit.
14:25:20 <sc68cal> can you expand upon what you mean by making it explicit?
14:25:38 <xuhanp> so baoli, are you saying we should allow RA from other IPs on the external network?
14:25:46 <xuhanp> not only the gateway?
14:25:51 <baoli> For example, in the case of ipv4, the gw ip is used to establish a route
14:26:25 <baoli> xuhanp, I'm not saying that. I'm saying implicitly we are using these IPs to create iptables rules to allow RA
14:26:44 <baoli> in the case of IPv6
14:27:02 <aveiga> baoli: we are implicitly using all gateways, either set in the neutron subnet or by an attached router
14:28:08 <sc68cal> +1
14:28:25 <baoli> aveiga, I understand. But this gateway ip must be a LLA in the case of IPv6, in order for the proposed patch to work.
14:28:51 <sc68cal> baoli: I believe that is a separate issue.
14:29:05 <sc68cal> At this point we need a spike to see how a neutron router is created for ipv6
14:29:18 <sc68cal> it *may* already use an LLA. And if not, feel free to make a patch that does so
14:29:46 <aveiga> it MUST use an LLA
14:29:52 <aveiga> baoli is correct here
14:29:55 <aveiga> however
14:30:10 <sc68cal> I agree that it must be an LLA per the protocol, but I don't know what the neutron code currently does
14:30:14 <aveiga> we didn't put in any checking code
14:30:29 <aveiga> it has to be doing LLA, since an RA can'tbe issued otherwise
14:31:06 <sc68cal> someone want to volunteer to do a code audit on neutron routers for v6 functionality?
14:31:24 <xuhanp> I can do that
14:31:27 <baoli> neutron router-gateway-set <router-id> <ext-net-id> creates a router gateway port. And you can see it's from a ext-net. This means for ipv6, we have to create a ext net with LLAs. which doesn't sound right to me
14:32:00 <aveiga> there has to be an LLA on every net
14:32:34 <aveiga> I think this is a slightly different question from the code for filtering RAs
14:32:48 <aveiga> the real question here is are we checking that the router gateway IP is LLA?
14:33:12 <sc68cal> yes - and if anything, any code that addresses the LLAs will update the database with an LLA address, so the code xuhanp will pick it up correctly
14:33:20 <sc68cal> via his query
14:33:40 <sc68cal> which is a long way of saying, I think we should try and get the bug fix that xuhanp has proposed in, and investigate the LLA issue separately
14:33:41 <xuhanp> aveiga: I am not sure how to make sure the ext-net has LLA
14:33:49 <aveiga> you don't have to
14:33:55 <aveiga> EVERY net MUST have LLA
14:34:04 <shshang> +1
14:34:04 <aveiga> you can't do ND without it
14:34:12 <aveiga> or RD
14:34:18 <aveiga> or any kind of non-static addressing
14:34:41 <xuhanp> so you mean we just need to get it updated into database?
14:34:57 <sc68cal> xuhanp: that's my thought - +1
14:35:03 <aveiga> probably
14:35:10 <baoli> aveiga, the protocol defined LLA's prefix as fe80::
14:35:20 <aveiga> baoli: that's right
14:35:48 <aveiga> so the question is, do we want to validate that a router address being entered is LL?
14:35:49 <xuhanp> so we need to store two addresses for ext-net?
14:36:12 <aveiga> I would consider that we don't validate
14:36:16 <sc68cal> +1
14:36:24 <sc68cal> We just need to make Neutron use the LLA
14:36:25 <aveiga> in the case that someone wants to do static addressing and static route entries
14:36:32 <baoli> with this command, neutron router-gateway-set, you can't enter an LLA
14:36:42 <aveiga> ah, so that's an issue
14:36:53 <aveiga> but the issue isn't with the RA filtering code there
14:37:05 <aveiga> go up the chain and file a bug on the gateway code
14:37:22 <baoli> This is not an issue with IPv4
14:37:29 <baoli> So I don't think that it's a bug
14:37:35 <sc68cal> Ipv6 != ipv4
14:37:38 <aveiga> because there is no such thing as LLA in IPV4
14:37:45 <dzyu> whether need to restore LLA address, just make sure ext-net have LLA, is it enough?
14:38:47 <sc68cal> baoli: Can I add an action item for you to remove your -1, and do a blueprint to look into neutron gateways and LLAs?
14:38:57 <aveiga> dzyu: not sure where you're going there
14:38:59 <sc68cal> and you can report back to us next week on what you find
14:39:08 <aveiga> I think if neutron is running the router, it needs to be LLA
14:39:12 <baoli> sc68cal, well, the code won't work
14:39:22 <aveiga> but if it's an external device then it can be anything
14:39:38 <sc68cal> baoli: I do not agree
14:39:39 <aveiga> if it's either LLA or within the external net address range
14:40:01 <sc68cal> baoli: Your assertation that the code won't work is not due to a flaw in the patch that xuhanp has proposed
14:40:06 <baoli> sc68cal, I may be wrong if xuhanp has tested it thouroughly
14:40:32 <aveiga> baoli: try it yourself. Apply the patch and rebuild
14:40:38 <sc68cal> baoli: If you are concerned about LLAs - please propose a patch that enforces the usage of LLAs in v6 routers
14:40:53 <aveiga> eh, please don't
14:41:10 <aveiga> there are use cases where you might want to use GUA routing
14:41:18 <baoli> The patch assumes that the gateway IP is an LLA
14:41:27 <sc68cal> OK - then we can discuss that problem in that review - not in xuhanp's patch
14:41:42 <sc68cal> My point is that we have an open security issue, and I believe xuhanp 's patch gets us very close, if not closes it
14:41:59 <sc68cal> better to get the ball to the 10 than stay at the 50
14:42:04 <dzyu> +1
14:42:28 <baoli> if that assumption is not right, the patch wouldn't work as it's intended.
14:42:46 <baoli> sc68cal, can you point me to the patch that creates default rules to allow neighbor related messages?
14:43:03 <sc68cal> baoli: Please look at the linked bug
14:43:05 <sc68cal> I left it as a comment
14:43:14 <sc68cal> in xuhanp's patch's commit message
14:43:17 <sc68cal> This is basic stuff
14:43:30 <baoli> sorry I missed it.
14:43:32 <sc68cal> Honestly you can't be a roadblock for people if you're not able to do basic research
14:43:46 <sc68cal> I'm sorry to come off harsh but we're under the gun here
14:43:49 <sc68cal> for I-3
14:45:21 <baoli> well, not trying to be a road blocker. But that's what the review is there for, right?
14:45:42 <aveiga> I think the issue is an upstream one
14:45:56 <aveiga> fix the upstream code to make the assumption right, because it's a correct assumption
14:46:16 <aveiga> and if you really want to use GUA, then you'd have the sense to add an allow ICMPv6
14:46:27 <aveiga> at an SG level
14:50:54 <sc68cal> OK - well i suppose if nobody has anything else, we can adjourn for today
14:50:57 <absubram> sc68cal: Sean.. do we have time for open discussion.. or would you rather I sent out an email.. for the Horizon BP
14:51:13 <sc68cal> absubram: sure!
14:51:18 <sc68cal> #topic open discussion
14:51:19 <absubram> just a couple quick questions.. I only have Sean's neutron diffs so I may be missing some other important patches..
14:51:37 <absubram> but I have been able to get basic functionality working
14:51:48 <sc68cal> cool!
14:52:00 <absubram> i.e I am able to create subnets with the two options.. for SOME combinations.. eg slaac/slaac; slaac/stateful
14:52:09 <absubram> however off/off does not work
14:52:26 <absubram> it seems to find "off" to be a bad parameter in neutron?
14:52:30 <sc68cal> when you say off/off- do you mean you're sending strings with the value of "off"?
14:52:48 <absubram> yes.. that's exactly what I am doing.. sending a string "off"
14:52:58 <absubram> is that wrong?
14:52:59 <sc68cal> Ah ok - sorry for the confusion
14:53:17 <sc68cal> I think when we say "off" - we mean ATTR_NOT_SPECIFIED
14:53:25 <absubram> ah ok
14:53:45 <absubram> so that was going to be next question.. if no value was presented would that be the same as off
14:53:49 <sc68cal> basically if they're off - don't set the attribute
14:53:59 <sc68cal> Does that make sense?
14:54:13 <absubram> ok.. right.. so I am able to create subnet via Horizon fine when I don't have a value specifified for the two attributes
14:54:20 <absubram> so I'll just get rid of the "off" option
14:54:23 <aveiga> it might also be good to recheck after sc68cal updates his code with the validation portion.  There are combinations (such as slaac/stateful) that are invalid
14:54:37 <sc68cal> +1 - although Neutron will return an error giving you the reason
14:54:44 <absubram> ok.. Sean mentioned neutron does the check for invalid combo?
14:54:46 <absubram> ok cool
14:54:54 <sc68cal> so you should be able to just display what neutron gives you back in the case of an error
14:54:59 <absubram> again I have only ttested to see if I can create a subnet
14:55:13 <absubram> I haven't actually tested the subnet itslef then to see if it functions correctly
14:55:21 <absubram> was hoping one of you could test that for me :)
14:55:47 <absubram> I'll send out an email with a pointer to the review as soon as I have it up.. which should be this afternoon.. need a little code cleanup
14:56:20 <absubram> then shshang I'll take up on the offer you made last week to test it ;)
14:56:30 <shshang> sure
14:56:44 <shshang> let me know what I can help you wiht
14:56:56 <shshang> thanks for giving me heads up
14:57:01 <sc68cal> Yeah we'll need to refresh dzyu's neutron-cli review
14:57:02 <absubram> those were the only questions I had on Horizon.. I did hit a differnt issue via CLI.. but thankfully not via Horizon
14:57:45 <dzyu> Yes, I will change neutron cli ASAP
14:57:53 <xuhanp> dzyu and also have confusions about address calculation code. Will discussion it in ML
14:57:54 <absubram> CLI returns this for some reason
14:57:56 <absubram> absubram@absubram-VirtualBox:~/devstack$ neutron subnet-create ab_net_v6_1 --ip-version 6 --ipv6_ra_mode slaac --ipv6_address_mode slaac fe80::/80 --name ab_sub_v6_1 Invalid input for ipv6_ra_mode. Reason: 'True' is not a valid string.
14:58:04 <absubram> but it works fine vis dashboard now
14:58:15 <sc68cal> yeah the CLI hasn't been patched to take the new attributes
14:58:20 <absubram> got it
14:58:36 <absubram> ok.. that's all I had.. look out for my email later today :)
14:58:41 <sc68cal> feel free to coordinate with dzyu - the old review is here https://review.openstack.org/#/c/54250/
14:58:51 <dzyu> xuhanp, I have talked it with shshang
14:59:16 <xuhanp> cool.
14:59:19 <dane_> shshang: Any luck with the UT?
14:59:26 <sc68cal> shshang: I got your e-mail this morning, let's try and meet up tomorrow during the day
14:59:37 <shshang> No...I am still struggilng with submitting the change.
14:59:39 <shshang> :(
14:59:54 <shshang> sure, thanks sc68cal and dane
15:00:17 <sc68cal> ok everyone - till next time
15:00:17 <sc68cal> #endmeeting