H Marcus, The idea is that for phase 1 we make it as simple as possible. The extra networks / ip-space per network can always be added later. Support will have to build for adding the routes on a per router implementation basis, as I understand. I was describing the simplest solution to implement first. I have no intention to forbid any strange complicated setup as admins design them. This one seemed the most straight forward from an automation point of view to me, or to us I should say.
Regards, DaanH -----Original Message----- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: vrijdag 10 januari 2014 6:14 To: dev@cloudstack.apache.org Cc: Daan Hoogland; Hugo Trippaers; Edwin Beekman; Erwin Blekkenhorst; Daan de Goede Subject: Re: IPv6 in VPC (was Re: IPv6 plan - questions) 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
