Re: [vnrg] Some definitions and way forward

Roland Bless <> Thu, 04 August 2011 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8120311E8090 for <>; Thu, 4 Aug 2011 14:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.029
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H6D-JA5PZV-i for <>; Thu, 4 Aug 2011 14:06:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC3C011E8077 for <>; Thu, 4 Aug 2011 14:06:20 -0700 (PDT)
Received: from ([] by with esmtp port 25 id 1Qp57c-0004ou-2i; Thu, 04 Aug 2011 23:06:33 +0200
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTPS id 44CE5A80025; Thu, 4 Aug 2011 23:06:27 +0200 (CEST)
Message-ID: <>
Date: Thu, 04 Aug 2011 23:06:26 +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: "Papadimitriou, Dimitri (Dimitri)" <>
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: 1312491993.840208000
Cc: "" <>
Subject: Re: [vnrg] Some definitions and way forward
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: 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).


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