Subject: Re: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Oct 2015 17:12:41 -0700

>
> Why did you not consider LISP (rfc6830) as a solution to your problem?
> Is it because LISP is an overlay and you preferred native transport?
> Your document does overlay IPv4 data in an IPv6 tunnel and thus the
> ipv4 solution could just as well use LISP?
>
LISP, along with many other methods that could implement an overlay
network (GUE, VXLAN, IPIP, SIT, GRE, etc.), is an encapsulation
protocol. In ILA we avoid encapsulation, and so it should provide the
best performance and compatibility with networking HW for implementing
an overlay. As discussed in the draft there are limitations-- this is
only for encapsulating L3 and it's not extensible for things like
securing a virtual network identifier.

The IPv4/IPv6 translation (not as tunneling) actually solves another
problem in network virtualization. Consider a data center that is
providing multi-tenant network virtualization, where tenants are IPv4
and use private addresses in 10/8. We would like to implement a common
service in the data center at some public IP address. Because client
addresses are not guaranteed to be unique, at the server either we
need to run an instance for each tenant virtual network, or use NAT to
make the client's source IPv4 address reachable back to the machine it
is running on. With ILA, we would allow the client to connect to an
IPv4 address, but at the server this would be IPv6. The client's
address as seen by the server would indicate both the virtual
networking identifier assigned to the client and virtual address. So
the client is unambiguously identifiable at the server, and this also
allows the client to be migrated without breaking the connection.

Tom