21:01:11 <sc68cal> #startmeeting neutron_ipv6
21:01:11 <shshang> Hello, Sean
21:01:16 <openstack> Meeting started Thu Nov 21 21:01:11 2013 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:19 <openstack> The meeting name has been set to 'neutron_ipv6'
21:02:06 <sc68cal> OK - thank you everyone that has decided to attend
21:02:23 <sc68cal> The agenda is pretty straight forward
21:03:03 <sc68cal> My name is Sean Collins, and I work for Comcast
21:03:17 <shshang> Great to "see" you, Sean
21:03:19 <sc68cal> please feel free to introduce yourselves
21:03:52 <aveiga> I'm Anthony Veiga, IPv6 SME at Comcast
21:03:59 <shshang> My name is Shixiong. I used to work for Cisco, but recently joined a startup working on OpenStack and IPv6
21:04:11 <mestery> Howdy folks, Kyle from Cisco.
21:04:18 <shshang> Hi, Kyle
21:05:16 <sc68cal> I am mostly working with aveiga to get OpenStack Neutron to work with the networking environment we have set up at Comcast
21:05:50 <sc68cal> As such, we're busy creating bugs and blueprints to cover things that we need done right away, to make it work in our environment, as well as some blueprints that probably would be useful to the community as well
21:06:02 <sc68cal> #link https://bugs.launchpad.net/neutron/+bug/1252852
21:06:38 <sc68cal> hmm, not sure if that worked or not
21:06:49 <sc68cal> #link https://bugs.launchpad.net/nova/+bug/1251235
21:06:59 <sc68cal> #link https://bugs.launchpad.net/neutron/+bug/1242933
21:07:06 <ijw> evening ladies and gents
21:07:22 <sc68cal> hi ijw - welcome
21:07:26 <shshang> interesting...the 2nd bug explained what we saw before....
21:07:28 <carlp> o/
21:07:39 <mestery> sc68cal: Try #link <link> <description>
21:07:40 <ijw> Seen that first one, it's bloody annoying
21:07:43 <mestery> It will show in hte logs.
21:08:06 <sc68cal> #link https://bugs.launchpad.net/nova/+bug/1251235 ip6tables rules isssues
21:08:26 <shshang> for the first one, I think ip6tables also drops ND packets, if I am not mistaken
21:08:40 <ijw> Didn't when I tried it
21:08:43 <ijw> The second's very risky - need to source-filter your RAs
21:08:49 <aveiga> shshang: It does
21:08:53 <sc68cal> Yeah, that's due to the hairpinning on the bridge device
21:08:56 <ijw> (speaking as a man of much experience and bitterness with some muppet in the lab sending them out)
21:09:03 <sc68cal> #link https://bugs.launchpad.net/nova/+bug/1251235
21:09:16 <sc68cal> #link https://bugs.launchpad.net/nova/+bug/1251235 hairpinning issue for DAD
21:09:22 <sc68cal> sorry, still getting used to this :)
21:09:32 <shshang> is there any workaround for the 2nd bug?
21:09:56 <sc68cal> shshang: for the hairpin?
21:10:02 <shshang> yup
21:10:07 <aveiga> the workaround we're using currently is a very painful and manual process to disable hairpinning on the tap
21:10:09 <shshang> I had to manually disable DAD
21:10:11 <sc68cal> shshang: yeah, I have a patch to nova that's in review
21:10:12 <shshang> on guest VM before
21:10:28 <sc68cal> should be linked in the bug report
21:10:55 * haleyb never knew about the -alt channel until today
21:11:02 <shshang> I see. Thanks for bringing it up
21:11:10 <sc68cal> Basically this stuff I've filed has been for our immediate goal, getting IPv6 networks that we have existing outside of openstack, to work with OpenStack the way provider networks does on the v4 side
21:11:34 <sc68cal> Obviously, IPv6 has some differences, since OpenStack wants to be the source of truth for things like subnets
21:11:57 <sc68cal> and that's where we're running up against issues, where OpenStack gets confused and creates ip6tables rules for ::/128 in the security group rules
21:11:58 <aveiga> we should consider a longer term roadmap of the parts of IPv6 that we need to get working
21:12:05 <sc68cal> aveiga: +1
21:12:15 <shshang> agree
21:12:18 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac
21:12:31 <shshang> #agreed
21:12:47 <sc68cal> That's a blueprint I'm trying to collect all my immediate work, to get IPv6 running inside OpenStack
21:13:10 <shshang> There is a hacking way to make dnsmasq to announce RA
21:13:14 <ijw> I don't think you'll be able to determine how routers should work in an hour long IRC meeting, to be honest...
21:13:14 <shshang> but it is quite a hassle
21:13:14 <aveiga> What I want to make sure we don't do is be blinded by individual goals.  I realize there are many people who want IPv6 that aren't necessarily keen on it being done via l2-provier
21:13:48 <aveiga> so that said, we've already got IPv6 via l2-provider/slaac as one implementation
21:14:00 <aveiga> are there others that should be looked at for immediate needs?
21:14:05 <sc68cal> We also want to extend DNSmasq so that you can do things like DHCPv6, create subnets on the v6 side and get things on par with the v4 side
21:14:07 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword
21:14:11 <ijw> What are you doing about antispoof with SLAAC?
21:14:27 <sc68cal> more long term
21:14:46 <aveiga> ijw: right now, nothing
21:15:06 <aveiga> however, I think the goal should be that when you create a subnet in an IPv6 SLAAC network, we should configure the router
21:15:18 <aveiga> and then use the router's information to populate the source list for RA inpouts
21:16:00 <shshang> @sc68cal, I am a little bit confused about the #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword
21:16:07 <aveiga> but again, we're in the baby steps mode right now of just getting it to work at a low level before implementing
21:16:20 <ijw> What I said about how long it'll take to decide that definitely applies.  Firstly, ipv4 routers don't advertise routes, but v6 ones do - so probably we should add a route-advertise flag on the network that both respect.
21:17:36 <sc68cal> shshang: what has you confused?
21:18:04 <shshang> if we only talk about SLAAC here, then the way it is coding today has capability to detect subnet type. And if subnet is IPv6, then trigger RA.
21:18:32 <shshang> However, if we talk about DHCPv6 and SLAAC, then yes, we need to provide options for user to define what they want
21:18:50 <ijw> I'm not sure you're allowed to assume that the link-local address is what the MAC suggests it is.
21:19:19 <aveiga> ijw: are you referring to privacy extensions?
21:19:47 <ijw> They don't apply to link local iirc
21:19:55 <aveiga> oops, missed that part
21:20:02 <shshang> agreed
21:20:09 <aveiga> what case would exist where the lla isn't EUI-64 derived?
21:20:10 <ijw> Trying to remember if link local is *required* to or *recommended* to be based on the link address.
21:21:25 <shshang> in my experiment, VM boots and it has linklocal address in any way. it doesn't need Openstack's help
21:22:24 <aveiga> I don't know that lla is relevant here
21:22:27 <shshang> the question here is, 1) How Openstack can send RA if we offer SLAAC 2) How OpenStack can store the SLAAC IPv6 address VM calculate
21:22:29 <aveiga> let's take a step back
21:22:38 <carlp> ijw: looks like it's required http://tools.ietf.org/html/rfc4291#section-2.5.6
21:23:31 <aveiga> shshang: We don't necessarily want OpenStack to issue the RA in all cases
21:23:43 <aveiga> just in cases where an l3 agent is the gateway
21:23:59 <sc68cal> Oh, I nearly forgot, Dazhao yu is working on a patch to do the calculations for EUI-64
21:24:05 <aveiga> most guests OSes ignore multiple RAs or ignore RA priority, and as such we'd blackhole them issueing RAs
21:24:16 <sc68cal> #link https://review.openstack.org/#/c/56184/ Calculate stateless IPv6 Addresses
21:24:33 <sc68cal> I think it just needs to be done against oslo, not neutron
21:26:05 <sc68cal> So, it's a bit of a info dump from what aveiga have been doing.
21:26:38 <sc68cal> There seems to be a lot of stuff where people have run into the same issues, but nothing seems to go back up into Neutron
21:26:52 <sc68cal> like hairpinning, etc.
21:27:35 <shshang> @aveiga, I can see your points in some setups.......is it a good approach to completely rely on external router?
21:27:45 <ijw> carlp - tehre's a few 'should' rather than 'must' in rfc2464 that leave it ambiguous
21:28:10 <carlp> ijw: true, but the diagram shows using the interface address which makes it seem like a must
21:28:35 <ijw> Yep, but how the interface address is calculated is where the 'should' comes in.  That's a 64 bit value, there are options on what you use for it.
21:28:41 <aveiga> ijw, carlp: The instances where it wouldn't don't make sense, because you'd have a MAC collision anyway
21:28:47 <carlp> ijw: ah, missed that. Sorry
21:29:05 <ijw> To be fair, we get to tell people what they should do to an extent.  Changing MACs in v4 gets you nowhere, too...
21:29:54 <carlp> aveiga: MAC addresses should be unique in openstack, too much depends on that for them not to be. Especially on the same network segment.
21:30:19 <aveiga> carlp: agreed, hence lla shuld be EUI-64 derived in all cases
21:30:22 <ijw> In this instance, we're adding the additional requirement that no-one tries to be smart about assigning ipv6 LLs, but that's fine
21:31:28 <sc68cal> I'm a bit short on action items, at least for community work
21:31:29 <mestery> So, it's 30 minutes in, just checking if people have settle on either some bugs or BPs they'd like to focus on.
21:31:33 <mestery> Icehouse-1 is in 2 weeks.
21:32:11 <sc68cal> aveiga and myself are working mostly on the slaac + provider networking, since that's our setup internally
21:32:35 <aveiga> I'm also working to get some Third OParty Testing cycles spun up for this too
21:32:55 <aveiga> but I can only really test the l2-provider model right now
21:33:11 <mestery> Both of those are solid. I think it makes sense to track that work as action items for next week.
21:33:22 <mestery> Is anyone else willing to sign up for any of hte other bugs discussed here?
21:33:37 <shshang> @aveiga: Is your setup completely using external router to send RA, right?
21:33:50 <aveiga> shshang: Yes.
21:34:11 <ekarlso> yo gang
21:34:24 <ekarlso> quick question, what's the plan to introduce ipv6 in neutrpn ?
21:34:32 <haleyb> mestery: is there a list of bugs?  i missed the first 10 minutes
21:34:40 <sc68cal> ekarlso: you'll have to read through the logs when we're done
21:34:46 <mestery> sc68cal may have that list
21:35:15 <sc68cal> it should appear in the log when we're done, but if not I'll e-mail the mailing list for good measure
21:35:17 <haleyb> ok, i only know of the two he has
21:35:34 <aveiga> I actually have about 3 more to post.  I'm a bit behind on my documentation
21:35:43 <ijw> sc68cal: so, just to confirm what your SLAAC stuff will leave us with - when you're done with your stuff, we're expecting VMs that assign themselves a global address appropriate to the subnet, right?
21:36:12 <jjmb> this is john brzozowski (jjmb), i run the ipv6 program at comcast - sean asked that introduce myself
21:36:27 <aveiga> ijw: We're expecting SLAAC to work normally as it would in any non-virtualized environment
21:36:35 <aveiga> again, this is for l2-provider models only
21:36:40 <sc68cal> ijw: Yes. Although the subnet is not inside openstack at this point
21:36:50 <aveiga> we should also get a blueprint to gether to bring DHCPv6 into the fold
21:37:25 <sc68cal> aveiga: I think the dnsmasq bp does cover that, though it could probably use better wording
21:37:51 <aveiga> then we should take that discussion in general to the mailing list and refine it
21:38:06 <sc68cal> ok
21:38:07 <aveiga> more needs to happen than just dnsmasq to get that bit working
21:38:30 <sc68cal> #action sc68cal discuss DHCPv6 support on the mailing list
21:39:42 <shshang> Can we discuss the big picture first, before we talk about bug fix?
21:39:54 <aveiga> please
21:40:11 <shshang> I am curious to see what approach we will take to tackle the IPv6 + Neutron issue
21:40:29 <shshang> something like the priority and dependancies
21:41:07 <aveiga> one of the key things required to get neutron to be ipv6-capable is for neutron to be able to derive, assign or retrieve the VM's IP address
21:41:18 <aveiga> that might be a good place to start
21:41:20 <shshang> agreed
21:41:27 <shshang> that is our goal
21:41:30 <shshang> or one of our goals
21:43:42 <sc68cal> aveiga: can I assign you a task of documenting our usecase?
21:43:56 <aveiga> sure, but let's link it to mailing list discussions
21:44:03 <aveiga> I don't claim to be omniscient
21:44:03 <sc68cal> ok
21:44:49 <sc68cal> #action aveiga document our immediate needs from Neutron, and open discussion on the mailing list
21:45:17 <shshang> How can we translate that to the blueprint?
21:45:19 <jjmb> do we want to include any phasing or future requirements?
21:45:23 <jjmb> ie a phased approach
21:45:30 <jjmb> or is this putting the cart before the horse?
21:45:42 <shshang> @jjmb, agreed
21:45:45 <aveiga> it might be better to gather them all and then prioritize them
21:45:54 <aveiga> perhaps based on the amount of responses from the mailing list
21:46:15 <sc68cal> #idea gather up requirements for immediate term, and log term
21:46:50 <jjmb> the immediate phase I would obviously need to be executed upon first...
21:47:17 <jjmb> however it might be useful for all to see and comment on what happens in future releases.  aveiga/sc68cal?
21:47:25 <ijw> As a basic sequence of events, it seems it's basic firewalling and L2 stuff to start (so that SLAAC works at least on provider networks) then we'll move on to RAs and then DHCP, I would think.  Longer term and more frightening is what routers actually *do* for v6, because it's not what they do for v4.  And a problem for both v6 and v4 is how multiple subnets on a network are supposed to be treated, I think - mestery, unless you know mo
21:47:48 <aveiga> Is there anyone interested in doing a neutron-wide code review looking for instances of addressing that are either cast as ints or pulled from IPv4-only calls?
21:47:54 <sc68cal> ijw: well put
21:48:17 <shshang> @ijw. That sounds like a plan already
21:48:20 <sc68cal> aveiga: most of the calls i've seen is through netaddr
21:48:23 <aveiga> ijw: you bring up a good point, since multiple networks on the same subnet isn't a problem in IPv6...
21:48:56 <sc68cal> which handles ip stuff - most is stored internally in the DB I believe for addresses
21:48:59 <ijw> aveiga: 'interested' would be a strong statement, but I think it needs doing.  We need to check the remaining bits of nova that neutron relies on too - and while we're at it can we please confirm that multiple subnets do work, and maybe even feed what we discover about operation to the docs people, because I don't think this is as well described as it should be
21:49:05 <sc68cal> *stored as strings
21:49:44 <aveiga> ijw: Yes, and I plan on filing a bug soon about this.  It turns out that if you even add an ipv6 subnet to a network with an IPv4 subnet, it disables the whole network
21:50:07 <shshang> aveiga, you are talking about the external network side?
21:50:10 <aveiga> Not sure about everyone else, but I don't want dual stack to require separate interfaces
21:50:13 <aveiga> shshang: yes
21:50:18 <ijw> Yeah.  Try not adding a subnet.  Havana's slightly different in that you get an error, but in Grizzly you got no interfae
21:50:19 <shshang> I have solution for you
21:50:31 <ijw> aveiga: 4, 46 and 6 should all work
21:50:42 <shshang> aveiga, we already made dualstack working on external network side
21:50:54 <aveiga> shshang: We did too, by not putting in a subnet at all
21:50:54 <shshang> v4, v6 on the same interface
21:51:11 <aveiga> we can compare notes outside this meeting though, as I don't want to take up time
21:51:13 <ijw> shshang: where's the review?
21:51:29 <shshang> we didn't publish the code yet, but we wrote a white paper
21:51:50 <ijw> Right.  Code review.  Volunteer?
21:51:59 <ijw> o/ (reluctantly, cos someone has to)
21:52:02 <shshang> aveiga, ijw, if you are interested, we can have a call to review it together
21:52:27 <ijw> shshang: bung it in gerrit as a WIP and mail the link around, we can comment on it there
21:52:27 <aveiga> actually, I'd prefer documentation and an email thread on the list
21:52:36 <sc68cal> ijw: +1
21:52:51 <sc68cal> shshang: can I put you down for an action on that item?
21:52:57 <shshang> ijw, that is a good idea, will do
21:53:11 <shshang> sc68cal, you mean, load code to github?
21:53:25 <sc68cal> #action shshang post code review & link on mailing list
21:53:37 <shshang> sure, I will do
21:53:39 <sc68cal> shshang: put it on gerrit and mark it as WIP
21:54:08 <shshang> aveiga, ijw, since this is my first time to post code, may need your help a little bit to make sure I did it right
21:54:13 <shshang> thanks in advance
21:54:25 <aveiga> I can help, but it will be my first time too shortly
21:55:13 <ijw> Might have more volunteers for the code review, if we can work out how best to file comments
21:55:29 <ijw> Also a checklist of issues to look for
21:55:42 <aveiga> I think I can finnagle jjmb into helping with that list
21:56:08 <aveiga> sc68cal: put me down for coming up with a list of gotchas that block IPv6
21:56:20 <sc68cal> ok
21:56:25 <aveiga> I can work with soem folks internally that already did this on other projects
21:56:36 <shshang> sc68cal, please put me down for gap list too
21:56:56 <sc68cal> ok, not sure if I can link multiple people to it
21:57:13 <sc68cal> should probably be shshang aveiga and ijw
21:57:19 <ijw> sc68cal: can you start a thread on the ML about what to look for?  And is there some way we can comment up the code on github or something similar?
21:57:49 <sc68cal> ijw: good question - probably the best thing to do is take notes then share on the mailing list
21:58:19 <aveiga> coming up on the end of the hour
21:58:35 <sc68cal> #action aveiga ijw shshang start code review looking for IPv4-isms
21:59:14 <sc68cal> Thanks everyone for coming, I'm going to get better at working with meetbot as we go along
21:59:19 <sc68cal> I promise :)
21:59:30 <shshang> thanks!
21:59:39 <sc68cal> Next week is pretty close to a holiday in the US, so we may reconvene the week after
21:59:58 <sc68cal> #endmeeting