Re: [vnrg] Some definitions and way forward

"Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com> Sat, 06 August 2011 14:03 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 53DD421F8754 for <vnrg@ietfa.amsl.com>; Sat, 6 Aug 2011 07:03:56 -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 Ict9QEHhKWZr for <vnrg@ietfa.amsl.com>; Sat, 6 Aug 2011 07:03:55 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5C21F874C for <vnrg@irtf.org>; Sat, 6 Aug 2011 07:03:54 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p76E48l0003973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Aug 2011 16:04:08 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p76E474l025039; Sat, 6 Aug 2011 16:04:08 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 6 Aug 2011 16:04:07 +0200
Received: from 10.150.128.35 ([10.150.128.35]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Sat, 6 Aug 2011 14:04:06 +0000
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: "ext Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>, Roland Bless <roland.bless@kit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 06 Aug 2011 17:02:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTX4ZbNkryoinLQU+84QfmEw7m1wAUt4EQACPT8yE=
Message-ID: <08df01cc5441$b42c4877$2380960a@nsnintra.net>
X-Mailer: EAS Version 1.00
MIME-Version: 1.0
Content-Language: i-default
X-OriginalArrivalTime: 06 Aug 2011 14:04:07.0337 (UTC) FILETIME=[B502D190:01CC5441]
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: Sat, 06 Aug 2011 14:03:56 -0000

Exactly.

Hannu

--- original message ---
From: "ext Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
Subject: RE: [vnrg] Some definitions and way forward
Date: 6th August 2011
Time: 2:44:23 pm

 
Hi,

> On 05.08.2011 10:31, Flinck, Hannu (NSN - FI/Espoo) wrote:
> > 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.
> 
> As already mentioned, it's really not about discussing a business
> model, but about controlling virtual and real resources. In order to
> do that you need different control interfaces for the various
> stakeholders. Let's assume you (as VNO) need to reboot your virtual
> router, because it crashed. Then your InP needs to provide 
> access to the virtual router in order to do that, 

The problem is not the inclusion of "control functionality" into the architectural related definitions but the assignment and distribution of control roles to stakeholders as part of these definitions (cf. VNO, VNP, InP, etc.). At this stage, it is important to define WHAT is to be controlled and not WHO controls what (and the term, e.g., Provider is basically defining the WHO). 

Using my previous example it means that VN, VR* and R* entities have of course associated control function but I didn't indicate who is associated/in charge of controlling the VN, VR*, and R* since it this is not part of the an architectural scope of the definitions we're currently working on. 

Thanks,
-dimitri.

> no matter where it is currently
> hosted in the substrate, but probably without exposing the current
> mapping of virtual to substrate resources.
> As InP you have the mapping information and can easily do this, maybe
> using a different control interface. If you have a VNet 
> spanning several
> InP domains, you even need to find out first at which InP the virtual
> router is currently hosted. This has implications for addressing
> virtual resources in the control plane and so on. These are important
> control plane aspects, not business model aspects.
> 
> Regards,
>  Roland
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
>