Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt
Didier Colle <didier.colle@intec.UGent.be> Tue, 08 June 2010 11:19 UTC
Return-Path: <didier.colle@intec.UGent.be>
X-Original-To: vnrg@core3.amsl.com
Delivered-To: vnrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40E628C169 for <vnrg@core3.amsl.com>; Tue, 8 Jun 2010 04:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.301
X-Spam-Level: **
X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_LIST=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7crb1LUqFHh for <vnrg@core3.amsl.com>; Tue, 8 Jun 2010 04:19:31 -0700 (PDT)
Received: from smtp3.UGent.be (smtp3.ugent.be [157.193.49.127]) by core3.amsl.com (Postfix) with ESMTP id 8E31E28C165 for <vnrg@irtf.org>; Tue, 8 Jun 2010 04:19:30 -0700 (PDT)
Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.UGent.be (Postfix) with ESMTP id BEC4A1478D7; Tue, 8 Jun 2010 13:19:30 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.UGent.be ([157.193.49.127]) by localhost (mcheck2.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 2vIdLMIp+FWm; Tue, 8 Jun 2010 13:19:29 +0200 (CEST)
Received: from mail4.intec.ugent.be (mail4.intec.ugent.be [157.193.214.4]) by smtp3.UGent.be (Postfix) with ESMTP id AE03E147900; Tue, 8 Jun 2010 13:19:27 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 6E2F113925; Tue, 8 Jun 2010 13:19:27 +0200 (CEST)
Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXFD9feJJ1cD; Tue, 8 Jun 2010 13:19:27 +0200 (CEST)
Received: from [157.193.135.66] (dhcp-zdpt-66.intec.ugent.be [157.193.135.66]) by mail4.intec.ugent.be (Postfix) with ESMTP id 08EAD13924; Tue, 8 Jun 2010 13:19:27 +0200 (CEST)
Message-ID: <4C0E275D.3020604@intec.UGent.be>
Date: Tue, 08 Jun 2010 13:19:57 +0200
From: Didier Colle <didier.colle@intec.UGent.be>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
References: <547F018265F92642B577B986577D671C014B9959@VENUS.office>
In-Reply-To: <547F018265F92642B577B986577D671C014B9959@VENUS.office>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Miltered: at mcheck2 with ID 4C0E273F.00A by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4C0E273F.00A/157.193.214.4/mail4.intec.ugent.be/mail4.intec.ugent.be/<didier.colle@intec.UGent.be>
X-j-chkmail-Score: MSGID : 4C0E273F.00A on smtp3.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: vnrg@irtf.org
Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/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: Tue, 08 Jun 2010 11:19:32 -0000
Dear Martin, all, My two cents in this discussion. Martin Stiemerling wrote: > [writing as individual RG member and not as chair] > > Dear all, > > Here is a brief review of draft-shin-virtualization-meta-arch-01.txt. > > - Section 1, 1st paragraph: this describes abstraction but not virtualization. > Would you then say that abstraction is a key tool to realizing virtualization? And what would then be definition of "virtualization"? E.g., creating "virtual things/instances"? To my feeling, "virtualization" means creating "virtual things" by "abstracting away the real things (infrastructure)". Hmm... this might become a pretty "artificial" discussion... Although I tend to agree with the text that virtualization bottom-line always boils down to abstraction of the physical infrastructure, I disagree with the statement in the text: "... or end users can interact with those resources WITHOUT THE KNOWLEDGE OF THE PHYSICAL CHARACTERISTICS." * For example, in an IP/WDM scenario the overlaid IP network(s) is(/are) virtual networks but still the IP routing protocols running in this(/these) virtual IP networks needs to be aware of possible SRLGs. Thus "without knowledge" does not seem correct to me, "with limited ABSTRACTED knowledge" seems more appropriate to me. * Is this compliant with the statement in section 1.1 "When combined with programmability feature in network elements, USERS of virtual networks CAN PROGRAM the network elements on any layers FROM PHYSICAL LAYER to application layer according to users' requirements." How do you program the physical layer WITHOUT KNOWING ANYTHING about that physical layer? > - Section 1, page 3, bullet list: how does this related to VNs? > - Section 1.1: too narrow for VN and it mixes VNs with programmable networks. > Euh... well, to me programmability is a key requirement for virtual networks. Perhaps programmability should not be mixed in section 1.1, but to my understanding it is missing from the requirements section 3. > - Section 2: First para: de-ossification may be one motivation but is in IMHO not the motiviation. > - Section 2: VNs are not necessarily programmable networks. > Again I would not exclude programmability from the requirements. When having a Software-Defined Radio infrastructure, it should be possible to create SDR virtual network instances. When having an infrastructure based on NetFPGA-alike hardware, it should be possible to create FPGA-programmable virtual network instances (e.g., part of the FPGA footprint). > - Section 3: The requirements are too high-level. It would be good to get more detailed requirements and where (from what system) these requirements are. > Some thoughts: * A system managing the virtual instances is needed. * The infrastructure should provide a standardized interface/api to such system. * An interface between that mgmt system and the user: giving user ABSTRACTED info on capabilities of the infrastructure over which he wants to create a virtual instance (e.g., is it programmable, or do you have only a limited number of combinations of "lego bricks"?) Information on the config/mgmt interface of the virtual network (element) instance(s), ... information on the subset of resources that were assigned to a virtual network instance (e.g., a virtual network instance might have been assigned a certain set of VLAN-IDs that he only he can use) * Enforcement of isolation * Enforcement of performance guarantees Kind regards, Didier > - Section 4: It's too high-level. A good use case would describe a VN use case and the resulting challenges and requirements > > I personally do not yet see this document to be the RG problem statement draft at this point of time. > > The draft misses some important points: > - what are some use cases you have in mind (system and what it does) > - e.g., testbed virtualization, operator-scale, Internet-scale, etc? > - what components are you using > - how do these components interact > - what about the existing work, e.g., VPNs, L2 link bundling technologies, virtual routers > - what are the problems? > > In general: I do not yet see that this draft is really a problem statement. It makes a start and its worth keep working on it, but needs more thoughts and discussions. > > Martin > > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > vnrg mailing list > vnrg@irtf.org > https://www.irtf.org/mailman/listinfo/vnrg > -- Didier Colle Ghent University - IMEC - IBBT Department of Information Technology (INTEC) Gaston Crommenlaan 8 bus 201, B-9050 Gent (Ledeberg) Email: didier.colle@intec.UGent.be MSN: didiercolle@hotmail.com Skype: didiercolle Tel. +32 9 331 4970 Fax. +32 9 331 4899 Mobile: +32 473 295655 WWW: www.ibcn.intec.UGent.be
- [vnrg] Review of draft-shin-virtualization-meta-a… Martin Stiemerling
- Re: [vnrg] Review of draft-shin-virtualization-me… Didier Colle
- Re: [vnrg] Review of draft-shin-virtualization-me… Krishna Sankar (ksankar)
- [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Martin Stiemerling
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] way forward on VNRG definitions Sangjin Jeong