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

["Sangjin Jeong" <sjjeong at etri.re.kr>]

Dear Didier,

> -----Original Message----- 
> From: "Didier Colle" <didier.colle at intec.UGent.be> 
> From Date: 2010-06-08 PM 8:19:57 
> To: "Martin Stiemerling" <Martin.Stiemerling at neclab.eu> 
> Cc: "vnrg at irtf.org" <vnrg at irtf.org> 
> 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?

Agree. I will revise the paragraph.

> 
> > - 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.

I think that programmability is not a mandatory for virtual networks, but 
virtual networks may promote programmability in network elements. However, I 
agree with you that programmability is important and closely related virtual 
networks.

> 
> > - 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

I agree with your investigation regarding VN requirements above. I will 
incorporate your requirement inputs into Section 3.

Regards, 
Sangjin

> 
> 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