Not necessarily. You can still set the upstream to send a /60 to VPC X, and then just assign individual /64s from that /60 into the networks in that VPC. You can create a route upstream for each /64, but you can also just program the contiguous /60 route into the upstream. That gives you future expansion as well, you could have that /60 and then decide you want an extra, non-contiguous block added later. By not requiring a block on the VPC, and admin can still choose to organize it that way, but they're not locked into the choice they initially made.
On Fri, Jan 10, 2014 at 3:41 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > 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
