Re: [vnrg] FW: I-D Action:draft-shin-virtualization-meta-arch-02.txt

[Didier Colle <[e-mail]>]

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: <[e-mail]> 
> Date: Tue, Jul 13, 2010 at 9:00 AM 
> Subject: I-D Action:draft-shin-virtualization-meta-arch-02.txt 
> To: [e-mail] 
>
>
> A 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 
> [e-mail] 
> 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
> [e-mail]
> 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: [e-mail]
MSN: [e-mail]
Skype: didiercolle
Tel. [phone]
Fax. [phone]
Mobile: [phone]
WWW: www.ibcn.intec.UGent.be