I think you are overlooking the fact that if you do not assign a continuous block to a vpc you need to set routes upstream for every tier. If you do you can set only the vpc block and let the vpc router take care of the internal routing. Maybe I am wrong and we are just speaking a different type of English, me being dutch and all.
On Thu, Jan 9, 2014 at 6:23 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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
