15:03:42 <sc68cal> #startmeeting neutron_ipv6
15:03:43 <openstack> Meeting started Tue Sep 30 15:03:42 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:44 <john-davidge> hello
15:03:47 <openstack> The meeting name has been set to 'neutron_ipv6'
15:06:27 <sc68cal> Just a gentle reminder if there are any high priority bugs that we want to fix during the RC phase, let me or cores know
15:06:34 <sc68cal> I saw a couple get classified yesterday
15:07:19 <john-davidge> I'd like to discuss https://review.openstack.org/#/c/87987 if possible
15:07:47 <sc68cal> sure
15:07:51 <john-davidge> Specifically using a fixed prefix for the initial IPv6 private subnet vs. a randomly generated one
15:08:24 <baoli> I want to point out that devstack is used for development, not for a real deployment
15:08:53 <john-davidge> I can see the appeal of using random generation, but I also feel that the results of running stack.sh should be predictable
15:09:06 <sc68cal> I'll point out that DevStack is deployed by some in real datacenters and real equipment
15:09:24 <sc68cal> still for dev purposes, but it's not always existing on a laptop
15:09:39 <aveiga> #link http://tools.ietf.org/html/rfc4193#section-3.2 RFC 4193 Global ID
15:10:22 <baoli> aveiga, are you suggesting to incorporate the algorithm desceibed in 4193 in lib/neutron?
15:10:28 <aveiga> personally, I'll be disabling ULA addressing in our deployments
15:10:40 <aveiga> baoli: if we're going to default to ULA, then yes
15:10:48 <aveiga> if you're going to use it, follow the RFC
15:10:56 <baoli> aveiga, do you know any existing tools to do that?
15:11:33 <baoli> aveiga, for v4, the default is 10.0.0.0/24.
15:11:45 <sc68cal> I suggested in my review to dd a few bytes from /dev/random and use hexdump to stringify
15:12:07 <aveiga> baoli: no, I don't.  I don't know if I've said this before, but I'm not much of a programmer.  I'm a network engineer who goes deep in the RFCs and has deployment experience with IPv6
15:12:09 <sc68cal> then concat with the ULA block
15:12:28 <aveiga> and IPv4 doesn't have a random ID requirement as RFC1918 space is never meant to route
15:12:34 <john-davidge> Would we also want to prevent the user from specifying a fixed ULA prefix? And if so should this not be a feature in Neutron?
15:12:57 <sc68cal> out of scope for neutron
15:12:58 <aveiga> john-davidge: nop, we should allow it since they may been joining a provider network that is preconfigured
15:13:08 <sc68cal> neutron assumes you understand networking and addressing
15:13:09 <aveiga> I can see bare metal existing on the same l2-segment
15:13:15 <baoli> keep in mind that the default can be overwritten
15:13:24 <sc68cal> yeah but a bad default is a bad default
15:13:33 <aveiga> baoli: agreed. Defaults should be sane and follow RFC though
15:13:59 <aveiga> if restacking and getting the same addresses is necessary, add the scope to your stack script
15:14:33 <sc68cal> john-davidge: a question for you, I see you are using link local addresses for everything else, including the public v6 net
15:14:40 <aveiga> but sc68cal is correct that there are people deploying multi-node devstack as a real build tied to the rest of a lab network
15:14:41 <sc68cal> by default
15:15:15 <john-davidge> I can see what you're saying in terms of RFC complaince
15:16:52 <sc68cal> john-davidge: can you comment on your thought process for using LLAs for the other v6 subnets that devstack creates, including the public ipv6 subnet?
15:18:16 <baoli> sc68cal, the link local addr is used between the namespace and the host.
15:18:39 <john-davidge> baoli: I belive the defult addresses were part of your contributions
15:24:27 <baoli> sc68cal, aveiga, ipv4 with the default of 10.0.0.0/24 has the same risk.
15:25:02 <sc68cal> I disagree
15:25:46 <sc68cal> *unique* local address
15:26:02 <baoli> what the script does is to add a private ipv6 subnet into the network 'private'
15:26:26 <sc68cal> then use LLAs
15:26:32 <sc68cal> like you did for all the other nets
15:27:13 <baoli> LLAs are auto generated
15:28:11 <sc68cal> so then why are you setting IPV6_PUBLIC_RANGE=${IPV6_PUBLIC_RANGE:-fe80:bad:dad::/64} ?
15:28:33 <john-davidge> baoli: I think we're talking about IPV6_PUBLIC_RANGE which is set on line 95
15:29:31 <baoli> sc68cal, it's to setting up the router so that the gateway port and br-ex are on the same network.
15:30:49 <baoli> the ipv6 private subnet needs to be created with neutron
15:32:47 <aveiga> I don't have a problem with any of this.  I just think we need to follow the RFC and generate pseudo-random scopes
15:32:52 <aveiga> is this really a big problem?
15:33:08 <aveiga> if it's necessary to have the same scope every time you restack, specify it in neutron subnet-create
15:33:23 <baoli> Besides, the private subnet prefix can be a global IPv6 addresses.
15:33:28 <aveiga> I just don't want defaults to violate RFCs, regardless of use
15:33:56 <baoli> So that the VM can communicate with the ipv6 internet
15:34:16 <baoli> In my localrc, I have it assigned with a global ipv6 prefix
15:34:25 <aveiga> right, which is totally fine
15:34:37 <aveiga> just change the default to not have a fully blank ULA prefix, as it violates the spec
15:35:01 <baoli> aveiga, so randomness is not required?
15:35:04 <john-davidge> aveiga: that makes sense to me, I'm sure we can do that
15:35:16 <aveiga> baoli: it is for the default scope when nothing is specified
15:35:27 <baoli> that sounds good to me
15:35:38 <aveiga> yup, asnd that's all I recommeneded in the review
15:35:40 <john-davidge> Ok great, I'll get started on that
15:35:57 <HenryG> It is easy to get a few random hex digits with uuidgen.
15:36:14 <aveiga> +1
15:36:43 <baoli> Ok, that's fine to me as well since it doesn't sound a big task to achieve.
15:36:46 <HenryG> uuidgen | sed s/-//g | cut -c 24- | sed "s/\(....\)\(....\)\(..\)/\1:\2:\3/"
15:36:48 <HenryG> :)
15:37:55 <john-davidge> HenryG: :)
15:39:48 <HenryG> There are two bugs that should really go in Juno, but they are blocked because of string freeze
15:40:22 <aveiga> HenryG: are you referring to https://review.openstack.org/116525 ?
15:40:38 <HenryG> yes, that is one
15:41:32 <HenryG> The other is https://review.openstack.org/117799 but I don't see a string there, so it should go in.
15:42:19 <baoli> https://review.openstack.org/#/c/123744/ as well
15:43:30 <haleyb> john-davidge: and there's always the python random library that we already use for MAC address generation
15:43:33 <xuhanp> https://review.openstack.org/#/c/101433/ this one has been moved out of RC1 as well
15:43:57 <HenryG> baoli: That is a client change, not dependent on release cycle.
15:44:16 <baoli> HenryG, I see.
15:44:39 <john-davidge> haleyb: Thanks, will take a look
15:45:30 <HenryG> xuhanp: Thanks, I lost track of that one :(  I kinda thought it was already merged.
15:46:20 <xuhanp> yep. we got a -1 which requires some clarifications. Now it gets removed.
15:46:21 <HenryG> So we have three patches that we want to campaign for getting in RC2.
16:00:12 <openstack> adrian_otto: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:47 <adrian_otto> oh, neutron needs to finish
16:01:34 <adrian_otto> is the neutron meeting still active, or has it gone idle?
16:01:40 <coolsvap> sc68cal, need to end ipv6 meeting
16:01:43 <coolsvap> i think its idle
16:02:04 <mspreitz> sc68cal is host
16:02:13 <adrian_otto> mspreitz: thanks
16:02:16 <mspreitz> sc68cal: are you still there?
16:02:36 <sc68cal> #endmeeting