Re: [vnrg] Some definitions and way forward

"Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com> Fri, 05 August 2011 08:31 UTC

Return-Path: <hannu.flinck@nsn.com>
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 7B14B21F8B9E for <vnrg@ietfa.amsl.com>; Fri, 5 Aug 2011 01:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cNU6KyvnfkPy for <vnrg@ietfa.amsl.com>; Fri, 5 Aug 2011 01:31:41 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0FB21F8B98 for <vnrg@irtf.org>; Fri, 5 Aug 2011 01:31:40 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p758VsJv022470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Aug 2011 10:31:54 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p758Vpuw026825; Fri, 5 Aug 2011 10:31:54 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Aug 2011 10:31:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Aug 2011 11:31:40 +0300
Message-ID: <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net>
In-Reply-To: <4E3BA5DE.6010204@kit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTR2phlY2WpnW7QqWzew++Iwb4XwAAarKw
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> <4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu>
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "ext Roland Bless" <roland.bless@kit.edu>
X-OriginalArrivalTime: 05 Aug 2011 08:31:42.0987 (UTC) FILETIME=[1AD6C5B0:01CC534A]
Cc: 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: Fri, 05 Aug 2011 08:31:41 -0000

The "issue" is the definition of the terms you have been discussing on
this mailing list and particularly the first point in Dimitri's mail
dated (04.08.2011 12:28,) summarizing the discussion. It was also quoted
in my mail.

Can you please elaborate what do you mean by "As soon as you
areconsidering control plane issues, different roles matter a lot." For
me the InP and VNP doesn't seem to be that useful other than explaining
a certain, somewhat limited business model.

   
Regards
Hannu

-----Original Message-----
From: ext Roland Bless [mailto:roland.bless@kit.edu] 
Sent: Friday, August 05, 2011 11:12 AM
To: Flinck, Hannu (NSN - FI/Espoo)
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Some definitions and way forward

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.

Regards,
 Roland