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

["Sangjin Jeong" <[e-mail]>]

Dear Krishna,
 
Thanks for the comments. I agree with your comments and will incorporate them 
into the next version of the document. Please see some replies inline.
 
Regards, 
Sangjin
 
> -----Original Message----- 
> From: "Krishna Sankar (ksankar)" <[e-mail]> 
> From Date: 2010-06-09 AM 1:26:47 
> To: "Didier Colle" <[e-mail]>, "Martin Stiemerling" > 
<[e-mail]> 
> Cc: "[e-mail]" <[e-mail]> 
> Subject: Re: [vnrg] Review of draft-shin-virtualization-meta-arch-01.txt 
> 
> 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
 
Ok. I will revise it, but it will be appreciate if you could provide some 
suggestion.  
 
> 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
 
Ok. I will try to categorize the requirements in the next version. 
 
> h)      Also at some point we need to look from the 
> data-control-management planes 
 
We also have received similar comments regarding management aspect, so we will 
investigate it.
 
> 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