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

Roland Bless <roland.bless@kit.edu> Wed, 06 July 2011 17:46 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 58B9B21F88FE for <vnrg@ietfa.amsl.com>; Wed, 6 Jul 2011 10:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+-izxf9Jyzy for <vnrg@ietfa.amsl.com>; Wed, 6 Jul 2011 10:46:48 -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 298FA21F8899 for <vnrg@irtf.org>; Wed, 6 Jul 2011 10:46:47 -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 1QeWBM-0003IE-Nr; Wed, 06 Jul 2011 19:46:46 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 78414A804CD; Wed, 6 Jul 2011 19:46:39 +0200 (CEST)
Message-ID: <4E149F7E.9080706@kit.edu>
Date: Wed, 06 Jul 2011 19:46:38 +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: Joe Touch <touch@isi.edu>
References: <E84E7B8FF3F2314DA16E48EC89AB49F01CED6E4D@DAPHNIS.office.hd> <4E142E69.5040606@kit.edu> <4E148490.8000006@isi.edu>
In-Reply-To: <4E148490.8000006@isi.edu>
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 1309974406.436817000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Status of the VNRG: Dormant or dead?
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: 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.

Yep.

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

Agree.

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

Agree.

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

Regards,
 Roland