On 12/20/2012 04:04 PM, Wesley Eddy wrote:
On 12/20/2012 3:49 PM, Brandon Williams wrote:
Hi Wes,
Thanks for your comments.
It looks like I might have managed to make the use of the proposed
option less clear, instead of more clear. Or maybe I'm misunderstanding
the point that you're making.
The mechanics of our system are tunnel-based, as with most overlay
architectures that I've looked at. The tunneling starts at an overlay
ingress machine close to one of the endpoints (i.e. the client or
server) and ends at an overlay egress machine close to the other
endpoint. Since the ingress and egress are on the public internet, the
overlay does not extend all the way onto the endpoints' LANs. This means
that standard internet routing cannot be used to drive the connections
into the overlay. Instead, NAT is used on both sides of the overlay,
which results in the server having no way to reliably identify the client.
The proposed options are not intended to be used as part of the
mechanics of the overlay. The overlay is fully functional without the
options. Instead, the options are intended to provide the client's
connection identifying information to the server for use in
load-balancing, diagnostics, etc.
Ah, so are there additional devices beyond what's shown in your Figure
1? I ask because if the overlay ingress and egress are simple tunnel
endpoints, then the endpoint addresses would be totally visible to one
another.
Yes. There are additional devices between the HOST and OVRLY_IN, and
also between OVRLY_OUT and SERVER, but those devices are just the
internet's standard routing infrastructure. There are also potential
intermediate devices between OVRLY_IN and OVRLY_OUT that can be used for
optimized routing between the overlay's ingress and egress.
Your figure 1 is:
+------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +------------+ |
| HOST_1 |-----| OVRLY_IN_1 |-----------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +------------+ +-----------+ | +--------+
| HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER |
+-----------+ | +------------+ +-----------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVRLY_IN_3 |-----------+ |
+-----------+ | +------------+ |
| |
+------------------------------------+
Figure 1
If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes,
then the inner IP headers would have the HOST_X and SERVER
addresses, and the outer ones in the tunnel would have the
overlay headers. Since the inner packets would be delivered
ultimately after egressing the tunnels, the HOST_X addresses
are totally visible to the server, and vice versa.
There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the inner
IP headers will typically use either the client-side addresses or the
server-side addresses. However, neither OVRLY_IN nor OVRLY_OUT can be
assumed to be reliably in-path between HOST and SERVER, which means that
internet routing cannot be relied upon to cause packets to arrive at the
overlay ingress. Instead, HOST_1 must directly address OVRLY_IN_1 in
order to send its packets into the tunnel, and SERVER must directly
address OVRLY_OUT in order to send the return traffic into the tunnel.
Your document shows instead:
---------------------------------------------------------------------
ip hdr contains: ip hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
---------------------------------------------------------------------
So, this is not really showing tunnels to me ... this is rewriting
(NAT) of the destination address.
As noted above, the use of tunnels and NAT in this case are not mutually
exclusive. NAT is used to allow the overlay ingress to intercept
packets, which are then tunneled to the overlay egress, where NAT is
used to deliver the packets to the receiver and ensure that return
traffic also uses the overlay.
--Brandon
PS: Sorry to double send this to you Wes. It was bounced by the ietf
lists the first time.
--
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
