13:59:35 <sc68cal> #startmeeting neutron_ipv6
13:59:36 <openstack> Meeting started Tue Feb  4 13:59:35 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:39 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:46 <sc68cal> #topic recap previous meeting
14:01:14 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Feb_4th Agenda for today
14:01:49 <sc68cal> Looks like shshang isn't here yet
14:03:03 <sc68cal> So, last week I had an action to rebase the review and add the second ipv6 attribute to subnets
14:03:27 <sc68cal> #link https://review.openstack.org/#/c/52983/ Create new IPv6 attributes for Subnets
14:04:20 <sc68cal> So at this point it's just fixing some issues with the migration and db models to make them play nice with postgresql
14:05:08 <sc68cal> shshang has a review that we're trying to get rebased on top of that review, so the gate will test it properly
14:05:32 <aveiga> is that the one that the of you were working out in #openstack-neutron last week?
14:06:18 <baoli> sc68cal, one question with this review: https://review.openstack.org/#/c/58186/. Is it completely abandoned? shshang's new review covers dhcp. What about the remaining changes in 58186?
14:06:50 <sc68cal> baoli: I imagine that will be rebased
14:06:54 <aveiga> baoli: I think that one is abandoned, as it's using an old model
14:07:10 <aveiga> that was basing on running the entire dhcpv6 server out of the router space
14:07:12 <shshang> Yes, that one is abandoned
14:07:23 <sc68cal> ah whoops
14:07:27 <baoli> ok.
14:07:49 <sc68cal> For some reason I was thinking the IPV6 SLAAC blueprint - which was just abandoned this morning
14:08:14 <baoli> So the changes in the firewall module is no longer needed with this new model
14:08:52 <aveiga> which changes?
14:09:08 <baoli> https://review.openstack.org/#/c/58186/2/neutron/agent/linux/iptables_firewall.py
14:09:34 <shshang> The firewall changes, I think, is duplicating with DaoZhao's code
14:09:47 <aveiga> +1
14:09:59 <sc68cal> I think it actually duplicates this
14:10:04 <aveiga> it's necessary, but will be compartmentalized to be added only for gateway IPs
14:10:19 <aveiga> and that's what DaoZhao's working on
14:10:21 <xuhanp> hello everyone, sorry for being late
14:10:25 <sc68cal> https://github.com/netoisstools/neutron/commit/cecd7591533e2c046aedba3b8e5d14a5b2fa7fe9
14:10:32 <shshang> Hey, xuhanp
14:10:53 <xuhanp> hey. sorry for interrupting, pleaes continue.
14:11:24 <baoli> got it.
14:11:38 <sc68cal> shshang: Do you have the link handy for the blueprint for horizon that we needed to register?
14:12:12 <sc68cal> I have an old one - https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-mode-support
14:12:38 <shshang> No....I didn't register one yet for horizon....Sorry about that. :(
14:12:50 <shshang> Will do today
14:12:56 <sc68cal> shshang: OK - well let's just repurpose the one I created a while back
14:13:22 <sc68cal> #action sc68cal edit horizon blueprint to match new attribute blueprints in neutron
14:13:28 <absubram> Hi can we add some more details to that Horizon bp please?
14:13:58 <sc68cal> #topic blueprints
14:14:11 <sc68cal> absubram: Yes - do you have any suggestions?
14:15:12 <sc68cal> Alright. Moving on
14:15:34 <baoli> sc68cal, shshang, one more question regarding the abandoned review: https://review.openstack.org/#/c/58186/2/neutron/agent/l3_agent.py. what happens to that change?
14:16:05 <absubram> well I am new to this.. but I was taking a look at it from what needed to be done in Horizon.. and I am not really sure what the ipv6 effort adds from neutron..
14:16:12 <absubram> so maybe just some whiteboard notes
14:16:23 <shshang> The l3_agent function will be carried onto icehouse release. I am waiting for Randy to join. He owns that piece
14:16:25 <sc68cal> baoli: Check out shshang's new review https://webmail.comcast.com/owa/redir.aspx?C=QxLI8ZBxq0GPzZXTFxWndIhLZPRF9dAIqAyUc7s4-RSvq9I03V1QBlP0VXz43dUkRD1zumO4wBI.&URL=https%3a%2f%2freview.openstack.org%2f70649
14:16:30 <sc68cal> shit
14:16:34 <absubram> that way it'd be easier to figure out what needs to be done from Horizon to support this?
14:16:38 <sc68cal> https://review.openstack.org/#/c/70649/
14:16:52 <aveiga> absubram: the horizon piece is going to need to reflect the new options we're adding to the API
14:17:05 <shshang> I am only working on the tenant network side
14:17:11 <aveiga> there are two keywords going in for managin IPv6 subnets
14:17:21 <shshang> and Randy is working on the external network side
14:18:06 <baoli> shshang, another BP or a bug?
14:18:27 <absubram> aveiga: thanks! can we add that detail and what the new keywords are? In the horizon bp..
14:18:48 <aveiga> absubram: Yes, because it will be directly linked to the other BP covering said attributes
14:19:00 <sc68cal> absubram: there's a link to the neutron bp in the description for the horizon bp
14:19:22 <shshang> https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
14:19:38 <absubram> ok thanks!
14:19:41 <absubram> will look at it
14:20:50 <aveiga> absubram: you might want to go back and take a look at our past meeting minutes to catch up, there's a lot we've discussed previously that explains why we're doing what we're doing: https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam
14:21:57 <baoli> shshang, so this BP will also cover the change in l3_agent.py, and Randy will be working on it. thanks.
14:22:37 <absubram> aveiga: good suggestion.. I'll be sure to do that
14:23:48 <sc68cal> Anything else on the blueprint side before I turn it over to open discussion?
14:23:58 <aveiga> so besides the Horizon BP, are there any missing to complete our existing goals for Icehouse?
14:24:05 <baoli> Any work with devstack to setup ipv6?
14:24:06 <aveiga> I think no, at this point
14:24:17 <shshang> sc68cal, I still need your help to link my code to your base
14:24:45 <aveiga> sc68cal has been setting up devstack in our lab with v6, but it's tweaked to use provider networks.  I don't think there's much to change though for GRE
14:25:09 <shshang> sc68cal, do you have some time today and we can use google hangout?
14:25:15 <aveiga> sc68cal: would it be possible to post your configs as a gist?
14:25:31 <aveiga> or maybe in the openstack etherpad
14:25:39 <sc68cal> shshang: Yes - I can help you today
14:26:07 <sc68cal> I can post my configs for devstack as well that we use in the lab
14:26:33 <baoli> cool
14:26:35 <sc68cal> I also have a branch of devstack that creates v6 subnets - so I'll post that branch as well
14:27:30 <rtuttle1015> @baoli: yes, I am addressing the l3_agent.py for external gateway
14:27:51 <baoli> rtuttle1015, thanks.
14:28:23 <baoli> sc68cal, would the changes you have for devstack needs to be upstreamed?
14:28:53 <sc68cal> #action sc68cal post branch of Devstack + configs on the mailing list
14:29:07 <sc68cal> baoli: They'd need some work for that
14:29:11 <aveiga> baoli: not sure, like I said they're specific to provider nets and I know devstack doesn't normally do that
14:29:24 <sc68cal> ^^^ what aveiga said
14:29:43 <aveiga> but if they can be altered to do GRE tunnels, then I don't see why not
14:29:54 <aveiga> start exposing the rest of openstack devs to v6 as soon as we can
14:30:04 <baoli> well, let me think about that
14:30:15 <aveiga> once they're up, have a look
14:30:23 <aveiga> if you see something you can do to integrate them, go nuts
14:30:34 <baoli> sure thing
14:30:59 <aveiga> I think we're clear on BPs then
14:31:21 <sc68cal> #topic open discussion
14:31:53 <shshang> Randy and I have a question regarding semantic check
14:32:24 <shshang> In two attributes combination, some modes are not valid for some use cases
14:32:51 <aveiga> I think the determination we made last time was to let it go
14:33:03 <shshang> We think we need to add semantic check to return errors to client (both neutron CLI and Horizon)
14:33:04 <aveiga> if the user is configuring these, they need to know enough about IPv6 networks
14:33:20 <aveiga> for the same reason that we covered not just assuming it's invalid
14:33:31 <aveiga> maybe a user is trying to do something we haven't come across yet
14:33:52 <shshang> yes, so in this case, we need to let user be aware what they are doing is not supported
14:34:04 <rtuttle1015> but if the wrong combos get to the agent on network node, weird configs get hard to debug. why not send the error back from API
14:34:06 <aveiga> what's not supported, though?
14:34:18 <aveiga> rtuttle1015: which use case are you referring to?
14:34:28 <shshang> So the best place we can think of is on neutron server side
14:34:33 <rtuttle1015> shshang's table are the valid cases
14:34:51 <shshang> which can cover both neutron client and horizon
14:35:05 <rtuttle1015> can we not include a static table of some sort that determines the valid combos
14:35:14 <xuhanp> I think we can add the check to Sean's code which is validating the two modes
14:35:28 <aveiga> we can't make a determination on validity
14:35:28 <rtuttle1015> yes, this is what shshang and I were thinking
14:35:32 <shshang> xuhanp, that is what we are thinking too
14:35:33 <aveiga> that's the core of what I'm getting at
14:35:55 <rtuttle1015> no, we have shshang's table which highlight the current supported combos.
14:36:10 <sc68cal> rtuttle1015: ah , is that what those red squiggles are?
14:36:12 <rtuttle1015> a truth table of sorts
14:36:22 <aveiga> I can't seem to find the table
14:36:39 <aveiga> or at least, the most recent version
14:36:40 <sc68cal> #link https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf Ipv6 modes table
14:36:45 <shshang> sc68cal, yes, the highlighted one are the ones we support and we developed
14:36:51 <rtuttle1015> yes, that's it
14:37:07 <sc68cal> you guys should amend that PDF to add that - I sort of was wondering what it was
14:37:21 <shshang> yes, we will
14:37:36 <aveiga> that PDF has everything underlined except the cases where averything is off
14:37:50 <aveiga> which is the equivalent to setting enable_dhcp = 0
14:37:56 <shshang> for example, if subnet has no gateway port, and user want dnsmasq to send RA, then we need to return error
14:38:23 <shshang> I need to update the link to version 3.0
14:38:32 <aveiga> shshang: what if the gateway is going to be added by config drive when a service VM starts up?
14:38:39 <aveiga> it would need to be on-net before the port could be added
14:39:14 <shshang> that is the case we didn't have time to cover yet
14:39:19 <aveiga> right
14:39:27 <aveiga> that's why I'm saying don't throw a validation error
14:39:32 <aveiga> just silently let it go
14:39:37 <sc68cal> aveiga: I imagine we'd need to talk to the service insertion folks
14:39:55 <aveiga> sc68cal: I'm imagining this is possible on your own today even without that piece
14:39:57 <sc68cal> since they're tackling the problem of how to insert firewalls and other services into the wire
14:40:28 <aveiga> I could spin up an haproxy today on v6, use config drive to manually add the v6 address that's not part of the pool but still inside the /64, and then use the api to add it as the gateway
14:40:29 <shshang> aveiga, that is actually the next topic I want to bring up
14:41:18 <shshang> the validation should be there based on the current configuration. If later on, the setup is changed, then we need to trigger the validation again.
14:41:31 <shshang> So this is 2-fold story
14:42:14 <aveiga> but according to your table, all modes are valid except off/off
14:42:47 <shshang> I refer to a case in the last email thread, which discuss private network v.s. provider network.....
14:43:20 <shshang> You bring up a good point of provider network in your reply.
14:44:28 <aveiga> I think we have a different issue here
14:44:48 <aveiga> that's a question of which addresses we want to use on a private network
14:45:03 <aveiga> technically, we don't need any since LLA should be sufficient
14:45:31 <shshang> yes, that cover address assignment side. How are about RA side?
14:45:38 <aveiga> no RA
14:45:41 <aveiga> if you're using LLA
14:45:44 <aveiga> but that's not the question
14:45:45 <shshang> exactly
14:45:57 <aveiga> the question is do we want to support GRAs on a private network?
14:46:01 <aveiga> or even ULAs
14:46:06 <shshang> what if user configure ipv6_ra_mode with attribute to enable RA
14:46:21 <aveiga> enabling RA only works if there's a gateway port
14:46:22 <shshang> we know we don't need RA, but user may not know
14:46:53 <shshang> there is nothing prevent them from typing ipv6_ra_mode = DHCPV6 Stateful
14:47:07 <shshang> and if that happens, the system needs to tell them, sorry, this is wrong
14:47:28 <aveiga> if there's no gateway, then we report that we can't issue RAs
14:47:31 <aveiga> no matter what mode
14:47:43 <baoli> aveiga, why enabling RA only works if there's a gateway port?
14:47:46 <shshang> exactly. The "report" piece is what I am looking for
14:47:52 <aveiga> baoli: something has to send the RA
14:48:03 <shshang> The "report" is what I refer to semantic check
14:48:10 <shshang> the system need to throw error
14:48:11 <baoli> You can send it through the dhcp port, right?
14:48:26 <aveiga> baoli: only if you want to permanently blackhole that network
14:48:37 <aveiga> if I add a gateway port later, it won't do anything
14:48:47 <aveiga> most linux distros ignore multiple RAs for the same subnet
14:49:06 <aveiga> so the second RA would come from the valid gateway, but get ignored.  Then you can't route
14:49:34 <baoli> I think that's the purpose of ULA? In addition, a port can have mutiple ipv6 addresses in addition to ULA
14:50:12 <baoli> aveiga, a route can be associated with a preference value
14:50:13 <aveiga> if you want ULA, then you have to advertise only ULA
14:50:26 <aveiga> baoli: linux doesn't honor the preference value
14:50:32 <aveiga> there are MANY bugs filed against this
14:51:02 <shshang> If user add a gateway port later, DB is updated. If user prefer change the subnet mode, then they can do it now.
14:51:06 <aveiga> I've been testing this in production environments for the past 5 years, and it's not reliable
14:51:20 <aveiga> shshang: that's fine, but they have to re-address
14:51:21 <baoli> aveiga, I tried. I have radvd running in both the dhcp namespace and the router space, and I have the route from the router spave have higher preference, and that route is chosen
14:51:43 <aveiga> or you have to have a really short RA lifetime and remove it completely from the dhcp server
14:52:37 <aveiga> do you want to extend the semantics check to only allow advertising RAs from the DHCPv6 namespace when there's also no gateway and only using ULA space?
14:52:49 <aveiga> but then that's not goign to be pleasant either, because ULA can be routed
14:53:09 <aveiga> or we just only support LLA on non-routed networks?
14:53:18 <aveiga> this is not a simple question
14:53:32 <baoli> I have a couple of more questions, 1. are the two new subnet modes exposed to the normal users? 2. normally a user launches a VM with nova boot --nic, and the nic will be associated with one of the subnets available in a network. how does the VM user indicate that the VM should be enabled with ipv6 and with which ipv6 subnet?
14:53:34 <shshang> aveiga, is that question to me, or to baoli?
14:53:41 <aveiga> shshang: to all
14:54:05 <aveiga> baoli: they don't, this is only network-level configuration
14:54:11 <shshang> How are about this, would u plz do me a favor sending all of the use cases to the ML, and we can chew on it.
14:54:23 <aveiga> shshang: I don't think I can even cover them all
14:54:23 <shshang> it also gives us a chance to think it through.
14:54:28 <aveiga> I'm sure I will miss a bunch
14:54:38 <aveiga> but I can try
14:54:48 <shshang> Just a couple of them, which will impose challenges on the semantic checks
14:54:57 <aveiga> sc68cal: AI me to cover private network addressing cases on the ML, please
14:54:58 <rtuttle1015> how about a short-list of the most important use cases
14:55:09 <sc68cal> #action aveiga cover private network addressing cases on the ML
14:55:10 <aveiga> and then we can table this to the ML, since we're running out of time
14:55:17 <rtuttle1015> these are the ones we will allow, and then drop all others with error to user
14:55:55 <baoli> Can someone help me with my second question?
14:55:55 <aveiga> rtuttle1015: I want to avoid that
14:56:04 <aveiga> that's why we're stuck with broken SLAAC today
14:56:19 <shshang> aveiga, your points about post configuration change are valid. I don't have answer right now. But I believe we can find a solution/workaround jointly.
14:56:26 <rtuttle1015> but we can't boil the ocean, and certainly can't address "unknown" use cases
14:56:27 <aveiga> baoli: if there's a v6 subnet on the network, they get v6
14:56:29 <aveiga> that's simple
14:56:38 <rtuttle1015> so let's allow those we know, drop all others (for now)
14:56:46 <baoli> aveiga, thanks.
14:56:55 <aveiga> rtuttle1015: agreed, but I'd rather err on allowing them even if they aren't considered "valid"
14:57:10 <aveiga> better to let a guilt man go free then put an honest one in prison, no?
14:57:33 <aveiga> if we want a WARN: in the logs, I'm ok with that
14:57:36 <rtuttle1015> so what you're really saying is drive the error checking down to the agent (network node), spit a log silently and then go debug later
14:57:37 <shshang> How are about we document them, so user at least have a reference of the limitation?
14:57:44 <aveiga> rtuttle1015: yes
14:57:50 <rtuttle1015> I don't like that
14:57:53 <aveiga> shshang: I will, hence the AI
14:58:02 <rtuttle1015> makes network node do unnecessary work
14:58:11 <rtuttle1015> checking should be on neutron-server
14:58:30 <aveiga> but it makes unkown cases possible instead of requiring someone to rewrite code to compensate
14:58:50 <shshang> sc68cal, can we make sure this topic will be in next week's agenda? We need to reach consensus.
14:58:56 <aveiga> agreed
14:58:59 <rtuttle1015> +1
14:59:02 <aveiga> in any case, I need to drop for another meeting
14:59:19 <aveiga> see you all on the ML
14:59:22 <aveiga> o/
14:59:27 <shshang> LOL
14:59:32 <shshang> yah, we only have 1 min left
14:59:33 <sc68cal> shshang: yeah we'll recap it next week based on the mailing list convo
14:59:37 <shshang> Yup
14:59:39 <shshang> will do
14:59:42 <sc68cal> Alright everyone
14:59:51 <shshang> aveiga, thank you for your points
15:00:00 <sc68cal> thanks for joining, we'll reconvene next week
15:00:04 <sc68cal> #endmeeting