Re: [vnrg] Status of the VNRG: Dormant or dead?

Roland Bless <> Wed, 06 July 2011 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58B9B21F88FE for <>; Wed, 6 Jul 2011 10:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d+-izxf9Jyzy for <>; Wed, 6 Jul 2011 10:46:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 298FA21F8899 for <>; Wed, 6 Jul 2011 10:46:47 -0700 (PDT)
Received: from ([] by with esmtp port 25 id 1QeWBM-0003IE-Nr; Wed, 06 Jul 2011 19:46:46 +0200
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTPS id 78414A804CD; Wed, 6 Jul 2011 19:46:39 +0200 (CEST)
Message-ID: <>
Date: Wed, 06 Jul 2011 19:46:38 +0200
From: Roland Bless <>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060111 Thunderbird/1.5 Mnenhy/
MIME-Version: 1.0
To: Joe Touch <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: Kaspersky (
X-ATIS-Timestamp: 1309974406.436817000
Cc: "" <>
Subject: Re: [vnrg] Status of the VNRG: Dormant or dead?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jul 2011 17:46:49 -0000

Hi Joe and all,

On 06.07.2011 17:51, Joe Touch wrote:
> I agree, and don't see either as particularly relevant to VNs. They're
> implementation issues, AFAICT. The more relevant technology to me is
> router virtualization.

Yep, agree.

>> That depends on the substrate technology, some allow to embed a "VNet
>> Tag" to identify different virtual links, e.g., VLAN-Tags in Ethernet
>> headers.
> Again, this is an implementation issue. I would expect some sort of
> indicator of VN, which can be buried inside an existing header or can
> require an additional header.

Correct, I just provided an example.

> IMO, a VPN extends an existing network to add a new node, or ties two
> existing networks together, i.e., it's a way to add a single private
> link to a new node.

> Further, VPN nodes are always a member of exactly one VPN.

Usually, yes, though one can think of VPN concentrators providing
access to several different VPNs

> A PPVPN is a network provided by another party (the provider) so that
> users can join it via basically conventional VPN methods.
> I don't think of VPNs as addressing either link or router multi-use,
> either.


> None of this is true of VNs, IMO - a VN is a complete E2E network, can
> coexist with many other VNs (even to the same endpoint nodes), etc.


>> How do OpenFlow concepts fit
>> into the classification?
> IMO, Openflow is a tool; it does not define a network architecture. It
> can be useful in moving some network issues elsewhere (e.g., allowing a
> non-VPN capable node to join a VPN, or helping to implement router
> virtualization outside a router that doesn't support it). I don't see
> Openflow as anything other than one of many tools here - and one I've
> never needed to develop VNs (if others do, I'd be glad to hear why).


>>> What do you see is important for the RG right now or what is missing?
>> See above, but maybe we should also consider questions such as
>> what interfaces and protocols are needed for creating inter-provider
>> virtual networks.
> That seems to presume we know what an intra-provider VN is, and I'm not
> sure we're all on a single page there... ;-)

Ok, I meant a VN spanning several substrate providers (or to use
4WARD terminology: Infrastructure Providers - InPs) in
contrast to a VN inside a single InP, which can be provided
by using proprietary protocols.