On 3/19/13 2:23 AM, "Murali Reddy" <murali.re...@citrix.com> wrote:
>On 19/03/13 4:08 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> >wrote: > >>Thanks for this. I'd like to note that there is no evidence that AWS >>maintains a separate pool of "Elastic Public IP" and "Ephemeral Public >>IP". If we drop this phantom construct, then the feature is greatly >>simplified >> - there are not 2 workflows to acquire a persistent public ip >> - there are no additional APIs >> - the only thing that needs to be done is to move the public ip resource >>to the region level from the zone level > >Chiradeep, thanks for your feedback. I agree to that fact that there is no >evidence that AWS maintains a separate pool of "Elastic Public IP" and >"Ephemeral Public IP". I don't have operational insights of datacenter >network infra, I would imagine data centre edge routers will advertise >subnets typically. It does not seem trivial to move a public IP across >data centres, hence the 'phantom construct' :) Rather than guessing, I'd say that the feature "requires" the ability of the routing infrastructure to move individual /32 across data centers. BGP AS do not advertise /32 outside (their BGP peers wouldn't accept them), so the provider has to control it inside their AS -- which means that all zones have to belong to the same AS. > >Can you please elaborate what you meant by "move the public ip resource to >the region level from the zone level"? Are you suggesting that public IP >that are configured at zone level today to be a resource at region level? >which means that current deployments with more than one datacenter with >their respective public IP address pool per zone will be migrated to a >single public IP address pool at region level? If region level public IP >pool/subnet is allocated to instances across multiple zones, the IP >address allocation is scattered then how does routing will work? If >CloudStack just assumes that public IP (non RFC 1918) can be >moved/allocated across the zones, then (irrespective of EIP service is >enabled or not) we have can public IP pools configured at region level. >But question is, is it a fair assumption? As I said, the use of the feature (enabled a region level) requires the routing infrastructure to handle these moves. If they cannot, then they do not get this feature.
