On Thu, May 28, 2015 at 11:44 AM, Luan Nguyen (CBU)
<luan.nguyen(a)dimensiondata.com> wrote:
> What I am trying to get at is yeah, you still need the l2 extension
> encapsulation, but on top you need something for disaster recovery, machines
> mobility between data centers, sort of like Vshield Edge using NAT – you can
probably what the vm mobilty looks like is a change in the L2 path,
right? why make it anymore complicated than that? inside a single
availability domain I would expect the L2 domain a vm sees doesn't
change, even if the VM itself is moved from physical machine to
physical machine.
making it more complex at the vm level is probably a bunch of work
that doesn't have to happen.
> change the NAT pool and update the DNS record, but the internal would remain
that sounds like a bunch of work though, which I don't think is really
necessary. I'm just a plumber, though so I don't actually know what
anyone does with this stuff.
> the same no matter where you move it to. LISP seems like a simple
> solution…so as specific host route injection, which for enterprise shouldn’t
lisp wasn't really finalized (still sort of isn't) when aws/ec2
started going like gang busters. They might have changed technology
under the hood, but it doesn't seem like they would have had to (not
in a drastic 'change encap type' sort of way at least).
> be much of a problem, but DRaaS cloud provider, this could ballooning the
> routing table pretty quickly.
how so? does the external and internal view from the vm have to be the
same? do the public /32's have to be individually routed ? inside what
scope at the datacenter?
> What does Google use? :)
no idea, probably rabbits with different colored carrots?
