cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: IPv6 in VPC (was Re: IPv6 plan - questions)
Date Fri, 10 Jan 2014 17:13:54 GMT
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.hoogland@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 <shadowsor@gmail.com> wrote:
>> On Thu, Jan 9, 2014 at 9:43 AM, Daan Hoogland <daan.hoogland@gmail.com> wrote:
>>> On Thu, Jan 9, 2014 at 5:28 PM, Marcus Sorensen <shadowsor@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

Mime
View raw message