21:00:01 #startmeeting neutron_ipv6 21:00:02 Meeting started Thu Dec 19 21:00:01 2013 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:05 The meeting name has been set to 'neutron_ipv6' 21:00:11 #topic housekeeping 21:00:22 So next week is a holiday week for some, so we're going to skip next week 21:00:50 The other thing is that we're trying to figure out a good time so we can get the people from IBM in China to attend 21:02:04 So everyone put in your 2c about the UTC time 21:02:05 So do we need to move later 21:02:07 ? 21:02:25 if we move later, the Europeans are out 21:02:27 either earlier or later, I think our current time has it at like 3AM or 4AM in china 21:02:29 yes 21:03:01 what about earlier? 21:03:17 I floated the idea of 1500 UTC 21:03:47 That at least puts it in the range of approachable for China, although it's pretty late their time I think 21:04:09 1500 UTC is like 9am EST? 21:04:12 yes, still late for them... could try for 1300 UTC?? 21:04:25 is that too early for you Sean ;-) 21:04:36 Randy__: I'm willing to make sacrificies 21:04:40 *sacrifices 21:04:42 1300 is 8AM EST, not that bad 21:04:48 I'll make sure Sean's awake 21:04:52 right 21:04:54 :) 21:05:13 #action sc68cal see if 1300 UTC works for everyone on the ML 21:05:30 #topic recap actions from previous meeting 21:05:39 ijw: ping? 21:06:10 there we go 21:06:32 ijw: you had an action to write up a blueprint for your ideal networking - is that google doc you created sort of part of that? 21:06:39 I thought ijw said he might not make this call 21:06:57 Yeah, the aim was to put that there and see what we already had. I think I've changed my opinion anyway 21:07:15 ok - do you have the link handy? 21:07:21 So I was saying that DHCPv6 would be the primary way of doing addressing because it's more general and SLAAC is very specific to /64s 21:07:38 But I grant you with all the feedback (a) SLAAC is going to be easier to implement and (b) we need both anyway 21:08:40 #link https://docs.google.com/document/d/1rOBOOu_OwixMStm6XJOb5PKkJA6eFbL_XCE7wlTfaPY/edit IPv6 addressing and routing in Openstack 21:08:49 Aside that, the doc lists in the first section the things we need - in terms of features, not implementations - and in the second section the APIs. I've tried to avoid implementation details in there completely. I'm working forward from what we need because it felt like everyone so far had gone with 'here's the code, what's the minimum we can do to make something work' and I wanted to make sure we'd covered everything 21:09:48 cool - we'll let people look over it and add feedback 21:09:56 sc68cal: I believe some of the subsequent agenda items might address some of these areas 21:10:08 Anyway, my take is that we want RAs from routers (with a degree of configuration) *and* DHCPv6, indepdendently, and in the DHCPv6 namespace as now. And we don't want them to all be tied back to a single config keyword on subnets, necessarily, because even if RAs are doing addressing there may be reasons to have a DHCP server 21:10:31 Randy__: agreed - we'll probably cover it in depth when we get to the blueprint topic 21:10:57 So for me - I registered two blueprints for the VIF hairpin attribute 21:10:59 ijw: +1, for cases of no RFC 6106 support in the client but a desire for SLAAC 21:11:19 #link https://blueprints.launchpad.net/nova/+spec/nova-hairpin-vif-attribute Nova VIF hairpin attribute BP 21:11:24 That approach is only a little different from Randy__'s POC - he moved dnsmasq, I'm saying we should duplicate it 21:11:34 #link https://blueprints.launchpad.net/neutron/+spec/vif-attribute-for-hairpinning Neutron VIF attribute 21:11:47 #topic blueprints 21:11:52 Ok - have at it folks :) 21:12:13 know people have some stuff to hash out on the v6 modes 21:12:21 Right, let's start with those two - there's nothing controversial there, I think we're just trying to make this easy for the Nova guys to see we're not breaking things 21:13:11 anyone have any qualms with the VIF hairpinning BPs? 21:13:17 if not, we could move on 21:13:41 is this tied to the issue we had before? 21:13:53 shshang: yes, this is to address the DADFAILED issue 21:14:01 I thought it has been fixed...no? 21:14:06 well, it was 21:14:12 Yeah, keeps coming up - it's just a problem to commit cos we have to get it past Nova reviewers who like the status quo 21:14:15 but the patch sc68cal proposed was rejected 21:14:26 I see. 21:14:29 they wanted it changed per VIF by Neutron 21:14:30 I am fine with that BP 21:14:33 hence those BPs 21:14:38 +1 for me 21:14:48 sounds like consensus to me 21:15:04 First is sc68cal's and I'll do the second 21:15:16 ijw: you want the neutron one or the nova one? 21:15:20 Neutrojn 21:15:22 k 21:15:35 You have a patch out in nova, you might as well just tweak it 21:15:37 #action sc68cal assign ijw to neutron vif blueprint 21:15:41 The right people are watching it already 21:15:50 cool. 21:16:37 Addressing modes? 21:17:16 sounds good to me - that's related to the new BPs that were just registered? 21:17:32 #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful dnsmasq stateful 21:17:41 so Randy and I submitted a couple of new BPs 21:17:53 The support of SLAAC mode is not new. 21:18:05 We discussed it before, and we have beta code available 21:18:09 I think shshang and Randy's proposals tend towards using dnsmasq and using one process to do both RA and DHCP, right? 21:18:20 yes 21:18:22 yes 21:18:32 I have a question there 21:18:47 and note that I'm not arguing that there's anything wrong with using dnsmasq 21:18:47 the next several BP intents to bridge the gap on DHCPv6 side 21:18:58 but why run dnsmasq if you're only doing slaac? 21:19:10 (just playing devil's advocate) 21:19:13 For DHCPv6, there are several modes 21:19:26 DHCPv6 stateful, DHCPv6 stateless 21:20:01 Which is basically address-and-info and info-only, right? 21:20:07 the new BPs try to bridge the gap on DHCPv6 side, so eventually, we have complete solution around dnsmasq to support SLAAC, DHCPv6 Stateufl, and DHCPv6 stateless 21:20:16 ijw: yes 21:20:17 @ijw, yes 21:20:36 any questions? 21:20:40 So I would prefer to break the problem into two, if we could 21:20:54 RAs on the one side and DHCPv6 on the other 21:21:01 nope 21:21:10 I'm a bit concerned that having one dnsmasq in the router namespace has problems 21:21:15 That is the wrong way to look at the problem. 21:21:18 Not least that networks don't always have routers, for starters 21:21:22 All three modes needs RA 21:21:40 I think a lot of people have that confusion 21:21:46 shshang: don't look at it from that persepctive. Look at it that not all modes need dhcpv6 21:22:01 @aveiga, not sure what you mean 21:22:05 there's no disagreement that all nodes need an RA 21:22:17 but a purely slaac mode doesn't need dnsmasq 21:22:27 aveiga: I think from that perspective it's more that dnsmasq does do DHCPv6 but it's often disabled in shshang's model 21:22:41 @aveiga, you mixed several things together 21:22:53 the dnsmasq is just an implementation of IPv6 address assignement 21:23:11 From IPv6 concept perspective, you have 3 modes 21:23:20 actually, you have 4 21:23:21 SLAAC, DHCPv6 Stateful, DHCPv6 Stateless 21:23:27 don't leave out static 21:23:34 Well, in this case, 'off' 21:23:35 i.e. cloud-init injeceted 21:23:39 yes 21:23:47 static means, no autoconfiguration 21:23:56 Yeah, that's not mutually exclusive with the above, so from a net config perspective it's really just 'off' 21:24:02 yup 21:24:06 hold on though 21:24:11 it might still want an RA 21:24:23 because remember, RAs configure default routes 21:24:27 aveiga: you have a twisty mind 21:24:38 I've been doing IPv6 for almost 8 years 21:24:42 it twists you 21:24:42 RA only configures default route in AUTOCONFIGURATION setting 21:24:48 shadower: not true 21:25:02 you can have a prefix, marked on-link, with A=0 and M=0 and still inject the route 21:25:16 sorry shadower, silly autocomplete 21:25:33 I can now configure my ubuntu VM manaully with IPv6 address and default gateway, if that is the "static" mode you refer to 21:25:40 nope 21:25:55 I am referring to having neutron pick the VM address, and confuigure the VM via cloud-init on boot 21:26:03 Oh, I see 21:26:09 I misunderstood you 21:26:13 yeah 21:26:20 That is not what the BPs are for 21:26:26 that's why you need to decouple RAs and Address assignment 21:26:39 You see, if you divide this down the middle, for any router you want RA+SLAAC, RA without SLAAC and off. And for DHCPv6 you want DHCP+address, DHCP without address, and off. But shshang, you were making a point about RAs being necessary? 21:27:32 For the "static" mode as referred by aveiga, it is not the cases covered by the BPs we submitted 21:28:00 I agree with aveiga, that is another viable way 21:28:01 Indeed, I think it's something we can leave out of the discussion really, short of saying we might want no chatter at all on the network 21:28:06 shshang: yup, and I guess I should propose a BP for injected and non-configured modes 21:28:15 +1 21:28:20 aveiga, agreed your suggestion 21:28:21 BUT 21:28:36 You'll find the cloud-init stuff could use a serious rework on addressing actually, there be dragons 21:28:38 the reason I bring that up is because it really does decouple the RA from address assignment 21:29:04 ijw: I think it should still be the same algo as the SLAAC addr, but that's another conversation I'd like to avoid today 21:29:17 No, that makes a lot of sense to me 21:29:36 aveiga: There's already a tempest scenario that is in review for static injection 21:29:36 Configurable addresses, if they are really needed, come last. 21:29:48 aveiga: we should probably keep an eye on it 21:29:52 +1 21:29:57 so, for the 3 BPs we submitted, our goal is to cover autoconfiguration 21:30:01 #link https://review.openstack.org/#/c/58721/ IPv6 injection scenario testcase 21:30:08 sc68cal: it sucks as an implementation but it demonstrates you can get hold of the data in the right place and that's what the test needs to do now 21:30:14 ijw: agreed 21:30:26 any objections? 21:30:33 yes 21:30:44 reason? 21:30:47 shshang: I think the thing I'm driving at is why run dnsmasq as an RA daemon 21:30:56 why not? 21:31:00 it's not a router 21:31:11 and in cases where you don't want autoconfiguration but still need an RA 21:31:15 you need something else 21:31:21 And mine is that if you use one daemon in the router namespace for everything then unrouted networks break 21:31:37 aveiga, would u plz elaborate? 21:31:48 I think the core is that dnsmasq only has an RA daemon becuase of it's use in OpenWRT and other projects 21:31:54 where it's also a router 21:32:09 in the case here where the address assignment is literally decoupled ala namespaces 21:32:13 aveiga: I thought the point here is that dnsmasq can be configured to do RAs and nothing else? 21:32:33 dnsmasq can send RA, and it can act as DHCPv6 server 21:32:37 aveiga: ijw: the one thing that we need to be concerned with is that there is no API in Neutron for orchestrating rtadvd - which means more work 21:32:48 which is true 21:32:53 No, I think we're into implementation without the abstraction 21:32:53 I am still not sure which use case you refer to? 21:33:01 dnsmasq, radvd, seriously don't care 21:33:01 and I'm not saying that we can't run dnsmasq as RA daemon 21:33:17 I'm justs driving at the reasons we should do that 21:33:23 aveiga, would u plz give me a use case? 21:33:24 because you then couple assignment with routing 21:33:32 shshang: slaac 21:33:42 ? 21:33:52 besides issuing just an RA 21:34:01 dnsmasq has no other purpose 21:34:07 in that use case 21:34:08 what else do you want to issue besides RA in SLAAC mode? 21:34:12 nothing 21:34:25 but Ian is poointing out the opposite problem 21:34:31 a non-routed tenant-only network 21:35:04 putting dnsmasq on the router namespace there is impossible, because none exists 21:35:08 there's no router 21:35:27 OK, let me recap what you want 21:35:44 in non-routed tenant-only network, there is no tenant router, and you still want RA, right? 21:35:49 No 21:35:50 DHCP 21:36:02 that's the tricky part 21:36:09 how do you start dhcpv6 without an RA? 21:36:11 you don't 21:36:41 How are about this, tell me the use case, and tell me what you want to achieve 21:36:59 in the concise way 21:37:08 I think you mentioned several scenarios 21:37:19 guys. the only reason to really have dnsmasq in the qrouter namespace was to provide a default gateway since qdhcp namespace can't do this. 21:37:32 Don't tell me what you don't want, tell me what you want 21:37:40 or it can, but obviously won't work for the tenant 21:38:01 shshang: specifically, I think I would want to have a private network between a webapp server and a DB server with no route to the world 21:38:17 Plus, let us stick to the use case aveiga mentioned: "non-routed tenant-only network w/o tenant router" 21:38:35 shshang: what ijw just proposed is exactly that use case 21:39:00 OK, in that case, webapp and DB server is in the same subnet, right? 21:39:14 Can you turn on ipv6 on dnsmasq that is runing on the tenant's subnet? 21:39:19 no router, right? 21:39:28 correct on both 21:39:47 so if no router, then no qr-interfaces 21:39:50 ok, if you don't want route to external world, then I assume you don't want RA either, right? 21:39:54 baoli: we don't run like that in neutron. A separate dnsmasq is spun up per IP pool (ipv4, ipv6, etc) 21:39:54 nope 21:40:23 but how do you intend to use dhcpv6 without an RA? 21:40:30 without the M and O bits, nothing sill ever solicit 21:40:33 a separate dnsmasq per network actually. 21:40:43 Answer my question, if you don't want route to external world, do you still need RA? 21:40:47 Nope 21:40:54 ijw yes, you do 21:41:00 ... 21:41:11 how do you initiate a solicit? 21:41:15 ijw, and aveiga, can two of you sync up first and get onto the same page? 21:41:27 RIght, I'll correct myself. I don't need a *route*. 21:41:32 correct 21:41:37 Protocolwise I defer to aveiga 21:41:45 but you still need the RA message for dhcpv6 to work 21:42:52 So you don't need default route, and you still want DHCPv6, right? 21:42:56 shshang: to be exactly precise, we need an RA with M and possibly O set, but the RA must not be on-link 21:43:17 which means tell the host to do dhcpv6, but do not install a route 21:43:49 Oh, I see. 21:44:05 yeah, so we have to be careful about blanket stating what an RA does 21:44:17 they aren't 100% decoupled 21:44:41 so I MOSTLY agree with your 3 mode blueprints 21:44:43 In this case, you just create subnet, and network, but not creating router. Is that correct? 21:45:02 with the exception that we need to not make it a default to put dnsmasq in the qrouter namespace 21:45:22 and we should maybe provide some mode where the dnsmasq instances is told "there's no router here" 21:45:39 Yes 21:45:46 Now I see the use case, 21:45:56 *phew* 21:46:08 sorry to drive you in circles, but it was a potentially breaking scenario 21:46:09 yes, agree with you, in that case, there won't be qrouter namespace, but qdhcp namespaece still exist 21:46:15 If you're used to routers, having no router is certainly a bit odd 21:46:19 nononon...it is all good 21:46:28 yup, and we need to issue a non-onlink RA 21:46:35 in that one specific case 21:46:45 but remember, that's not an abnormal thing to do 21:46:49 No, it is fine, we can add a simple check to see whether qrouter- namespace even exist 21:46:54 Doesn't work 21:47:03 I can attach a router later 21:47:16 if qrouter- namespace and qg- interface don't exist, then use qdhcp- namespace 21:47:18 (from an API perspective I can. God only knows what it means.) 21:47:27 ijw: that router should then issue an RA for the subnet though 21:47:47 assuming an address already exists on the host, it should only install the route 21:47:58 which it never had before, because no on-link RAs were present 21:48:04 yeah they'd need to update the subnet via the API to set a gateway, when you add the router (If it doesn't already do that when you create the router) 21:48:06 that should, *in theory* still be OK 21:48:20 it might do it as part of the router creation op 21:48:28 if you want to be doubly sure, we could issue a message to cause the dnsmasq config to change 21:48:28 aveiga, I don't want to go into tooo much implementation details now, but I think I get your use case. But if we add a checkpoint, do you think it will work? 21:48:33 and stop sending RAs 21:48:44 shshang: I think we need a flag 21:48:52 yes 21:48:52 boolean, is_router_present 21:48:55 yes 21:48:57 I agree 21:49:13 I will add enhancement to the BP to call out this case 21:49:18 I'm still going to ask, is there any reason to go moving the daemon from the dhcp to the router namespace, or is it simpler to just use two? 21:49:19 ok 21:49:29 but aveiga, thanks for bringing it up 21:49:34 it is an interesting use case 21:49:46 and that's exactly why I asked about running an RA from the router, in its own daemon 21:49:46 The flag might be able to just do a query to the neutron DB for the presence of a router attached to the subnet or network 21:49:55 even if said daemon is another copy of dnsmasq 21:50:08 or just query out the ports for a network, look for the device owner to be a router 21:50:18 ijw: you need the qrouter instance of dnsmasq for cases where you want to provide a default gateway 21:50:35 I think thay should split 21:50:42 Randy__: yup - that's what I mean about two - granted you can't avoid the router daemon 21:51:00 and the qdhcp instance should only ever issue an RA when a) RA is no on-link and b) the RA is only present when there is no router 21:51:03 yes, the qdhcp namespace instance remains intact 21:51:12 otherwise, the other daemon running in the qrouter namespace runs the RA 21:51:18 aveiga: yes 21:51:23 #action shshang add a blueprint to cover a tenant network with no router 21:51:31 shshang: does that sound right? 21:51:42 or should I rope in aveiga and ijw to help 21:51:59 I think aveiga explained it clearly 21:52:05 I don't want to dictate implementation, but it seems to me that we need the RA to be discrete from the dhcpv6 server 21:52:12 Actually I think aveiga would be better for this 21:52:13 except for the no_routers case 21:52:27 #undo 21:52:28 Removing item from minutes: 21:53:05 Let me know how to word the action, so we can file it then do open discussion 21:53:08 also, assign me one to define the RA cases and the desire for a separate RA daemon 21:53:26 #action aveiga define RA cases and the desire for a separate RA daemon 21:53:48 the assumption here is, if we have qrouter, then we assume we have default gw, hence RA should be from qrouter- namespace and it should have privilege; if we don't have qrouter, then it is non-router case and dnsmasq in qdhcp namespace should send RA 21:53:50 uh, is everyone OK with a slight delay here? I'm going on PTO for medical and family reasons starting Saturday 21:53:56 is my statement accurate? 21:54:13 I mean, the assumption here? 21:54:19 shshang: be specific though, the qrouter has to be on the same subnet 21:54:23 sounds correct to me 21:54:32 as opposed to a shared public network and a private tenant network on the same machine 21:54:34 Yep - the only thing I would add is, does it actually matter where DHCP comes from if we have DHCP or should we just use the DHCP NS for that all the time? 21:54:39 hence why I think there should be a flag 21:54:56 aveiga, correct 21:55:05 ijw: for the sake of not breaking ops folks troubleshooting this, reduce disparity with the v4 model where possible 21:55:09 hence, leave it in qdhcp 21:55:28 and leave the routing functions in qrouter 21:55:55 Now, the reason I like that is nothing to do with the DHCP one but that we again come down to the nice simple solution 'routers send RAs' - we need a daemon there that respects attached subnets' flags and does very boring things 21:56:07 yup 21:56:20 routing routes and addressign assigns addresses 21:56:26 and we're out of time 21:56:31 sorry to hijack the meeting 21:56:32 OK, this is good discussion 21:56:41 no no no, aveiga, it is ALL good 21:56:41 yeah let's just open it for the last few minutes 21:56:47 I like this kind of brainstomr, 21:56:54 #topic open discussion 21:57:00 Now I can see the use case you are thinking 21:57:12 In practice there's only so much work we'll get done in a 'week' and we've just carved some of it off. 21:57:44 I apologize for running through the first 15 minutes of the meeking super quick - but I knew this discussion was probably going to take the bulk of the time 21:57:45 So shshang, do you have some code that could do that? Sounds like what you have - using dnsmasq, probably, but who cares - could spit RAs 21:58:10 sorry, ijw, what do you refer to? 21:58:19 RAs from routers per above 21:58:24 yes 21:58:29 running two dnsmasqs, one for addressing and one for RA 21:58:30 Ignoring DHCP for now, we can add that in a later round 21:59:04 So I would suggest we do the thing we need in the qrouter NS, we leave the old DHCP NS there (for v4 only, for now) and call that a job 21:59:20 I think we're pretty well wrapped up 21:59:22 this is what has been done 21:59:50 Randy__: thought so, but the thing is it has much fewer modes now - RA-slaac, RA-noslaac and off 22:00:01 sc68cal: I think you should adjourn 22:00:04 we're over 22:00:14 hmm - is my clock slow? 22:00:27 I'm reading 2200 22:00:30 same 22:00:31 aveiga, 22:00:34 #endmeeting