14:00:08 <sc68cal> #startmeeting neutron_ipv6
14:00:09 <openstack> Meeting started Tue Jan 21 14:00:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:37 <sc68cal> Hello everyone - thanks for being here
14:00:57 <sc68cal> #topic recap previous meeting
14:01:11 <sc68cal> Agenda for the ipv6 meeting - https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Jan_21st
14:01:58 <sc68cal> Last week the only real action item we had was for shshang to send an e-mail to the mailing list about a new set of attributes
14:02:22 <sc68cal> he does not appear to be on - so we'll have to see if he joins late
14:02:25 <xuhanp> yep. I saw that one and your last comment about which commit it should go to.
14:03:09 <xuhanp> there is shshang
14:03:16 <sc68cal> shshang: welcome
14:03:29 <shshang> Good morning! Good Night!
14:04:00 <dzyu> Good morning! shshang
14:04:09 <sc68cal> shshang: we had an action item last week for you - do you have any progress to share?
14:04:20 <sc68cal> "
14:04:21 <sc68cal> shshang send e-mail to mailing list regarding new attribute
14:04:23 <sc68cal> "
14:04:45 <shshang> I did, but I am waiting for Anthony and Ian to confirm.....
14:05:13 <shshang> it is not the ultimate solution, but I think we can live with that in Icehouse release while waiting for API to settle down
14:06:05 <shshang> let me sent the email to the mailer, so everybody here can take a look
14:06:51 <sc68cal> It's probably going to take a while to propogate, so can you share it here
14:07:57 <shshang> As we discussed last time, we need a pair of keywords
14:08:15 <shshang> the first one is to control whether RA is sent and which bits are set
14:08:58 <shshang> the second one is to control who manage the address assignment leverage DHCPv6
14:10:06 <shshang> But since Neutron team want backward complaintability and a boolean value, and we are stuck to enable_dhcp.
14:10:41 <shshang> the table included in the email was created to see whether we can take advantage of what we have so far to move the needle forward
14:11:22 <shshang> it is surely not the BEST solution, but before API decision is made, it is one of the alternate solutions.
14:11:47 <shshang> Did you guys get the email?
14:12:11 <xuhanp> not yet
14:12:30 <sc68cal> not yet - so we may need to move discussion to the ML
14:12:30 <dzyu> is the link: http://lists.openstack.org/pipermail/openstack-dev/2014-January/024179.html?
14:12:47 <shshang> let me verbally summarize it....
14:13:14 <shshang> Anthony made an excellent point over and over again, which I overlooked before
14:13:27 <aveiga> I did?
14:13:46 <shshang> oh, you are HERE! I thought you are hidden. :D
14:14:03 <shshang> aveiga, I think you can explain your thoughts better than me. :D
14:14:37 <aveiga> I got in late
14:14:52 <aveiga> some mixups with an exchange server :/
14:15:03 <sc68cal> #topic blueprints
14:15:05 <shshang> you want to explain to the crew members on the neutron+ipv6 boat?
14:15:37 <aveiga> I think sc68cal is interesting in moving the topic
14:15:47 <aveiga> and I'm not sure what you wanted to dicsuss
14:15:51 <sc68cal> just keeping the topic current
14:15:53 <shshang> OK, then we can discuss it further in ML
14:16:04 <aveiga> sorry, someone catch me up then
14:16:27 <sc68cal> OK - so there's a proposal to make additional attributes and replace the subnet_mode attribute
14:16:35 <shshang> aveiga, would u plz do me a huge favor verifying the table included in the email to the ML?
14:17:00 <shshang> I need your expertise there
14:17:11 <aveiga> shshang: when I receive it I will, the ML usually takes a good half hour to get to me
14:17:23 <sc68cal> Is the plan for this to be replacing our current code review, or an addition?
14:17:39 <sc68cal> I asked on the ML - http://lists.openstack.org/pipermail/openstack-dev/2014-January/024902.html
14:17:49 <aveiga> sc68cal: I think the idea was to change it from subneet_mode to addressing mode and routing mode
14:18:11 <aveiga> otherwise, we would just have to make subnet_mode a full matrix of permutations
14:18:47 <sc68cal> It sounds like the answer is "replace"
14:18:58 <aveiga> with the intent to decouple them, as people have been seeing both in the IPv6 world and even in today's mail in the IPv4 world, sometimes you want an external system to handle certain bits
14:19:13 <aveiga> we should be functional, but also be able to get out of t he way if another solution is brought in place
14:19:18 <aveiga> i.e. be modular
14:19:57 <aveiga> so if you're using a provider net router but want OpenStack to do addressing, we just need the address bit and no RA
14:20:28 <aveiga> or if we want OpenStack to do the routing but we need a specific DHCPv6 server to comply with some policy, we could run just the routing bits and don't run addressing
14:20:52 <aveiga> honestly, it's fine either way
14:21:08 <aveiga> it really becomes an implementation decision
14:21:36 <sc68cal> My concern with this is that we're going to have to do a full 180* on this, so I don't know if we'll be able to make anything for Icehouse with this new proposal
14:21:47 <aveiga> whether you want to enumerate and loop through all the permutations or split the function and the parameters
14:22:07 <aveiga> well, then keep it to the full list of permutations
14:22:18 <aveiga> and leave some of them "cuirrently unimplemented"
14:22:48 <aveiga> but there's the whole issue of folks wanting the enable_dhcp attribute to still be there
14:22:59 <aveiga> personally, t hat's a bad idea, as DHCPv6 isn't a binary on/off
14:23:15 <ijw> 2 weeks running, *sigh*
14:23:20 <aveiga> and the permutation idea doesn't work unless the value of enable_dhcp actually matches
14:23:23 <aveiga> or we ignore it
14:23:54 <ijw> I'm going to jump in without the prior discussion on this - what the cores want from enable_dhcp is that, if it's false, nothing transmits DHCP *or* RAs
14:24:11 <aveiga> that makes a little more sense
14:24:22 <aveiga> basically disable the network management functions
14:24:27 <ijw> So I would use it as a global disable flag, and then use other flags (with defaults that match Neutron's current behaviour) for the specific choice of behaviour we want
14:24:35 <ijw> yup
14:25:28 <xuhanp> so what happen when enable_dhcp is true?  RA or DHCP?  or depends on the other attribute to decide?
14:25:58 <aveiga> yes, the other attribute becomes important
14:26:20 <aveiga> and even then, it could still be disabled if the other attribute is set off/off
14:26:31 <aveiga> but it passes control to the other attribute
14:27:13 <ijw> Yup, indeed
14:27:15 <xuhanp> then we probably should not allow that to be happen since it doesn't make sense to end user.
14:27:16 <aveiga> sc68cal: if we did the permutations as values, do you still think we'd delay past Icehouse?
14:27:22 <ijw> enable_dhcp becomes a backward compatibility thing, really
14:28:18 <aveiga> I'm still uncomfortable with one value to control multiple subsystems, but I'll accept it in the name of progress
14:28:23 <ijw> aveiga: If we have a DHCPv6 server independent of an RA server, and we use something specifically RA-sending like RADVD so that we have the maximum of control over RAs, then can we implement the two attributes entirely independently of each other?
14:28:49 <aveiga> ijw: yes, but you joined after sc68cal mentioned that would push us out too far
14:29:14 <sc68cal> aveiga: we'd need to see the proposal to get a good idea. However, I'm very concerned about how it's now basically I-2 and we've got nothing off the ground, and now we're going to do a whole re-arch
14:29:46 <dzyu> the other attribute should be what? boolean?
14:29:58 <shshang> another attribute is values
14:29:59 <aveiga> dzyu: nope, no booleans here
14:30:00 <sc68cal> I know that my change wasn't great- but it was proposed back in November - it's had a bit of time to bake and it still hasn't gone far
14:30:21 <shshang> you will see more details in the email. It listed all possible values
14:31:00 <sc68cal> Has any code been written for this new proposal?
14:31:36 <shshang> I got most of the dnsmasq part of the code done with the exception of two scenarios. I am still researching on it.
14:31:48 <shshang> it is 75% complete
14:31:59 <shshang> I should get it out by tomorrow
14:32:13 <shshang> but that is only 1 piece of the puzzle
14:32:37 <ijw> aveiga: the bit I'm missing, I think, is what we could implement that we would be able to do in time and wouldn't have us screwed for backward compatibility
14:32:46 <sc68cal> OK - has anyone added the attribute to the API, and the db migration, as well as additions to the db_base_plugin_v2 ?
14:33:14 <xuhanp> dzyu and I can help with that if that's needed urgently
14:33:25 <dzyu> Yes
14:33:26 <xuhanp> you know, to speed up this
14:33:31 <ijw> sc68cal: and that's important - if we do put this out and it's wrong we are stuck with it for at least a year till the v2 api goes away
14:33:42 <shshang> xuhanp, and dzyu, that will be AWESOME!
14:33:57 <aveiga> we need to get the attributes nailed down for that work to happen at all
14:34:06 <shshang> yes
14:34:08 <sc68cal> If you guys share the details - I can rework my piece to fit what you guys are proposing
14:34:11 <aveiga> so one attribute or two?
14:34:37 <xuhanp> and will dzyu's address calculating code still be useful?
14:34:41 <shshang> I vote for two
14:34:44 <aveiga> xuhanp: yup
14:34:46 <xuhanp> we get that based on Sean's current code now.
14:34:51 <shshang> xuhanp, yes, that part is still valid
14:35:09 <ijw> I think two and I think we have to write this in the BP so that everyone's clear what it is - we've been discussing it in private and that is, I suspect, not helpful sc68cal's opinion of us ;)
14:35:29 <sc68cal> No - it has not made me happy
14:35:30 <aveiga> +1
14:35:51 <aveiga> ok, let's get the BP setup for the two attributes then
14:36:08 <sc68cal> Who should I make responsible for that
14:36:14 <aveiga> we can mostly ignore enable_dhcp except to say that if it's off, everything is disabled
14:36:29 <dzyu> yes
14:36:37 <shshang> can everybody review the email in the ML, and then nail down the values first?
14:36:47 <shshang> then we can create BP?
14:36:51 <shshang> and then we can code?
14:37:32 <xuhanp> sure. then also talk about the code assignment in the ML?
14:37:41 <shshang> Yup
14:37:56 <shshang> that is the fastest way to get everybody aligned
14:39:18 <shshang> I can set up a BP in the next 10 mins. Very simple. Just to capture the discussion with aveiga and ijw. It should be immediately available to everybody.
14:39:34 <shshang> instead of waiting for ML
14:40:59 <sc68cal> #action shshang register new blueprint for IPv6 attributes
14:41:18 <sc68cal> #action aveiga ijw shshang discuss new IPv6 attributes on ML
14:41:40 <sc68cal> Everyone else - please participate as well
14:41:57 <sc68cal> I spoke with core devs yesterday and they are looking out for e-mails regarding this
14:42:38 <sc68cal> I don't have anything else, so open discussion?
14:42:46 <xuhanp> I have a bug opened by ijw which I want to have a quick talk.
14:42:54 <sc68cal> ok - we can do that
14:42:59 <sc68cal> #topic bugs
14:43:04 <sc68cal> have a link handy?
14:43:08 <xuhanp> https://bugs.launchpad.net/neutron/+bug/1262759
14:43:17 <xuhanp> I was trying to help on this one since it's IPv6 related
14:43:25 <xuhanp> but I have some confusion about it.
14:43:25 <sc68cal> #link https://bugs.launchpad.net/neutron/+bug/1262759  ICMPv6 RAs should only be permitted from known routers
14:43:42 <ijw> OK - the issue is that Linux will take an RA from anyone.  It's a tart, basically
14:43:49 <xuhanp> https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L284
14:43:54 <xuhanp> but looking at the code here
14:44:17 <xuhanp> I can see there is already some rules for tenant RA from dhcp port
14:44:43 <aveiga> xuhanp: that's only part of the puzzle
14:45:05 <aveiga> we need to allow external gateways (provider networks) and advances services VMs as well
14:45:07 <xuhanp> I know we are trying to separate the RA from dhcp, but is it missing other things?
14:45:19 <ijw> Hmm
14:45:25 <ijw> you know, I didn't know that was there
14:45:44 <xuhanp> that's sc68cal was trying to do in his patch: https://review.openstack.org/#/c/53028/9
14:45:45 <xuhanp> right?
14:45:51 <xuhanp> aveiga?
14:46:16 <aveiga> yes, that was the intent
14:46:28 <aveiga> but sc68cal basically opened up all RAs
14:46:37 <aveiga> in the itnerest of working first, secured later
14:46:58 <aveiga> ideally, the admin should register these things as Routers in Neutron
14:47:02 <xuhanp> aveiga, are you saying we need a config list to let admin/user specify the router address to allow only them?
14:47:05 <aveiga> and we should accept all RAs from Routers
14:47:13 <sc68cal> I believe the fix is remove the RA from ICMPV6_ALLOWED_TYPES, then add a function similar to that function in security_groups_rpc that looks up the gateway and other services, and adds a rule that allows in the ICMPv6 type for RAs
14:47:26 <aveiga> +1 to sc68cal
14:47:29 <aveiga> that's the ideal way
14:47:37 <shshang> agree
14:47:46 <sc68cal> I have a patch that is WIP adding a function that does just that to security_groups_rpc
14:47:53 <ijw> xuhanp: that original assumes RAs come from the DHCPv6 server and that would be the problem I think
14:48:27 <ijw> It should be operating on the list of known routers (which should include both internal and external ones)
14:48:28 <xuhanp> sc68cal, when you say the gateway and other services, do you mean the provider network?
14:48:44 <xuhanp> I mean the external ones?
14:48:49 <sc68cal> xuhanp: provider network sets the gateway - it's just an external gateway
14:48:54 <aveiga> ijw: actually, it would not impede it
14:49:12 <aveiga> if you moved the RA to the router namespace, then the gateway rule would still allow the RA
14:49:30 <aveiga> it would just leave an opening for the DHCP namespace to also send one
14:49:47 <aveiga> which shouldn't happen if the implementation is intelligent enough to split the RA to the rotuer namespace anyway
14:50:18 <ijw> aveiga: cross purposes, I think - I was talking about the current code that xuhanp pointed at
14:50:24 <aveiga> yep
14:50:31 <aveiga> I get it knwo
14:50:34 <aveiga> now*
14:51:07 <shshang> https://www.dropbox.com/s/kyh7vpty0nugaza/IPv6%20Two%20Modes.pdf
14:51:14 <shshang> This is the table in my email to the ML
14:51:23 <shshang> I just uploaded to the dropbox
14:51:51 <xuhanp> sc68cal, do you have a blueprint for that WIP code change?  Can I help on that too?
14:52:13 <xuhanp> just a great opportunity to get familiar with these stuff.
14:52:33 <sc68cal> xuhanp: no bp for it, I was just going to add a Bug # to the commit message - but yeah I'll make sure to announce it on the ML and share the link next week worst case
14:52:46 <sc68cal> I'll probably get it posted to gerrit this week
14:53:02 <shshang> sc68cal, here is the new BP I created. https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
14:53:21 <xuhanp> sc68cal, OK. let me know what I can help here. Thanks
14:53:31 <shshang> everybody, please help review........
14:53:49 <sc68cal> so it's really only one *new* attribute
14:53:56 <shshang> YUP
14:53:56 <aveiga> shshang: no, don't reference enable_dhcp
14:54:04 <aveiga> that needs to be another attribute
14:54:15 <shshang> OK!
14:54:19 <shshang> I will change it
14:54:40 <aveiga> it's not dhcp
14:54:42 <aveiga> it's addressing
14:55:15 <sc68cal> #topic open discussion
14:55:16 <aveiga> SLAAC is part of it, because if SLAAC is on we need to determine the EUI-64 address and provide it to Neutron
14:55:24 <shshang> True
14:55:30 <shshang> I am updating it now
14:55:35 <xuhanp> shshang, is the PDF same with the email in ML?
14:55:38 <shshang> thank you for pointing it out
14:55:59 <shshang> the email included the same table as pic
14:56:08 <xuhanp> got it
14:56:22 <shshang> The PDF is also in my dropbox. I can send you the PDF if you need it.
14:56:54 <xuhanp> yes, please. pengxuhan@gmail.com   Thank you
14:57:46 <shshang> Please provide your feedback on ML, so we can capture them to finalize the BP
14:57:54 <sc68cal> make sure that BP is linked to the IPv6 feature parity BP
14:58:06 <shshang> sc68cal, yup, I am doing it no
14:58:07 <shshang> now
14:58:22 <shshang> sc68cal, do you think we can nail down the attributes by tomorrow?
14:58:38 <shshang> or in the next 48 hours?
14:58:38 <aveiga> depends on the BP and the ML feedback
14:58:43 <aveiga> but we should be able to
14:59:00 <sc68cal> if I've got good doc - I can rework my review to add the second attribute, and rename dhcp_modes to the first
14:59:36 <dzyu> yes, it will be more easy than replace it
15:00:34 <shshang> sc68cal, linked it to your original BP
15:00:37 <sc68cal> yep - plus dzyu's logic for when to do SLAAC cn be reused
15:00:54 <shshang> and I will put you as approvor
15:01:01 <sc68cal> alright everyone - to the mailing list!
15:01:05 <sc68cal> #endmeeting