Re: [vnrg] Some definitions and way forward

Roland Bless <roland.bless@kit.edu> Thu, 04 August 2011 21:06 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 8120311E8090 for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 14:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.029
X-Spam-Level:
X-Spam-Status: No, score=-6.029 tagged_above=-999 required=5 tests=[AWL=0.220, 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 H6D-JA5PZV-i for <vnrg@ietfa.amsl.com>; Thu, 4 Aug 2011 14:06:21 -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 AC3C011E8077 for <vnrg@irtf.org>; Thu, 4 Aug 2011 14:06:20 -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 1Qp57c-0004ou-2i; Thu, 04 Aug 2011 23:06:33 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 44CE5A80025; Thu, 4 Aug 2011 23:06:27 +0200 (CEST)
Message-ID: <4E3B09D2.70202@kit.edu>
Date: Thu, 04 Aug 2011 23:06:26 +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: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
References: <4E3936FF.1090006@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C646B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E39A744.8010508@kit.edu> <EFDB2B5417263843B5077E12666D8C10187C6490@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4E3A59FE.1090809@kit.edu> <EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <EFDB2B5417263843B5077E12666D8C1018FD26C8@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
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 1312491993.840208000
Cc: "vnrg@irtf.org" <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 21:06:21 -0000

Hi Dimitri and all,

On 04.08.2011 12:28, Papadimitriou, Dimitri (Dimitri) wrote:
> Trying to summarize the discussion:

> o) VNRG, even if dealing virtual network, does not mandate VN
> provided exclusively by networking infrastructure providers. Part of
> the problem comes from the definition initially proposed which refers
> to Infrastructure Provider whereas one should speak about a Physical
> Resource Host (or a term that doesn't implicitly assign VN roles from
> the roles inherited by current physical networks).

To me "Infrastructure Provider" is a broad term not necessarily
narrowing down to solely a meaning of "_Network_ Infrastructure
Provider". That is, an InP may provide many different types of substrate
resources, e.g., network nodes, links, servers, hosts, storage, etc.
Would that be ok for you?

> o) Next we should not restrict physical resources to networking nodes
> / links but also incorporate storage and processing resources (a.k.a
> IT resources). Thus, instead of restricting a virtual resource of
> type X to be hosted on physical resources of type X, the definitions
> should allow for a virtual resource of type X to be hosted on a
> physical resource of type Y.

Agreed as already discussed.

> o) Moreover, we have to better distinguish the type of resource from
> their function/role. In the initial definition, there is a 1:1
> relationship (because a physical networking node can only host
> virtual nodes e.g. virtual routers), whereas in the example provided
> in the previous e-mail (case of emulation of virtual resources),
> there is a 1:N relationship (IT resources can emulate a set of
> routers).

Yes.

> o) Finally, the partition of the physical resources on which the VN
> relies should not determine the delimitation of that VN. Whatever the
> criteria of demarcation between physical resources being
> administrative, ownership, etc. as long as we don't find an
> architecturally constraining reason these different levels of
> demarcation should be left independent.

Agreed, I think in my earlier example it was pretty clear that the VN
spanned multiple InP domains, which is a nice aspect of this virtual
abstraction, i.e., you don't have to care about the InP boundaries.

Regards,
 Roland