I'm just trying to understand why it's simpler or preferred. To me it's simpler to not bother with the VPC-wide, and automatically enables flexibility or the use case you've described.
Case 1: admin decides to put a /60 on a vpc admin programs /60 to vpc via cloudstack admin programs /60 route on upstream router to point to vpc admin assigns /64 ranges from /60 to individual vpc networks via cloudstack Case 2: admin decides to put a /60 on a vpc admin programs /60 route on upstream router to point to vpc admin assigns /64 ranges from /60 to individual vpc networks via cloudstack On Mon, Jan 13, 2014 at 3:23 AM, Daan Hoogland <dhoogl...@schubergphilis.com> wrote: > 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
