14:00:08 <sc68cal> #startmeeting neutron_ipv6
14:00:09 <openstack> Meeting started Tue May 20 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:12 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:25 <xuhanp> hello everyone
14:00:40 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_May_20th Agenda
14:00:55 <sc68cal> #topic blueprints
14:01:22 <aveiga> o/
14:01:33 <sc68cal> Firstly, thank you everyone who attended the summit and the design summit session - we had some good discussions
14:02:06 <sc68cal> #link https://etherpad.openstack.org/p/neutron-ipv6-atlanta-summit Design summit etherpad
14:03:02 <sc68cal> We had some good discussions about some of the blueprints that are on our roadmap - it was also nice to meet everyone in person
14:03:32 <aveiga> +1 - it was good to put faces to nicks
14:04:22 <Shixiong> yah, glad to meet with everybody in person
14:04:34 <baoli> hi
14:05:04 <baoli> it's great to see everyone in the summit
14:05:21 <xuhanp> Oh. I feel sorry for missing that :-) Really hope I can meet you all sometime.
14:06:41 <sc68cal> So one of the things that came up at the summit was doing tempest tests
14:07:13 <sc68cal> I currently have filed a couple blueprints for Tempest for testing the attributes
14:07:48 <dane_leblanc> Those are API tests, rather than scenario tests?
14:07:55 <aveiga> they have to be for now
14:08:01 <aveiga> since the functionality isn't implemented
14:08:11 <aveiga> we should do scenarios once the patches land
14:08:23 <sc68cal> +1 - currently API tests - scenario in the future
14:08:41 <sc68cal> SridharG filed a BP and both he and I have been adding patches linked to the bp
14:08:51 <sc68cal> #link https://blueprints.launchpad.net/tempest/+spec/ipv6-subnet-attributes Tempest IPv6 subnet attributes
14:09:09 <pcarver> I have a general question that goes well beyond IPv6. Are there test cases that run within a tenant VM to verify functionality?
14:10:21 <sc68cal> pcarver: I don't know to be honest. Probably worth asking in #openstack-qa
14:10:29 <dane_leblanc> There is a basic network scenario (connectivity) test that does pings and SSH to VMs
14:10:40 <pcarver> e.g (in an IPv6 context) testing that a couple of VMs can get spun up and can reach each other on their IPv6 interfaces
14:10:55 <sc68cal> dane_leblanc: right but those tests are from controller -> VMs
14:11:00 <dane_leblanc> Oh, don't know if that will test v6 yet.
14:11:21 <dane_leblanc> Yes
14:11:23 <sc68cal> I think all the tests are from control node connecting to instance, not instance to instance, but I could be wrong
14:11:29 <pcarver> sc68cal: ok, researching that is on my (long) list of todos
14:11:56 <sc68cal> Also- the scenario that is currently used for Tempest relies on the L3 agent
14:12:22 <sc68cal> there is a blueprint for more advanced scenarios, and I am working on adding a scenario test that reflects the way we deploy Neutron in production
14:12:36 <sc68cal> #link https://blueprints.launchpad.net/tempest/+spec/neutron-provider-networking Tempest provider networking blueprint
14:12:57 <sc68cal> Mostly because that's the quickest way for me to start doing ipv6 tests in tempest, in our lab
14:14:18 <sc68cal> There is also some pieces that need to land in DevStack and devstack-gate. For example, the tempest API tests for the ipv6 subnet attributes will fail in the icehouse branch of neutron since they disaled the attributes
14:14:45 <sc68cal> So I am adding a config knob to tempest.conf to have those tests skip when running the icehouse job.
14:15:48 <sc68cal> Anyway that's the blueprints I have been working on between summit sessions. Does anyone have new BPs to discuss?
14:15:59 <xuhanp> sc68cal, I will restore my client code since I saw it's on the agenda
14:16:08 <baoli> shall we talk about the RA BP?
14:17:27 <sc68cal> I hesitate to discuss it, to be honest. My concern is that we will beg bogged down arguing the merits of a single ipv6 attribute vs. two attributes, when we struggled mightily to get the two attributes merged for Icehouse. But I won't stop people
14:17:47 <pcarver> sc68cal: no blueprints yet, and probably not for a while, but we've got several folks actively working on getting up to speed on current IPv6 status in OpenStack and figuring out what the gaps are for our use cases
14:18:12 <aveiga> I'm actually writing a BP right now for getting IPv6-only networks to have a flaoting IPv4 address
14:18:12 <sc68cal> #link https://review.openstack.org/#/c/92164/ "Add IPv6 RA support in neutron"
14:18:20 <aveiga> not posted yet though
14:18:33 <dane_leblanc> I've started on the design spec for multiple v6 prefix per port.
14:18:59 <baoli> sc68cal, that's fine. But the openstack implementation for the two attributes seem to have a long way to go get reviewed.
14:19:02 <aveiga> dane_leblanc: thank you, as that will be a prereq for getting floats to work
14:19:28 <dane_leblanc> I've got a basic question re. if multiple subnets belong to a network, and port is created, how many subnets/prefixes should get assigned?
14:19:40 <sc68cal> ok - let's hang on to questions till open discussion
14:19:51 <dane_leblanc> sc68cal: Okay.
14:20:58 <sc68cal> OK - so we have baoli's bp that is posted, so please feel free to review - aveiga you said yours is WIP, and dane_leblanc is that the case as well?
14:20:58 <baoli> sc68cal, your BP to calculate SLAAC addr in neutron in the case of provider SLAAC is still under review
14:21:05 <Shixiong> dane_leblanc, if you need anything, feel free to let me know
14:21:22 <dane_leblanc> shixiong: Thanks! :)
14:21:52 <Shixiong> It will be critical for us to work together, so the way IP address is assigned maintain consistent between single subnet and multiple subnets.
14:22:07 <sc68cal> if you guys have any of them in gerrit let me know so I can add links so they apppear in the minutes
14:22:07 <Shixiong> btw, seemed like you survived through the race. :D
14:22:29 <dane_leblanc> shixiong: yes, survived. :)
14:22:50 <sc68cal> baoli: yes - it is still under review
14:23:07 <sc68cal> #link https://review.openstack.org/#/c/88043/ IPv6 provider networks
14:23:27 <baoli> sc68cal, one thing I want to mention is that there are a few methods out of there to generate the interface ID
14:23:28 <xuhanp> sc68cal, before the summit, you mentioned we should split shixiong's code into several commits? is that still the plan?
14:23:58 <baoli> sc68cal, modified eui64 is just one of those methods
14:23:59 <sc68cal> xuhanp: Yes - I mentioned it to Shixiong at the summit as well
14:24:09 <aveiga> baoli: this came up already at the summit
14:24:25 <aveiga> it's very difficult to programmatically support them all, and some are impossible
14:24:38 <aveiga> if you'd like to submit a patch to support mod-EUI64, please do
14:24:49 <aveiga> we currently only support EUI64
14:25:07 <baoli> aveiga, I thought that sc68cal's bp is doing do. I might be wrong
14:25:16 <baoli> s/do/that
14:25:28 <aveiga> it only supports plain EUI64 right now
14:25:42 <baoli> aveiga, thanks.
14:26:11 <baoli> aveiga, another thing, what we do if it's provider dhcp?
14:26:27 <aveiga> same thing we do in IPv4 - nothing
14:26:36 <aveiga> unless you want to suggest sniffing the neighbor table
14:26:41 <sc68cal> also we wait for someone to have the usecase :)
14:26:51 <sc68cal> and figure out if we need to change anything
14:26:57 <aveiga> in which case we should propose that as a whole to neutron in general, for v4 as well
14:27:28 <aveiga> it's doable if we have the l3 agent running
14:27:38 <sc68cal> I'm going to try and get through the rest of the agenda quick to give you guys half an our for open discussion - so bear with me
14:27:39 <aveiga> it's more complicated though for an l2-prov net
14:27:41 <Shixiong> dane_leblanc, who is that gentleman from Cisco who used to work on Dashboard?
14:27:41 <aveiga> but doable
14:27:49 <baoli> aveiga, sc68cal, I thought we should have some idea how to support them.
14:28:07 <aveiga> baoli: let's table it for open discussion
14:28:13 <aveiga> there are bugs and such to cover
14:28:21 <sc68cal> #topic code review
14:28:29 <dane_leblanc> shixiong: Abishek, but don't know his IRC handle
14:28:47 <sc68cal> xuhanp: thanks for the heads up on restoring the patch. I'll ping Mark to remove his -2
14:28:52 <baoli> sc68cal, thanks for your review on the snat bug
14:29:05 <Shixiong> Ok, thanks. I think we need to involve him too, so he can continue the work on Dashboard
14:29:07 <xuhanp> sc68cal, yes. I saw your note in the review.
14:29:40 <sc68cal> #link https://review.openstack.org/88584 Install SNAT rules for ipv4 only
14:29:46 <sc68cal> baoli: no problem
14:30:05 <xuhanp> sc68cal and Shixiong, BTW, we are testing Shixiong's patch in our lab recently, so let me know if I can help with splitting the dnsmasq big patch.
14:30:26 <xuhanp> And we found some problems with that patch :-)
14:30:29 <Shixiong> Sure, thanks, xuhanp
14:30:39 <Shixiong> Oh, yah, bring it up, I would love to fix the problem. :D
14:30:50 <Shixiong> Btw, I spent a lot of time with your boss in the Summit, :D
14:31:23 <xuhanp> Shixiong, I will post the comment in your code review.
14:31:35 <Shixiong> Please, thanks a lot, xuhanp!
14:31:47 <xuhanp> Shixiong, you are welcome
14:32:12 <sc68cal> #link https://review.openstack.org/#/c/70649/ dnsmasq patch that needs to be split
14:32:47 <sc68cal> any other code reviews?
14:33:41 <sc68cal> #topic bugs
14:33:54 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 bugs tagged with ipv6
14:34:31 <sc68cal> anything to discuss in bugs, or is everyone ready for open discussion
14:35:14 <sc68cal> alrighty - thanks everyone for being patient
14:35:19 <sc68cal> #topic open discussion
14:37:32 <dane_leblanc> I have a basic question re. multiple prefixes per port, if there are no other topics.
14:38:18 <sc68cal> sounds good to me - thank you for your patience
14:38:20 <dane_leblanc> Question is, if multiple subnets belong to a network, and a port is created, which subnets/prefixes should be associated by default?
14:38:41 <dane_leblanc> v4 model is that one subet is selected, and then others can be updated.
14:39:33 <sc68cal> I'd assume an IP from each subnet that is linked to the network in the neutron API
14:39:36 <dane_leblanc> I think this makes sense for v6, although I'm not sure which of a list of subnets should be chosen first.
14:39:47 <baoli> dane_leblanc: one way is to allow all the v6 subnets, assuming that's what the user intended.
14:40:14 <Shixiong> very good question
14:40:16 <aveiga> I'm trying to understand the use cae for not just getting one of each
14:40:26 <dane_leblanc> If all v6 subnets are allowed, how can a user enable a given prefix on a subset of VMs?
14:40:27 <aveiga> if you assigned a subnet to a network, I assume you want to use it?
14:40:55 <aveiga> there's no attribute I know of for selectively enabling per-vm
14:41:01 <dane_leblanc> Let's say a user wants some VMs that don't have a public (globally addressable) prefix
14:41:23 <aveiga> I think the issue there is that you'd have assumed topological reachability where it doesn't exist in practice
14:41:33 <aveiga> so they don't provide a method for this
14:42:24 <dane_leblanc> If that scenario makes sense, then we'd want to let's say disable SLAAC prefix assignment on some VMs
14:42:49 <baoli> dane_leblanc, that's a good question. So the question is how a neutron subnet is created, which is not associated with a neutron network, and you can get ips from it that can be assigned to some VMS
14:43:06 <aveiga> what you're asking for isn't selective subnets, it's flaoting IPs
14:43:29 <aveiga> going the other way, you'd setup a subneet for floating IPs for IPv6, and only assign to some hosts
14:43:50 <aveiga> selectively doing slaac would mean a multicast filter per port
14:44:04 <aveiga> which breaks RFC, and may also break regular v6 rachability
14:44:11 <aveiga> since neighbor solicits would also be blocked
14:44:16 <dane_leblanc> aveiga: Yes, this is looking towards floating-ip-like support.
14:44:30 <aveiga> so instead of selectively filtering subnets, why not just work on floating IPs?
14:44:36 <aveiga> I have some ideas in mind
14:44:39 <baoli> aveiga, the name of floating ip in IPv6 would be confusing.
14:44:53 <sc68cal> baoli: I disagree
14:45:04 <sc68cal> I think it's a decent openstack-ism
14:45:19 <sc68cal> I mean AWS has "elastic IP addresses"
14:45:20 <aveiga> we'd still doa  float, just not with NAT
14:45:31 <aveiga> it would be done via unicasted RA or a routed IP
14:45:34 <baoli> sc68cal, those are coined for ipv4
14:45:47 <pcarver> baoli: I disagree as well. I'm not an IPv6 guru, nor a huge fan of NAT but I don't see anything wrong with floating IP as a concept that applies equally to v4 and v6
14:45:56 <sc68cal> true - but the principle is the same - IPs that can be rapidly allocated to instances
14:46:15 <baoli> sc68cal, in that sense, I agree.
14:46:31 <aveiga> yes, it would not be via NAT
14:46:38 <sc68cal> just so happened in v4 land it's through nat - bleeech :)
14:46:43 <aveiga> we would do floats as an extra addr
14:46:53 <dane_leblanc> What might be confusing is that the v4 floating ips are public, where with v6 the prefixes we get by default are public
14:46:55 <Shixiong> aveiga and dane_leblance, by using floating ipv6 address, the VM needs to be associated with the pool, but not the subnet, in order to support the use case Dane mentioned, right?
14:47:08 <aveiga> either a second IA_NA in the Advertise, or unicasted RA
14:47:12 <aveiga> and static route to /128
14:47:35 <aveiga> do an RA for the float net, but set A and M to 0
14:47:55 <aveiga> another BP I want to submit if I ever get the time
14:48:37 <Shixiong> this is another question from my side. Usually the unicast RA is sent as response to RA solicit msg. Can we unwillingly initiate unicast RA to the VM without solicit msg?
14:48:47 <aveiga> sure
14:48:51 <Shixiong> If so, what VM is going to do with it?
14:48:54 <aveiga> we have to write the packet ourselves though
14:48:59 <baoli> shixiong, yes
14:49:04 <aveiga> it's still an RA, it should just accept it
14:49:16 <baoli> aveiga, the radvd supports unicast RA
14:49:21 <aveiga> yup :)
14:49:33 <aveiga> this is why I had been suggesting using radvd in the wrouter namespace before
14:49:33 <Shixiong> Does IPv6 stack on VM side will do check and realize it is not the response to its own solicit msg?
14:49:36 <Shixiong> and drop it?
14:49:36 <aveiga> I had plans ;)
14:49:53 <aveiga> Shixiong: the RFC doesn't require that
14:49:58 <baoli> aveiga, the RA BP would like to address that as well
14:49:59 <aveiga> and I think we can file bugs where that happens
14:50:19 <aveiga> s/wrouter/qrouter
14:50:25 <Shixiong> I see, this will be very interesting method
14:50:27 <Shixiong> I like it
14:50:46 <aveiga> it makes it easy to inject at will, and remove at will by setting the preferred and valid lifetimes low
14:51:11 <Shixiong> True. I have been thinking about it since last time we discussed it.
14:51:22 <Shixiong> Now the question is, when will we implement it? :D
14:51:22 <baoli> aveiga, yes
14:51:39 <aveiga> Shixiong: as soon as I get 5 min to myself to write out the BP :)
14:51:42 <baoli> the RA BP would pave the way for it to be implemented
14:51:48 <Shixiong> LOL
14:51:55 <aveiga> baoli: I don't see a reason why the existing BP would block it
14:52:08 <Shixiong> Do you guys know whether dnsmasq has the same feature to send unicast RA?
14:52:31 <baoli> aveiga, it just that the BP is trying to address that in a whole
14:52:41 <sc68cal> markmcclain had a interesting idea that he talked with aveiga nad I about on that note
14:52:47 <Shixiong> if the dependancy is on RADAD, then somebody wants to write the driver for RADAD first?
14:53:11 <aveiga> Shixiong: no need to rewrite, since dnsmasq still needs to do dhcpv6
14:53:13 <dane_leblanc> Maybe someone can help me here: comparing v6 to v4, SLAAC (public) is similar to float IPs, ULA (private) is similar to fixed IPs, so in Openstack, the public/private assignments would happen in reverse?
14:53:18 <aveiga> we need an extra set for radvd in qrouter
14:53:21 <baoli> The BP doesn't depend on RADVD. But the implementation would start with radvd
14:53:37 <sc68cal> dane_leblanc: fixed IPs is  sort of a carry over from nova
14:53:45 <aveiga> dane_leblanc: nope, slaac is no different thatn DHCPv6, it's a way to add an addr to a port
14:53:57 <sc68cal> the way nova was structured, you *had* to do NAT
14:54:08 <Shixiong> aveiga, if dnsmasq can send unicast RA, then we can continue working on it. If not, and we have to use RADAD, then we need to add driver, right?
14:54:14 <aveiga> for us, fixed IPs are already public
14:54:26 <aveiga> adding a float would be a way to do a reserved, semi-static public
14:54:35 <aveiga> that you can shuffle around
14:54:43 <aveiga> for instance, as a VIP for an haproxy instance
14:54:56 <dane_leblanc> aveiga: Thanks for the clarification.
14:55:09 <aveiga> Shixiong: yes, or we can write a python RA generator
14:55:13 <aveiga> RAs are damned simple
14:55:22 <aveiga> they're completely stateless, too
14:55:45 <Shixiong> agree, just want to make sure we don't reinvent the wheel if something already exists
14:55:53 <aveiga> +1
14:56:03 <aveiga> just worried about adding another dep
14:56:35 <sc68cal> yeah we talked with markmcclain about it
14:56:57 <sc68cal> if it's small, it's worth looking into
14:57:07 <Shixiong> he said he would code this part during his business trip, not sure what's the outcome.
14:57:11 <baoli> just want to mention that nova networking uses radvd
14:57:36 <aveiga> o.O
14:57:41 <aveiga> I was unaware that nova had v6
14:58:05 <Shixiong> I like this o.O
14:58:09 <baoli> all that radvd does is from the RFC, pretty standard. So it can be replaced with any other implementation
14:58:15 <aveiga> that's my raised eyebrow
14:58:52 <sc68cal> Does nova still create a column in the database for each IP when you create a network via the nova api? Anyone allocate try allocating a /64?
14:59:10 <sc68cal> column...jeez
14:59:11 <sc68cal> row
14:59:17 <aveiga> try allocating a /48
14:59:21 <aveiga> watch your DB cry
14:59:47 <baoli> sc68cal, aveiga, the first ipv6 experiment I had was using nova
14:59:59 <Shixiong> btw, sc68cal, I saw some errors when I run the patch to insert two attributes to DB in Icehouse release
15:00:36 <Shixiong> do u want me to send the logs to you?
15:00:57 <sc68cal> do you mean when you try and apply the patch?
15:01:18 <Shixiong> yah
15:01:32 <Shixiong> No worry. I can email u offline.
15:02:13 <sc68cal> Icehouse has the patch already
15:02:32 <sc68cal> they just added another change to disable the attributes in the REST API
15:02:46 <bauzas> sc68cal: are you close to the end of the meeting ?
15:02:53 <sc68cal> bauzas: yep sorry
15:02:58 <sc68cal> alright everyone, till next week
15:03:03 <sc68cal> #endmeeting