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.
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.
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.
Or am I misunderstanding?
--
Wes Eddy
MTI Systems
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
