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