Re: [vnrg] Some definitions and way forward

"Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com> Sat, 06 August 2011 11:43 UTC

Return-Path: <dimitri.papadimitriou@alcatel-lucent.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 2CBF421F8663 for <vnrg@ietfa.amsl.com>; Sat, 6 Aug 2011 04:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.582
X-Spam-Level:
X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=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 uZiUGFsCy-YL for <vnrg@ietfa.amsl.com>; Sat, 6 Aug 2011 04:43:52 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 695EF21F863C for <vnrg@irtf.org>; Sat, 6 Aug 2011 04:43:52 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p76Bi7wY005161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 6 Aug 2011 13:44:07 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 6 Aug 2011 13:44:08 +0200
From: "Papadimitriou, Dimitri (Dimitri)" <dimitri.papadimitriou@alcatel-lucent.com>
To: Roland Bless <roland.bless@kit.edu>, "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
Date: Sat, 6 Aug 2011 13:44:06 +0200
Thread-Topic: [vnrg] Some definitions and way forward
Thread-Index: AcxTX4ZbNkryoinLQU+84QfmEw7m1wAUt4EQ
Message-ID: <EFDB2B5417263843B5077E12666D8C1018FD2A4C@FRMRSSXCHMBSB1.dc-m.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> <4E3B09D2.70202@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D307A@FIESEXC035.nsn-intra.net> <4E3BA5DE.6010204@kit.edu> <26E5D1C5D5365D47B147E5E62FC73585036D31C7@FIESEXC035.nsn-intra.net> <4E3BCE47.2000805@kit.edu>
In-Reply-To: <4E3BCE47.2000805@kit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
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: Sat, 06 Aug 2011 11:43:53 -0000

 
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
>