Re: [vnrg] Some definitions and way forward

Andreas Fischer <andreas.fischer@uni-passau.de> Thu, 04 August 2011 10:47 UTC

Return-Path: <andreas.fischer@uni-passau.de>
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 D5B1E21F8B04 for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 03:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 S0Y+P-7oomUq for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 03:47:00 -0700 (PDT)
Received: from tom.rz.uni-passau.de (tom.rz.uni-passau.de [132.231.51.4]) by ietfa.amsl.com (Postfix) with ESMTP id C564B21F8B00 for <vnrg@irtf.org>; Thu, 4 Aug 2011 03:46:59 -0700 (PDT)
Received: from tom.rz.uni-passau.de (puremessage.rz.uni-passau.de [132.231.51.54]) by tom.rz.uni-passau.de (Postfix) with SMTP id B91DC2E0951; Thu, 4 Aug 2011 12:47:13 +0200 (CEST)
Received: from mail.uni-passau.de (localhost [127.0.0.1]) by tom.rz.uni-passau.de (Postfix) with ESMTP id 5FE522E0954; Thu, 4 Aug 2011 12:47:13 +0200 (CEST)
Received: from [132.231.13.115] (helo=[132.231.13.115]) by mail.uni-passau.de with ESMTP (eXpurgate 3.2.5) (envelope-from <andreas.fischer@uni-passau.de>) id 4e3a78b1-104a-84e70d7309a9-1 for <multiple-recipients>; Thu, 04 Aug 2011 12:47:13 +0200
Message-ID: <4E3A78B1.1050808@uni-passau.de>
Date: Thu, 04 Aug 2011 12:47:13 +0200
From: Andreas Fischer <andreas.fischer@uni-passau.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Roland Bless <roland.bless@kit.edu>
References: <4E3936FF.1090006@kit.edu> <4E39750A.2080302@isi.edu> <4E39A9E8.5070307@kit.edu> <4E3A5EDE.2060208@uni-passau.de> <4E3A6C09.8010505@kit.edu>
In-Reply-To: <4E3A6C09.8010505@kit.edu>
X-Enigmail-Version: 1.2
Content-Type: multipart/mixed; boundary="------------000109060709090006020301"
X-purgate-ID: 151291::1312454833-0000104A-039F604E/0-0/0-0
X-purgate-type: clean
X-purgate-size: 3658
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_FUNWORDS 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0'
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 10:47:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roland,

On 04.08.2011 11:53, Roland Bless wrote:
> 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.

Ok, I think I had a slightly different notion of overlay here. If an
overlay is characterized by being transparent to the substrate (except
for the end-points, of course), then I agree with your point.

>> 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.

Depends. If you consider the conglomerate of N1, R1, R4, and N2 as being
the VPN, then there is actually a network. However, then the 'V' and the
'P' are misleading. This network is - for a large part - not virtual,
but real. Moreover, it is not necessarily private - R1 may possibly only
route certain traffic via the tunnel (e.g. only traffic destined for
N2), whereas the rest may be open to the Internet.

Regarding typical implementations (IPSec, OpenVPN, SSH, ...) I would
consider the VPN in your picture consisting of just the tunnel.
Therefore my argument, that it isn't actually a network, just a link
(apologies to Michael - I did not consider multipoint-to-multipoint VPNs
here).

Regards,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOOnixAjz9S4YPAw8RAgXJAJ9fvf/NM/Cwz/c27u6clGPcQmCgVgCeMLwE
tJ3mMZyvem60hZeR0tkADZ0=
=OOYA
-----END PGP SIGNATURE-----