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

Joe Touch <> Wed, 06 July 2011 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A5E321F886F for <>; Wed, 6 Jul 2011 08:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.502
X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XLEcG7YZavsb for <>; Wed, 6 Jul 2011 08:52:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 69BF221F8871 for <>; Wed, 6 Jul 2011 08:52:27 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p66FpiRb009114 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2011 08:51:54 -0700 (PDT)
Message-ID: <>
Date: Wed, 06 Jul 2011 08:51:44 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Roland Bless <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
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 15:52:28 -0000

Hi, all,

(speaking as an individual participant)

On 7/6/2011 2:44 AM, Roland Bless wrote:
>> We had the last meeting at the Beijing IETF meeting and also some lively discussion afterwards.
>> One of the areas of discussion was (amongst many others):
>> - openflow vs. forces
>> - how forces would fit in virtual networks
> I see both technologies mainly focused on control plane / data plane
> separation.

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.

>> - do we need tunnel headers for virtual networks on the wire or not?
> 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.

>> - definition of acid tests
> Not only definition of acid tests, but also definition of
> terms. For instance, how differ traditional VPNs from Virtual
> Networks in the context of network virtualization? IMHO current
> VPN solutions concentrate mainly on virtual links, advanced concepts
> consider virtual nodes as active elements.

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.

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