On Thu, Jan 9, 2014 at 9:43 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > On Thu, Jan 9, 2014 at 5:28 PM, Marcus Sorensen <shadow...@gmail.com> wrote: >> Do you have any specific reasoning or need for the >> VPC itself to have a configured contiguous block, rather than just >> assign the /64s the networks? > > > convenience in configuring the upstream router. The idea is that > everything on the network gets the same ip-space (/56 or /52 or > whatever) whether it is a VPC or an isolated network.
That would still be possible even if you didn't provide that info to cloudstack. You could internally choose to only assign networks from a particular /56 to a VPC. I originally wanted that too, but after thinking about it a bit and the implementation, that setting just sits there, doing nothing in cloudstack. It's just a database entry, not used for anything that is necessary for the IPv6 to work. All of the work revolves around the individual prefixes assigned to the network and programming internal VR routes for those. We could potentially use it as a validator (does the range entered fit within the vpc range), but is there any reason to validate/limit someone? We could also create an automated allocator, but since we currently don't do that for VPC tiers with IPv4 it seemed like an inconsistent approach. However, I suppose it may preclude us from creating an allocator later (or the allocator would need to be able to handle allocating from and managing multiple prefixes in order to accomodate existing non-contiguous allocations). If an admin later wants to put a new /64 from the new ARIN allocation on a VPC, or a tenant has their own ARIN assignment, we could easily just enter their /64 without having to launch a new VPC and move/redeploy their VMs. Maybe there's something I'm overlooking there. > > The block broker was Hugo's idea to make working with devcloud > convenient. This way we get lots of playing around and feedback on the > rest of the implementation. > It needs to be optional if our implementation is to be serious in any > kind of bigger business environment. > > As to the last points; You are right about their importance. They are > there to signify design considerations, not constraints or > requirements. > > in all I think we agree on the general way to go, > Daan
