Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt

["Krishna Sankar (ksankar)" <[e-mail]>]

Good points.

a)	I think if we delete the first sentence "Conventionally ...
characteristics." It would read better. The second sentence is a
succinct description of the virtualization domain, as it stands now.
b)	Virtualization provides abstraction rather than hiding. And in
some cases, it provides direct path to the underlying hardware as well
(for performance and other reasons)
c)	I think programmability is orthogonal to virtualization. IMHO,
virtualization should be dealing with declarative constructs which then
are provisioned and configured by the underlying network.
d)	Yep, second paragraph in section 1.1 is a little mixed. If
programmability needs to be addressed, it should be a new section with
appropriate details.
e)	In section 2, elasticity should be mentioned and described. The
last paragraph touches upon it. But need a little more elaboration
f)	In section 3, SLAs and limits are mentioned, but distributed
across couple of bullet points. Would be good to aggregate them
g)	Would like to see the virtualization requirements be described
on a layered scale of
orchestration-automation-provisioning-configuration - that way we can
separate appropriate paradigms at the right context for example
programmability from abstraction
h)	Also at some point we need to look from the
data-control-management planes  
Cheers
<k/>
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Didier Colle
Sent: Tuesday, June 08, 2010 4:20 AM
To: Martin Stiemerling
Cc: [e-mail]
Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt

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
>
>
> [e-mail]
>
> 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
> [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

_______________________________________________
vnrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/vnrg