Dear Sangjin, all,If I am right, this is the current definition in the document (cfr. 2nd paragraph in section 1.1)?
A virtual network is a logical partition of a physical or logical network and its capability is the same as or subset of the network.I am struggling with the latter part. What is exactly meant by "capability"? And "of THE network'?
Reading further in section 1.2 it is stated
The virtual networks over physical infrastructure are completely isolated each other, so different virtual networks may use different network technologies, for example, different protocols and packet formats or even defining a new layering architecture can be supported on each virtual network without interfering the operation of other virtual networks.
In such a case, what is THE network? What are its capabilities?==> Suggestion for new definition of virtual network (avoiding refer to CAPABILITY of THE network): a virtual network is a network consisting of virtual resources created out/partition of a pool/substrate of other resources (physical or virtual). In other words, what I am trying to say is: there is no underlying "network" only underlying "resources" and only a virtual "network" is build after that these "resources" have been "virtualized"/"aggregated-and-then-sliced".
By the way, it might be interesting to include in the section on the definition of a virtual network the definition of a non-virtual network. Does there actually exist a formal definition (e.g., one of the first RFCs)?
Regarding the following requirement:
The virtual network may want to avoid complex physical network operations that are fully dependent on the types of network layers and equipment vendors. To disengage the virtual network from the complexity of the physical network, the network virtualization should be capable of abstracting the physical network information and provides the standardized interfaces for resource control to the virtual networks.I do not disagree, but feel it important that "abstracting the physical network information" still allows specifying for example SRLG information, delays of virtual links, .... More generalized, that would become something like: abstracting underlying infrastructure while retaining (and guaranteeing (cfr. SLA guarantees below)) characteristic information of the logical resources made available to a virtual network instance.
The following requirement seems to strict to me:
Considering the utility of customers, each virtual network should be capable of using physical network resources and constructing a network topology. However, one possible problem is that some abnormal virtual networks may occupy most of the resources, which deteriorates other virtual network performance due to network resource exhaustion. So, the network virtualization should provide the capability to regulate the upper limit of resource consumption by each virtual network in order to maintain the overall utility and performance.
Other schemes should be possible to envisage:* More in the core network: dedicated reserved bandwidth per virtual network / slice. Thus no overbooking allowed. * In the access network: probably overbooking cannot be prevented. Regulation of upper limit of resource consumption could be a scheme. But adaptive pricing schemes for example could be another technique. ==> More generalized: the infrastructure provider delivers a service to the virtual network instance operators by providing virtual resources in accordance to certain SLA guarantees (cfr. characteristic information of logical resources above). For this, the virtualization technology should regulate behavior of virtual network instance usages (similarly as the traffic shaping/marking that happens at the ingress of regular networks, but also for example frequency of reconfiguring things in a virtual network instance should be limited (cfr. finite/limited capacity of network element control/mgmt infrastructure).
A requirement that is missing, is the accountability in case of a failure.Scenario: you have an infrastructure provider, providing virtual network services to several network service providers. In case something breaks, the customers from the network service providers should be able to make some accountable in case the service they purchased is broken and not ending up in a situation that the network service provider and the infrastructure provider are blaming each other.
Another requirement that needs to be added:Failure of the virtualization technology should be handled in such a way that minimal impact is perceived by the virtual network instances. (Similarly to: ideally, when the control plane in a regular network fails, this should not interrupt the operation of the data plane).
Kind regards, Didier Sangjin Jeong wrote:
Dear VNRG folks,We have uploaded the revised version of Network Virtualization Problem Statement document. This version incorporated most of the comments we have received so far, except some comments about Section 4 (Applicability and use cases) and a couple of general comments. Please have a look and let us know if you have any comments to the document. Regards,Sangjin-----Original Message----- From: <Internet-Drafts at ietf.org> Date: Tue, Jul 13, 2010 at 9:00 AM Subject: I-D Action:draft-shin-virtualization-meta-arch-02.txt To: i-d-announce at ietf.orgA New Internet-Draft is available from the on-line Internet-Drafts directories. ? ? ? ?Title ? ? ? ? ? : Network Virtualization Problem Statement ? ? ? ?Author(s) ? ? ? : S. Jeong, et al. ? ? ? ?Filename ? ? ? ?: draft-shin-virtualization-meta-arch-02.txt ? ? ? ?Pages ? ? ? ? ? : 10 ? ? ? ?Date ? ? ? ? ? ?: 2010-07-12 This document analyzes and discusses the problem space of supporting network virtualization in the networks. ?Furthermore, some key requirements for enabling network virtualization in the networks are investigated and described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-virtualization-meta-arch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft._______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt_______________________________________________ vnrg mailing list vnrg at 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 at intec.UGent.be MSN: didiercolle at hotmail.com Skype: didiercolle Tel. +32 9 331 4970 Fax. +32 9 331 4899 Mobile: +32 473 295655 WWW: www.ibcn.intec.UGent.be
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.