Re: [vnrg] Some definitions and way forward

Roland Bless <> Fri, 05 August 2011 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ED9021F8BCD for <>; Fri, 5 Aug 2011 01:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.039
X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=0.210, 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 51bNiNMUKffw for <>; Fri, 5 Aug 2011 01:12:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 917C021F8BB0 for <>; Fri, 5 Aug 2011 01:12:10 -0700 (PDT)
Received: from ([] by with esmtp port 25 id 1QpFVy-0008HV-7z; Fri, 05 Aug 2011 10:12:23 +0200
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTPS id 2685EA80118; Fri, 5 Aug 2011 10:12:16 +0200 (CEST)
Message-ID: <>
Date: Fri, 05 Aug 2011 10:12:14 +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: "Flinck, Hannu (NSN - FI/Espoo)" <>
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: 1312531944.013566000
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: Fri, 05 Aug 2011 08:12:11 -0000

Hi Hannu,

On 05.08.2011 09:03, Flinck, Hannu (NSN - FI/Espoo) wrote:
> I agree that the definition of Infrastructure Provider is problematic. I
> do not think that stating "... an InP may provide many different types
> of substrate
> resources, e.g., network nodes, links, servers, hosts, storage, etc."
> captures the issue yet.

I don't know what particular problem you mean by "the issue".
It is a fact that virtual resources have to be hosted somewhere
down in the substrate. The substrate is controlled by some entity
(the InP) who also has control over the virtual resources, e.g., an
InP can migrate VMs between substrate nodes or increase/reduce the
capacity of virtual resources etc. A VNO performs also control over
the virtual resource but at a different level and not in the same manner
as an InP. How can we describe such scenarios without defining the
entities/roles who are entitled to perform such control/access?
It's pretty normal that a VNet can be composed of virtual (and physical)
resources hosted at different InPs, so considering the role
of an InP does not impose any restrictions on the VNet realization.

> Virtual networks and physical networks (substrate) can be mixed and
> matched. A MVNO can have most of its infra as "virtual" but some parts

Fully agreed.

> can be very physical (substrate), say by having its own base stations in
> some key areas. Same applies to many enterprise network where parts of
> the resources are virtualized and externalized and some are under the
> control of the enterprise itself. Such an entity would be both InP and
> VNP at the same time. Do we really need to have define InP and VNP at
> all as these terms do not add clarity but confusion? 

I don't see a problem if such entity is performing both roles at the
same time. It makes pretty clear that another InP controls the _virtual_
resources, i.e., the enterprise also depends on this InP, who may be
responsible in case of problems with the virtual resources. The
enterprise needs also some control access to the virtual resources,
no matter where they are actually hosted in the substrate...
Virtual resources are not just hanging in the air, they are realized
on top of virtual or physical substrate resources. As soon as you are
considering control plane issues, different roles matter a lot.