13:59:31 <sc68cal> #startmeeting neutron_ipv6
13:59:31 <openstack> Meeting started Tue Sep  2 13:59:31 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:36 <openstack> The meeting name has been set to 'neutron_ipv6'
14:01:50 <sc68cal> The only thing I have for discussion today is the progress on the Horizon patch, so if anyone else has things they'd like to discuss please do!
14:03:15 <xuhanp> sc68cal, do we need to change our meeting time since the WL meeting will start next week?
14:03:41 <sc68cal> xuhanp: are they starting next week? I was under the impression is was going to be after the summit?
14:04:18 <xuhanp> I think I saw one email today saying so but not 100% sure
14:04:32 <sc68cal> yep, you are right. Just looked at the ML
14:05:33 <baoli> xuhanp, what is the WL meeting?
14:05:43 <xuhanp> sorry, typo.
14:05:49 <xuhanp> the weekly neutron meeting
14:07:28 <baoli> xuhanp, I see. thanks.
14:07:53 <xuhanp> so I guess we will need to change time if we still want IPv6 meeting to be hold?
14:08:09 <sc68cal> I was going to wait to the summit, but lately I wonder if the subteam and meeting needs to continue - we've got a lot of things done this dev cycle, and we had a lot of consensus to build. Perhaps with the work we've gotten in, it may not need to be a weekly meeting in the future?
14:09:37 <BrianB__> I think a weekly meeting is still good
14:10:09 <xuhanp> I think it will be great if we have a meeting to discuss what's the next steps
14:10:54 <HenryG> How about moving it one hour earlier?
14:11:16 <baoli> it will be conflicting with sr-iov meeting which I need to attend
14:11:25 <BrianB__> HenryG:that conflicts with sr-iov
14:11:37 <sc68cal> I'm glad people want it to continue - I'll keep running it as long as people attend :)
14:12:05 <xuhanp> how about one hour later?
14:12:15 <xuhanp> it's good to keep meetings at one day
14:12:45 <sc68cal> I'm ok with an hour later... although that's pretty brutal for you xuhanp?
14:12:59 <xuhanp> that's fine for me too :-)
14:13:05 <baoli> that sounds good to me
14:13:19 <sc68cal> yeah the upside is it gives the US west coast people a break ;)
14:14:34 <sc68cal> Let me just see if we conflict with anything at 1500 UTC
14:14:37 <xuhanp> if there is no room for this time in openstack-meeting or openstack-meeting-alt, there is openstack-meeting-3
14:15:08 <sc68cal> xuhanp: cool, thanks for checking.
14:15:36 <sc68cal> hmm
14:16:02 <sc68cal> oops, no that's thursday
14:16:49 <sc68cal> ok, so openstack-meeting-3 on tuesdays at 1500UTC?
14:17:24 <sc68cal> I'll put something on the ML to let everyone check and make sure that works
14:17:32 <aveiga> sounds good
14:17:33 <xuhanp> sounds great
14:18:19 <sc68cal> xuhanp: I saw you still had some q's from the HA thread on the ML?
14:18:29 <xuhanp> yep.
14:18:51 <baoli> actually, it seems that tuesdays utc1500 is open on openstack-meeting-alt
14:19:04 <xuhanp> but I just left a new thought today. so I guess I will leave some time for everyone to check it out.
14:19:51 <baoli> xuhanp, right now, the garp is sent to router ports, gateway port, etc.
14:19:55 <sc68cal> Hmmm - I think I found a bug in the mailing list software
14:19:57 <sc68cal> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044340.html
14:20:18 <baoli> xuhanp, for vrrp to work, would it make sense for it to send the garp to the ports that are configured for vrrp?
14:20:18 <sc68cal> That e-mail is from xuhanp but it has aveiga as the from in the archive.
14:20:49 <aveiga> sc68cal: nice catch, as I didn't send that
14:20:56 <xuhanp> sc68cal,  you should search for Sep 1
14:21:00 <xuhanp> I sent it today.
14:21:12 <sc68cal> ah ok,
14:21:13 <sc68cal> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044602.html
14:21:22 <xuhanp> that one should came from aveiga, only he is replying inline so mixed with mine
14:21:36 <aveiga> I think the issue at hand should really be which method(s) do we want to support for HA
14:21:45 <aveiga> do we want VRRP? Do we just want standby RAs?
14:21:54 <aveiga> do we want options?
14:22:24 <sc68cal> I know there is some work for vrrp in Neutron - I'd have to do research
14:22:35 <xuhanp> in the latest code of L3 HA, when HA is enable, keepalived is used to send out GARP. When is not, GARP is sending out by neutron code.
14:22:43 <xuhanp> just checked today.
14:23:04 <aveiga> xuhanp: is that using VRRP for IPv4?
14:23:12 <aveiga> and is that the only mode supported?
14:23:43 <xuhanp> I think so since there is no special treat for IPv6.
14:23:52 <xuhanp> although keepalived supports IPv6 VRRP
14:23:57 <baoli> xuhanp, I think that we need to separate the discussion between garp on router ports, and garp on gateway port
14:24:01 <aveiga> ok, so the question is do we want to do just VRRP for IPv6?
14:24:26 <xuhanp> baoli, right.
14:25:05 <xuhanp> aveiga, I think we need to support HA like IPv4, but it's debatable if VRRP is used.
14:25:19 <xuhanp> I just use that as an example of not using two LLA for subnet
14:25:22 <aveiga> xuhanp: I don't question the need for HA, just asking about the methods
14:25:31 <aveiga> and yes, that makes it easier
14:25:34 <aveiga> having only one LLA
14:26:08 <xuhanp> since keepalived with VRRP is used for IPv4, I think it's convenient to use for IPv6
14:26:18 <aveiga> I agree
14:26:32 <baoli> xuhanp, the point I want to make is that garp for router port should be controlled by the higher prototol.
14:27:12 <xuhanp> baoli, so do you understand why currently GARP is used for IPv4 routers?
14:27:22 <xuhanp> I am confused by that part from the beginning
14:27:43 <baoli> xuhanp, garp for the gateway port is for NAT, I believe, but garp for the router ports, I'm 100% sure.
14:28:01 <baoli> sorry, not 100% sure
14:28:18 <xuhanp> I thought it's for bridge learning
14:28:34 <xuhanp> since the router node changed
14:28:44 <xuhanp> we need to update the learning table cache
14:29:32 <baoli> xuhanp, yes, that's possible for quick convergence. But the VM sends ARP anyway
14:30:15 <xuhanp> VM don't need to update ARP if the router IP is not changed, right?
14:30:29 <aveiga> xuhanp: has the MAC changed?
14:30:40 <xuhanp> in VRRP, no. The virtual MAC is used.
14:30:45 <xuhanp> but in other case, maybe
14:31:26 <baoli> xuhanp, so router ports' ip address changed but mac remains unchanged, it maybe a good thing to send garp, I guess.
14:31:37 <baoli> right now, it seems to be sending it regardless.
14:31:51 <aveiga> baoli: is it harming anything to send it?
14:32:12 <aveiga> at the worst, you get a packet that confirms what you already know
14:32:19 <aveiga> at best, it reconverges on the proper gateway
14:33:25 <baoli> aveiga, I don't think it hurts anything
14:33:37 <xuhanp> maybe we should talk to the HA code owner to understand more.
14:33:58 <xuhanp> I see the code change around GARP in the HA code.
14:34:53 <xuhanp> If there is a gap to support IPv6 HA, we can fix that.
14:36:12 <baoli> xuhanp, maybe it's worthwhile to see the packets while RA is enabled on a router port. We can better understand if garp is needed for router port for ipv6
14:37:01 <xuhanp> baoli, if we go that way, then there will be two LLA when router failover.
14:37:17 <xuhanp> VM need to switch to the backup's LLA as route
14:37:47 <xuhanp> In VRRP, the previous LLA is used.
14:38:36 <baoli> xuhanp, I'm still thinking about normal case. For HA, I'm thinking that keepalived will do the right thing.
14:38:53 <xuhanp> baoli, OK
14:38:56 <aveiga> baoli: yeah, VRRP is fine and normal case will judst need a new RA
14:39:02 <aveiga> need to keep valid lifetimes low though
14:39:58 <baoli> aveiga, good point.
14:40:48 <xuhanp> aveiga, I think too low increases the overhead?
14:41:04 <aveiga> xuhanp: it does, but too high means outages during failover
14:41:14 <xuhanp> exactly
14:41:15 <aveiga> it's a tradeoff
14:41:31 <aveiga> but RAs aren't that expensive
14:42:25 <xuhanp> aveiga, so you are saying since failover causes the new router to send out RA anyway, we don't need additional steps here?
14:42:43 <aveiga> xuhanp: if you're triggering the standby to become active
14:42:50 <aveiga> it will have to send RAs anyway to be a router
14:42:53 <aveiga> so yeah
14:43:03 <aveiga> we should spin up radvd on it and fire away
14:43:28 <xuhanp> so we need the VM to wait for the last RA to expire and receive the new one?
14:43:37 <xuhanp> and change it's route to the new LLA?
14:43:57 <aveiga> xuhanp: that depends on the guest, sadly
14:44:08 <aveiga> some of them will take the new RA immediately
14:44:34 <aveiga> some might need to wait for the timeout
14:44:42 <baoli> it's also possible to deprecate the old RA by sending its lifetime to be 0
14:44:56 <aveiga> baoli: spoof send it?
14:45:15 <aveiga> we'd haveto have the failover router send it from the old router's LLA
14:45:17 <xuhanp> the old route is already dead, so how to do it.
14:45:50 <xuhanp> then it falls into the VRRP way.
14:46:02 <xuhanp> in VRRP the new router just send out the old LLA in RA
14:46:25 <aveiga> xuhanp: we're talking about a non-VRRP mode
14:46:39 <xuhanp> yes. but we are making the process more and more like VRRP process
14:47:03 <xuhanp> since it's invented to solve the same problems here
14:47:30 <aveiga> xuhanp: this would potentially let you go to DVR on the fly though :-P
14:47:48 <xuhanp> :-)
14:47:49 <aveiga> just spin up all the local gateways and take over the RA :)
14:49:15 <aveiga> so this is a good conversation and all, but is any of this work tied to  a specific blueprint with a timeline?
14:49:36 <xuhanp> no. it's triggered by a bug
14:49:42 <xuhanp> since ARP doesn't work for IPv6.
14:49:43 <aveiga> ah, ok
14:50:18 <baoli> xuhanp, so are we saying that garp on router port will be taken care of by the higher level protocol? In other words, l3 agent doesn't need to send garp blindly.
14:50:38 <baoli> for ipv6
14:50:43 <xuhanp> for IPv4 I think that's useful
14:50:47 <aveiga> well, there's no garp for v6
14:50:51 <xuhanp> but for IPv6, seems not
14:50:55 <aveiga> so it's either a new RA or unsolicited NA
14:51:02 <xuhanp> yep
14:51:06 <baoli> aveiga, that's what I mean.
14:51:08 <aveiga> if it's an RA< then radvd does it normally
14:51:17 <aveiga> if it's NA, then we have to manually craft the packet
14:51:32 <xuhanp> unsolicited NA is useful if the LLA is not changed.
14:51:47 <xuhanp> it will have the same benefit as GARP.
14:51:56 <aveiga> if the LLA is not changed, then why do we need anything?
14:52:06 <aveiga> the MAC and the LLA aren't changing, so the route should still work
14:52:18 <aveiga> the DAD packet will update the switches
14:52:21 <xuhanp> the port could changed, so we need that for switch learning?
14:52:32 <xuhanp> that's my thoughts not 100% sure
14:53:03 <aveiga> unless we aren't waiting to instantiate the listener on the failover router
14:53:09 <aveiga> in which case, yes an NA is needed
14:53:18 <xuhanp> aveiga, yes.
14:54:33 <xuhanp> if LLA is changed, the unsolicited NA is useless after all, right?
14:55:12 <aveiga> if LLA is changed, then a new RA is required
14:55:17 <xuhanp> yep
14:55:20 <aveiga> which will cover for the NA as well
14:56:15 <xuhanp> I can leave these comments in code review and see other's opinions
14:56:27 <aveiga> +1
14:56:52 <baoli> xuhanp, there is ra dump facility you can use to see what would happen with the scenairos you mentioned, also tshark can help find out the packets sent to the network
14:57:17 <xuhanp> baoli, good to know. I will try that.
14:57:43 <baoli> xuhanp, that will help figured out if NA is needed
14:58:07 <xuhanp> baoli, ok
15:00:20 <sc68cal> Cool stuff everyone
15:00:23 <sc68cal> thanks for coming!
15:00:33 <sc68cal> until next week!
15:00:36 <sc68cal> #endmeeting