On 10/6/14 2:16 PM, "Tom Herbert" <[email protected]> wrote: > >Consider in Iast week's Interim meeting I described the "virtualizing >existing jobs" use case of networking virtualization. In this model, >we would like to be able to migrate existing jobs between servers. For >the networking part of this, we need to migrate addresses and and >connection state.
Clarifying question. Trying to understand the comment here; Not promoting a specific approach/technology. Does migration of "IP addresses and connection state" does not equate to Layer-3 mobility ? >These jobs don't run in VMs, they run in the host's >stack with some sort of containerization. While job is not migrating >there is no impact, performance and behavior are unchanged. At most we >need to perform encapsulation, >but we may even be able to obviate that >with some create use of IPv6 addressing (Identifier/Locator). If the container has its own IP address and is changing its point of attachment across layer-3 boundaries, then to me those container migration properties are matching the mobility of a typical mobile device. The use of encapsulation is to hide the transport topology from the end point addressing; FWIW, Identifier is a stable address, locator is your current reachable point; In some other language this is the home address/care-of address. Sri _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
