Re: [vnrg] Some definitions and way forward

Roland Bless <roland.bless@kit.edu> Thu, 04 August 2011 09:53 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: vnrg@ietfa.amsl.com
Delivered-To: vnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B003F21F8B1B for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 02:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.006
X-Spam-Level:
X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZt2jIFIKkxh for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 02:53:10 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id DABEB21F8B03 for <vnrg@irtf.org>; Thu, 4 Aug 2011 02:53:09 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1Qouc8-00083g-La; Thu, 04 Aug 2011 11:53:23 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 60EB9A80025; Thu, 4 Aug 2011 11:53:15 +0200 (CEST)
Message-ID: <4E3A6C09.8010505@kit.edu>
Date: Thu, 04 Aug 2011 11:53:13 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Andreas Fischer <andreas.fischer@uni-passau.de>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu> <4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de>
In-Reply-To: <4E3A5EDE.2060208@uni-passau.de>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1312451603.432147000
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2011 09:53:10 -0000

Hi Andreas,

On 04.08.2011 10:57, Andreas Fischer wrote:
> Aren't VPNs just one kind of link virtualization? VPNs are basically
> tunnels with added encryption, no? Tunnels, on the other hand, just
> create a "virtual link" between two arbitrary nodes in a network.

Yes, but a tunnel is IMHO an overlay technique:
it is created between the end-points of the underlying layer. Consider
an L3-VPN, consisting of networks N1 and N2 and a "virtual link" between
them.

 /----\                        /----\
|  N1  |--R1==============R4--|      |
|      |  |                |  |  N2  |
 \----/   +-----R2----R3---+   \----/

N1 and N2 are networks that are connected via some provider network.
R1 and R4 are their access routers. The tunnel is established between
the endpoints R1 and R4, i.e., they are source/sink of the outer header
of the tunnel packets and the tunnel is terminated there. R2 and R3 are
not and do not have to be aware of the virtual link in this case.
A non-overlay solution would require awareness in R2/R3, e.g., creating
and LSP.

> As such, I would also disagree to consider them as kind of an overlay
> network, as
> a) They don't build a network, only a link (the 'N' in 'VPN' is
> misleading, IMHO)

Hm, but there are other nodes connected by that tunnel, e.g.,
N1 and N2 may have their own routers etc. Especially, they
have their own addressing scheme and routing inside their
VPN.

> b) They are not necessarily between end hosts (which conflicts your
> earlier statement, that overlay nodes are always sitting at the edge of
> the network)

But always between end-points (in an addressing sense, not in a
topological sense) of the underlay/substrate. If one defines a host
as being either source or sink of packets, the term host is also
correct. In the above example, we have R1 and R4 being routers in the
substrate, but from a forwarding perspective, they are end-points
(hosts) for the tunnel. For VPN traffic, the hosts will reside in N1 or
N2.

Regards,
 Roland